Slashdot Mirror

I'm the lead for a group of over 20 engineers and programmers that produces public safety communications equipment and have direct experience with memory leaks large scale C++ projects AND Firefox. The system we sell includes embedded devices, a Linux/Oracle/Apache server for management, and management terminals. Management and monitoring is done via web browser, either on Windows or Linux. We officially support both Firefox and IE, and both leak memory. We strictly control what is installed on the management PCs - no browsers extensions, no ActiveX components, no Firefox Ad-ons. Typical usage is to open the browser and monitor one page continuously for weeks until an alarm is shown.

Let me be clear, both Firefox and IE leak memory so badly that even on management PC with 2GB of RAM we have to require the end user to restart the browser every week. We are monitoring FF3 and looking forward to reduced memory leakage. In the referenced article it discusses reducing memory fragmentation. OK, that's a worthy goal but first fix the memory leaks. Memory fragmentation and memory leaks are related, but different beasties. A memory leak almost always results in fragmentation, but fragmentation can happen simply from an unfortunate memory allocation/deallocation pattern.

Regarding C++ and memory leaks: over 2 1/2 years we've worked on the embedded code, which is pure C++, we have hunted exactly one memory leak. And that leak turned out to be from the OS. We use Boost smart pointers, RAII, exceptions, and exception safe code. We have no trouble with leaks or fragmentation, despite a fairly high turnover rate and a customer base that would quickly notice memory leaks requiring reboot of the embedded devices.

Who, in their right mind, would devote thousands of development hours cobbling something together, then cast it into the wind where basement developers use "what they want, and [get] rid of what they don't?"

Hmm, let's see...

• Apple
• Adobe
• Cray

And of course the usual suspects like Sun and IBM.

Free Software can most definitely be an important part of a business strategy. For example, the company I work for uses it to leverage testing resources of the community. We also get bug fixes back from the community. We think it makes a lot of sense for a large community to share core development responsibility, the sort of stuff you find in university textbooks that is not proprietary in any way.

In the future, companies aren't going to make money selling operating systems, word processors or basic compiler implementations. They're going to make money modifying the OS to run well on custom hardware, selling plugins to do fancy document formatting and developing new compiler optimizations that make all of this run well on their proprietary computer system.

indeed it does and it works very well:

http://www.boost.org/libs/utility/operators.htm

proxy

The problem is that there are so many ways to do things wrong in C++. Writing proper code takes experience. It doesn't help either that monsters like MFC easily mess things up.

I was going to quit coding C++ when I discovered Boost and wxWidgets. Now I don't want use anything else.

I haven't had any problems with wrong values being returned. Did you properly initialize your variables to default values?

("foo,f",
po::value<int>(&foo)->default_value(10) ,
"some description here")

The main reason I settled on boost::program_options was that it was written in C++ for C++, unlike other libraries out there. An added bonus is that it can also accept configuration files via the parse_config_file function.

What about Boost.Program_Options? I thought I'd see a post on it here somewhere, but not one person has mentioned it (yet).

A few months ago, I was looking around for a C++ library for parsing command line options. I checked out get_opt and I thought that there must be something that uses std::string instead of char*. After some googling, I found Boost.Program_Options seemed to be exactly what I was looking for. It supports long and short options (-s,--short) and I was able to start using it quite easily after looking at the tutorials.

You should look at Phoenix. You really do not need to be that smart to use it. Check the examples here. Note that Phoenix and Boost.Lambda are planned to be merged in the near future.

http://www.boost.org/libs/smart_ptr/smart_ptr.htm

> I think the relatively small amount of RAM (512Mb) may be responsible since I use Eclipse as my
> main IDE and it usually takes 150-250 megs.

In that case I'm not surprised, TMP code tends to use heaps of RAM for even moderately complicated problems.

> I can mail you the source that results in insane compile times, my email is
> [my nickname on slashdot]@gmail.com

Ok, I'll contact you offline.

> I've looked at http://www.boost.org/libs/statechart/doc/faq.html# CompilerError and it confirms
> what I said - an error in code using the Boost library results in 6-8 long compiler errors and
> only one of them actually needs to be fixed.

Correct. My point was that it's often very easy to find that single line that needs fixing. Just work yourself up the instantiations until you find a line in your code (as opposed to library code).

I'm using g++ 4.1.2 (the default g++ in Ubuntu 7.04) with no optimization, as a debug build. I think the relatively small amount of RAM (512Mb) may be responsible since I use Eclipse as my main IDE and it usually takes 150-250 megs. OTOH the other project I mentioned also builds from Eclipse. I can mail you the source that results in insane compile times, my email is [my nickname on slashdot]@gmail.com
I've looked at http://www.boost.org/libs/statechart/doc/faq.html# CompilerError and it confirms what I said - an error in code using the Boost library results in 6-8 long compiler errors and only one of them actually needs to be fixed.

Hi

> This drives me nuts, a simple 200-line *.cpp file using boost::stateschart compiles
> for about 30 seconds,

What compiler are you using? I've observed *huge* differences (>300%) in compile time, depending on the make of the compiler and optimization settings. Also, I would be very interested in the 200 lines that cause such a long compile time. Optimizing the TMP part of statechart so that compile time is reduced has been on my TODO list for quite some time now. Reports of unbearable compile times would certainly increase the priority of that work item!

> and syntax errors result in 400+ character lines with recursive template codes etc

Have you had a look at http://www.boost.org/libs/statechart/doc/faq.html# CompilerError?

Thanks & Regards,

Andreas

Ah, yes...the flamebait comment from the "expert" who doesn't understand how to use a powerful language feature. It never dies....

"(1) It's impossible to debug. You can't read the code. The debugger can't unravel the templated variables and stuff in any meaningful way for you. You can't even step through code, that's doing a supposedly simple operation like memory allocation!"

Well, rather than getting into a childish "can too!" debate with you, I'll posit that it must have been pretty damn hard to develop boost, if all of the things you mention were actually "impossible".

Better explanation: you don't know how to debug template code. Sad for you, but not a strike against the language.

"(2) Some compilers will choke on the code, or compile it wrong in subtle ways due to differing interpretations of some obscure section of the enormous C++ language spec."

Oooh...scary! Guess what, mate: some FORTRAN compilers choke on legitmate F77 code for the same reasons. This is nothing but a FUD tactic, dressed up as informed criticism.

Boost is well-tested against the major C++ compilers, and you can always find out the status of the various sub-libraries by going here.

"(3) The error messages from the compiler are useless. You have to run them through a filter to even figure out what they mean."

See #1, above.

"(3) Bugs in the library are very difficult to fix. Template metaprograms are essentially programs written in a functional language, except one that has horrible syntax. This is not the stuff that normal C++ programs are made of."

I think your second, third point says volumes about your problems: if you don't know how to use it, then it isn't "normal".

Sometimes, you have to learn new things to be productive in a new programming style. I could spend a great deal of time proving to you that there are many thousands of expert C++ developers who know how to do all of the things that you claim to be "impossible", but it isn't worth my time. I'm just hoping that a few knowledgeable developers will see this, and remove the ridiculous "Insightful" moderation from your rant....

Just FYI, take a look at boost for C++. It's (basically) a template library that makes working with the STL (even with member functions) a breeze. Take a particularly good look at the shared_ptr, bind, and lambda libraries.

Compilers should be doing dimensional analysis at compile-time. I had originally hoped to create C++ templates -- which are evaluated at compile-time -- to do this, but I couldn't quite see how to get them to handle all the possible permutations of unit combinations and conversions -- at least not easily. It really needs to be built into the language.

Compilers should be doing dimensional analysis at compile-time. I had originally hoped to create C++ templates -- which are evaluated at compile-time -- to do this, but I couldn't quite see how to get them to handle all the possible permutations of unit combinations and conversions -- at least not easily. It really needs to be built into the language.

Partial implementation is available from Boost.
A commercial full implementation can be purchased from DinkumWare.

Boost strikes me as the sort of library used by people who want to show off how up to date their skills are , not people who really need to write a program to get a job done

Its bloated

has a wierd syntax that differs from the C++ norm

and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway

What is its point except as intellectual masturbation by its authors?

No this isn't a Troll

this is a post by someone who was forced to use Boost for a year

> shared_ptr is not thread safe

Not true, as I understand it (but please correct me if I'm wrong). See the section titled "thread safety" on this page: http://www.boost.org/libs/smart_ptr/shared_ptr.htm

    "shared_ptr objects offer the same level of thread safety as built-in types."

It goes on to give various examples. This means that you only need to add your own locking in cases where you would also need to lock a built-in pointer type. Well, hmm.... a question that just occurs to me is whether a T* is small enough to be atomic on common architectures, while a shared_ptr is not atomic. It may be that code that relies on writes to pointers being atomic (which is true on most machines, but would not be on e.g. a 32-bit processor with a 64-bit address space) would not work with shared_ptr. But the rest of the time, I believe shared_ptr really is safe.

I'm not sure what techniques the developer is using as the um, "article" is a little light on details (unless I missed something) But the concept of Active Objects (a trivialized way of using threads) has been around for a while with generic implementations of them becoming more mainstream rapidly. In the past week there as been much discussion about active objects and "futures" on the boost mailing list and it is likely that both will become part of boost shortly. To put it simply, an active object is an object which has its own threaded message queue, so it is asynchronous from the rest of the system and a future is a return value from an asynchronous method call, a "future" value. These techniques are quite reasonable today because of concepts like fibers and the NPTL.

And of course, a shameless plug for my active objects implementation (bsd style license). Actually, that page also does a decent job of demonstrating the concepts.

I'm not sure what techniques the developer is using as the um, "article" is a little light on details (unless I missed something) But the concept of Active Objects (a trivialized way of using threads) has been around for a while with generic implementations of them becoming more mainstream rapidly. In the past week there as been much discussion about active objects and "futures" on the boost mailing list and it is likely that both will become part of boost shortly. To put it simply, an active object is an object which has its own threaded message queue, so it is asynchronous from the rest of the system and a future is a return value from an asynchronous method call, a "future" value. These techniques are quite reasonable today because of concepts like fibers and the NPTL.

And of course, a shameless plug for my active objects implementation (bsd style license). Actually, that page also does a decent job of demonstrating the concepts.

I'm not sure what techniques the developer is using as the um, "article" is a little light on details (unless I missed something) But the concept of Active Objects (a trivialized way of using threads) has been around for a while with generic implementations of them becoming more mainstream rapidly. In the past week there as been much discussion about active objects and "futures" on the boost mailing list and it is likely that both will become part of boost shortly. To put it simply, an active object is an object which has its own threaded message queue, so it is asynchronous from the rest of the system and a future is a return value from an asynchronous method call, a "future" value. These techniques are quite reasonable today because of concepts like fibers and the NPTL.

And of course, a shameless plug for my active objects implementation (bsd style license). Actually, that page also does a decent job of demonstrating the concepts.

I'm not sure what techniques the developer is using as the um, "article" is a little light on details (unless I missed something) But the concept of Active Objects (a trivialized way of using threads) has been around for a while with generic implementations of them becoming more mainstream rapidly. In the past week there as been much discussion about active objects and "futures" on the boost mailing list and it is likely that both will become part of boost shortly. To put it simply, an active object is an object which has its own threaded message queue, so it is asynchronous from the rest of the system and a future is a return value from an asynchronous method call, a "future" value. These techniques are quite reasonable today because of concepts like fibers and the NPTL.

And of course, a shameless plug for my active objects implementation (bsd style license). Actually, that page also does a decent job of demonstrating the concepts.

I'm not a coder, I'm a scientist. Sometimes I have to code. Getting the tools to do so is many times easier (faster, cheaper, less confusion, etc.) for me on Linux than on Windows. A colleague recently suggested I try quantlib. He also mentioned that they require Boost which can be a real pain in the ass to get compiled and installed on an XP machine. I went home and installed both of these libraries in 10s of seconds with Synaptic.

So for me, Linux is very "pro-developer".

Sadly I wrote this for the company I work for, so I can't open source it.

No need

You may not be able to use sockets directly with WaitFor[Single|Multiple]Objects(s), but you can attach an event to a socket (using WSAEventSelect IIRC) and wait on that, along with other things (which effectively gives you BSD's select() for Windows' file handles.

As far as the discussion on concurrent programming goes, I'm surprised no one has yet mentioned boost.threads.

What is the right way to do a pthread_cond_wait under win32?

What is the right way to do a pthread_cond_wait under win32?

And the time it takes to get something published is ridiculous ! Take the following example from http://hri.iit.tsukuba.ac.jp/tchri Important Dates: June 1, 2006: Call for Papers September 30, 2006: Deadline for Paper Submission February 28, 2007: Completion of First Review June 30, 2007: Completion of Final Review December 2007 (tentative): Publication So i get to wait 5 months until i known the article gets reviewed . If it's ok it gets published in 1.5 years after submission ?!?!?! If it doesn't get published i still lost 5 months with my work idleing, because i compromised to just publish to that journal ! In http://boost.org/ they peer review c++ libraries in 1 month tops ! I get to face the reviewers and reply their quesions, the reviewers are not anonymous also !

Delegates are not just function pointers, they are a pair consisting of a context pointer and a function pointer. The closest thing C++ has to it are member function pointers, which are far more difficult to work with.

Delegates are not just function pointers, they are a pair consisting of a context pointer and a function pointer. The closest thing C++ has to it are member function pointers, which are far more difficult to work with.

Firstly templates. They are just void pointers with type safety.

This is thoroughly wrong it's hard to keep my reply polite. You'd be roughly correct about the generic support in Java, but about C++ templates, your statement is completely, totally and thoroughly wrong. I can't do anything approaching justice to the subject here, but I'd recommend reading Modern C++ Design by Andrei Alexrandescu, to at least start getting a clue about how much more there really is to templates. You might also want to look at the source code to The boost library for more along the same general line (e.g. take a look at boost Lambda, which is quite different from anything you can do with void pointers.

The thing is, in practice the overhead of the type checking is superfluous as very few bugs are down to bad casts in functionally similar C code.

Sorry, but no. The type-checking is done at compile time, so it doesn't impose any overhead (at runtime -- in theory it makes for slightly longer compile times, but in practice the difference is rarely noticeable.

And while I'm considering performance, despite another poster claiming it's a linker issue, vtable lookups do impact performance regardless of whether you blame the linker or the compiler. The language requiring something like vtable support is the real culprit, excacerbated by the debatable way that C++ handles method resolution. In Java, if I call List.get() on an object that is actually an ArrayList, I get the ArrayList version of the method - the most derived one - not the List implementation. In C++, I get the List implementation (this ignores the fact that List is an interface in Java, but you should get the gist of what I'm saying). In practice, the C++ way of doing this is counter intuitive, despite the fact that the C++ way seems more logical from a syntax point of view.

The performance of a virtual function in C++ (at least with most recent compilers I've tested) is essentially the same as the switch statement or pointer to a function you'd have to use to get the same functionality in C. The problem arises primarily from the fact that people often use virtual functions where they're not really suitable.

The differences between C++ and Java tend to get sufficiently religious quickly enough that I'll stay away from discussing that, at least for now.

As for the inlining of sorting code, in a test I just ran the sorting function was inlined in a C example just like the use of std::sort() you described.

I specifically talked about using qsort. Obviously, you're not doing that. It's nearly always true that more specialized code can be more efficient than more generalized code. The trick is to write generalized code that retains close to the efficiency of the more specialized code -- and C++ does a better job of that than C does.

The difference is that my sort resulted in far less assembler instructions than the C++ std::sort() one, although I did have to spend an extra couple of minutes copying the sort code from a Sedgewick book.

Counting assembly instructions gave a useful of speed in the days of 68Ks and 8088s. Those days are long gone. Given that it came from a Sedgewick book, your code may easily be substantially slower ( I'm not a fan of Sedgewick).

Finally, the iostream library. I spent part of this afternoon refactoring a loop that was proving to be a bottleneck in some C++ code. It relied on ostringstream to turn an unsigned integer into a string, and then passed the std::string representation to be add

Using the shared_ptr class of Boost, it becomes very easy to use heap-allocated objects with C++. It's a smart pointer that automatically deallocates memory when appropriate. Memory leaks are virtually eliminated, without requiring programmer intervention. So in a way, you get the best of the Java world, with the vastly superior native-binary speed of C++.

True. Although that's why the standard is getting shared_ptr and why Boost has pointer containers. It's not perfect, but the STL's philosophy of "make it as generic as possible but not without sacrificing performance" is a restriction. Once you are talking about polymorphic objects, then performance is probably not of as much concern.

The problem with C++ is Stroustrup. Specifically, it's that, as what's now called "C++0x", the next revision, got underway, Strostrup insisted that C++ had no major problems - it just needed some cleanup. This was after a decade of trouble with buffer overflows and related safety issues.

C++ is unique in that it has hiding without safety. No other major language is in that space. C has neither hiding nor safety; Java has hiding with safety, as do almost all languages which postdate C++. This is not fundamental to a compiled language; Modula 2 and 3, and Ada, had hiding with safety. Nor is it related to garbage collection, inherent problems of an efficient, compiled language, or the needs of systems programming. Providing backwards compatibility with C while bolting objects onto the language led to safety issues that were never overcome.

Most of the problems with C stem from the "pointer equals array" model, the basic source of buffer overflow bugs. C doesn't even have a way to talk about the size of array arguments (well, C99 does). Dangling pointers are also a problem but a secondary one. C++ tries to paper this problem over with collections, but far too often, collections have to expose a C pointer to get something done. At that point, size information is lost. Right there is the biggest single problem with C and C++.

The C++ revision committee is dominated by people who want to do l33t things with templates, things nobody will ever do in production code but, they think, are really cool. There's a whole "generic programming" cult of abusing the template mechanism to do computation at compile time. Millions of users suffer from unnecessary program crashes, and the US is more vulnerable to malware and cyber-terrorism because of this focus. It's as if the IEEE committee on power transmission standards was dominated by people who were into making big sparks.

Stroustrup could have insisted on actually fixing the safety problems. But he didn't.

(I'm writing this as someone with over ten years of experience in C++, doing everything from protocol stacks to game physics engines to real-time programming. And after ten years, I'm fed up with the mess. This should have been fixed years ago.)

Oh, you mean something like the Boost multi-index containers library?

Boost is loaded with these sorts of goodies, and is a must-check-out for anyone who does serious C++ programming.

The Event objects are always problematic; see: boost's rationale for not using events.

And there is no nice way to use the window's primitives to create a multiple-reader / single writer semaphore, like there is with the posix threads style.

Not to say that the posix style of messaging is wonderful or anything, though.

--jeffk++

Not so sure. I am a C++ guru, and I still reach for Python first in most cases. It's without a doubt the language that enable me to express the problem that I'm working on in the most clear and succinct fashion. Furthermore, it has certain features that don't really have obvious counterparts in C++, such as generators and list comprehensions, that I find extremely useful.

And when I really need speed for that expensive inner loop, or image processing algorithm, or whatever, I just reach for boost::python and incorporate my C++ code nicely exposed as Python functions and classes.

Look at source code from the masters of programing such as ACE, TAO, and BOOST. Look at "Design Patterns" and learn to recognize where and how each would be applied. Design your own patterns that could have been used for past projects, and "design" new patterns for new projects. Get your hands dirty in learning several programming languages and learn their strengths and weaknesses and be able to choose which is best for any given project, and be able to defend that position (you may have to). Learn how to program "secure code". (Its not as easy as you might think.) Learn reverse engineering, debugging skills, and know your operating system internals.

class_<Loader, boost::noncopyable>("Loader", no_init)
.def("name", &Loader::name)
.def("addTable", &Loader::addTable)
.def("load", &Loader::load)
;

The problem isn't that floating point numbers are inherently problematic, the problem is that we typically use them by converting base-10 numbers to them, doing a bunch of calculations and then converting them back to base 10. [...] Bottom line: If you care about getting the same results you'd get in base 10, do your work in base 10. This is why financial applications should not use floating point numbers.

Base-10 is one problem; floating-point is another. If you are certain that base-10 floating point is what you want for financial calculations, use IEE 754r floating-point numbers when it's finalized. But floating point numbers, by design, only maintain a certain number of significant figures. In many financial calculations (say, current bank balances; possibly not long-term stock market estimates), you always want precision down to the nearest cent or tenth of a cent, regardless of how big the number is. That's a job for fixed-point, base-10 arithmetic. (Luckily, libraries for this exist, and IEE 754r also introduces standardized fixed-point base-10 numbers.)

You might be able to get away with floating-point if the mantissa's wide enough for your largest number[*], but why mess around? Fixed-precision arithmetic is easier to understand, so it's the right tool for the job. Save floating-point numbers for the people who need them, who put in the effort to tweak formulas to minimize errors like catastrophic cancellation, and who use them appropriately:

• knowingly accept an unknown precision and accuracy (might be okay for an OpenGL-based game)
• use interval arithmetic to flag problems (say, scientific calculations that can be tweaked and rerun if a problem is revealed)
• actually prove that they're within defined error bounds (the only way for real-time critical applications, like life-sustaining systems or ones that affect a lot of money)

[*] - Maybe; I don't remember all the properties of IEE 754 floating-point numbers off the top of my head, which is exactly my point.

> For instance, you can't have a C++ array of "anything",
> unless all objects descend from the same class, and then you
> are restricted to functions that were declared in that base
> class.

Sounds like someone hasn't tasted the sweet goodness of Boost. (:

In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.

See here:

http://boost.org/doc/html/any.html ... and see also:

http://boost.org/libs/libraries.htm

The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.

> For instance, you can't have a C++ array of "anything",
> unless all objects descend from the same class, and then you
> are restricted to functions that were declared in that base
> class.

Sounds like someone hasn't tasted the sweet goodness of Boost. (:

In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.

See here:

http://boost.org/doc/html/any.html ... and see also:

http://boost.org/libs/libraries.htm

The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.

If this is what you want, you're better off using Boost than Qt. The GUI library is what makes Qt great. If you just want a foundation library for smart pointers, signals/slots, containers, threads and a bunch of stuff that it never occurred to you that you might need, Boost is far, far superior.

Not only is Boost exception-safe (which almost none of Qt is), but today's Boost library is tomorrow's C++ standard library. Boost prepares you for the future.

I assume you're including the functionality of specialist preprocessors in that list, but even so you have listed a few items of which I was previously unaware. A quick Google search for lambda expressions in C++ brings up preprocessors such as Clamp, which seem rather interesting indeed.

Clamp notwithstanding, actually no: I don't consider preprocessors other than the one that's part of the language as a fair candidate for talking about what a language can do. For pure-C++ lambda, the best (though not the only) example is Boost Lambda.

That said, I have to be careful here. A while ago, I pointed out that one of the advantages of Python over Java was its mutable classes (which could also potentially be a disadvantage as well, but I digress). The person I was discussing this pointed out this wasn't the case, informing me that one could dynamically alter a class at runtime by altering the JVM bytecode. Whilst this was technically true, there's a large difference in practicality between a single line of "Foobar.new_method = method_impl", and a page of Java code manipulating the bytecode of a class.

I agree with you: whoever was discussing with you is taking what I believe to be an unreasonable stance, namely that of suggesting the alteration of the binary as a candidate for a language feature. That said, in C++ what you want to do is relatively easy to replicate, provided that if it's a function you know the signature you're calling (it's possible, but harder, if you don't;) just keep a map or a hash to Boost::Any (or if you need to be stabbed in the stomach, void pointers,) fill it with members and function pointers, and then overload operator-> .

This is why I think C++'s flexibility is vastly underrated: things like that are easy to hack, if you're comfortable with the language.

I'm interested in the compile-time metaprogramming you mention. Perhaps you could point me toward some resources?

I don't actually know of any good ones online, though I've not looked for them. By far the best example I'm aware of is the book Modern C++ Design, which is both an excellent book and which covers quite a few other tremendously powerful techniques, such as template-based policy modules, typelists and type traits, and a whole bunch of other stuff.

I'm aware of the capabilities of templates

With all due respect, I used to say the same thing, and I was just dead wrong. For example, compile-time metaprogramming is accomplished using templates. What most people don't realize - what I didn't realize until I read that book - is that templates are when carefully used in fact a fully distinct third language within C++ (the first two being c++ itself and the macro preprocessor,) and that they create a radically different environment than traditional C++ does.

Do you know of many more preprocessors like Clamp? I'm something of a language nut, and learning something new about a language I thought I was reasonably familiar with is always very interesting.

I refuse to use tools like Clamp. Just a personal thing. Besides, C++ is large enough that, despite having 7 years of heavy industrial use under my belt, I'm still learning things in it at just a remarkable rate.

That all said, I still disagree with your assertion. Runtime metaprogramming can be very useful, especially with higher level functions (or partial functions, as some people apparently refer to them).

My assertion was simply that C++ is more powerful than most people expect. Runtime metaprogramming, well, I've never seen a definition of runtime metaprogramming which I was able to get much traction out of. Each time, people will give me an example, I'll show them how to do that in traditional languages, and they'll tell me I'm missing the point, which I quite possibly am.

The germane difficulty is that compile-time metaprogrammin

This could be an approach for implementing n-tuples :-)

http://www.boost.org/libs/tuple/doc/tuple_users_gu ide.html

Everything is cake when you are an undergrad, and one week's or even one summer's experience with C++ and .NET is just scratching the surface. The C++ specification book (Stroustrup) is a thousand pages and very densly written. .NET is enormous and also takes a year to years to master. The best thing you can do during the summer job is learn from the more experienced people working there (their methods, working with the customer/management, etc.). The programming aspects of the job mainly just bolster the buzzwords on your next resume and provide talking points during interviews.

While you make some good points, you also have a couple of mistakes there. First of all, it's been quite a while since any of Stroustrop's books was really the C++ spec. Anymore, the spec. is the 2003 edition of the C++ standard (aka ISO 14882), and before that it was the 1998 edition of the same. Oh, and FWIW, while it's certainly densely written, it's less than 800 pages long. :-)

.NET is huge, but that's not necessarily very closely related to the time it'll take to master it. In fact, I'd almost go so far as to say that .NET simply isn't oriented toward toward what I would normally consider real mastery. At least from my viewpoint, it's a rather "flat" library -- very large, but not a lot of real depth. Most of the functions just "do what they do", and that's the end of it. To a large extent, "mastery" is mostly a matter of sufficient familiarity that you can quickly find the functions you want/need at any given time.

That's a direct contrast to, for example, the Boost Library or the Loki Library, which are a lot smaller, but a whole lot deeper. Here much of mastery is simply wrapping your head around some of the concepts involved. A few people accustomed to Lisp, Scheme, Ocaml, etc., may already be accustomed to some of them, but most typical programmer have never even considered doing the kinds of things it covers (and even the Lisp crowd is likely to find a fair amount of it somewhat challenging as well).

To put that contrast a bit differently: if you were accustomed to Java (for example), using .NET would mostly mean learning different names for classes and member functions, but the classes and member functions would still be on the same order as you were used to (a bit cleaner in some places, a bit grungier in others, but ultimately the same general kind of thing). By constrast, either Boost or Loki is much more likely to cause fundamental alterations in how you think about and solve your problems.

There's a MUCH better library for Python-C++ integration. See http://boost.org/libs/python/doc/index.html