Which features of C++ are particularly resource intensive at compile time?

I believe C is generally faster to compile than C++, because it lacks features like late binding and o开发者_运维技巧perator overloading. I'm interested in knowing which features of C++ tend to slow the compilation process the most?

This is a difficult question to answer in a meaningful way. If you look purely at lines of code per second (or something on that order), there's no question that a C compiler should be faster than a C++ compiler. By itself, that doesn't mean much though.

The mention of late-binding in the question is an excellent case in point: it's almost certainly true that compiling a C++ virtual function is at least somewhat slower than compiling a C (non-virtual) function. That doesn't mean much though -- the two aren't equivalent at all. The C equivalent of a C++ virtual function will typically be a pointer to a function or else code that uses a switch on an enumerated type to determine which of a number of pieces of code to invoke.

By the time you create code that's actually equivalent, it's open to question whether C will have any advantage at all. In fact, my guess would be rather the opposite: at least in the compilers I've written, an awful lot of the time is spent on the front-end, doing relatively simple things like just tokenizing the input stream. Given the extra length I'd expect from code like this in C, by the time you had code that was actually equivalent, it wouldn't surprise me a whole lot if it ended up about the same or even somewhat slower to compile.

Operator overloading could give somewhat the same effect: on one hand, the code that overloads the operator almost certainly takes a bit of extra time to compile. At the same time, the code that uses the overloaded operator will often be shorter specifically because it uses an overloaded operator instead of needing to invoke functions via names that will almost inevitably be longer. That's likely to reduce that expensive up-front tokenization step, so if you use the overloaded operator a lot, overall compilation time might actually be reduced.

Templates can be a bit the same way, except that in this case it's often substantially more difficult to even conceive of a reasonable comparison. Just for example, when you're doing sorting in C, you typically use qsort, which takes a pointer to a function to handle the comparison. The most common alternative in C++ is std::sort, which is a template that includes a template argument for the comparison. The difference is that since that is a template argument, the code for the comparison is typically generated inline instead of being invoked via a pointer.

In theory I suppose one could perhaps write a giant macro to do the same -- but I'm pretty sure I've never seen such a thing actually done, so it's extremely difficult to guess at how much slower or faster it might be to use if it one existed. Given the simplicity of macros versus templates, I'd guess it would compile faster, but exactly how much faster will probably remain forever a mystery; I'm certainly not going to try to write a complete Quicksort or Introsort in a C macro!

Templates are a turing complete functional language that's executed at compilation time. So they can cause the compiler to take quite a long time, though most compilers have a recursion depth limit that strongly limits this.

Templates are generally more compiler intensive, partly because the whole templated library needs to be compiled. This is especially true for STL, where all the code for the library is in header files and needs to be compiled whenever the client code is compiled.

Putting code in the header files will slow down your compilation. Not just because there is more code to compile but because changing the code in one file may cause lots of recompilations to be necessary.

It's a smaller language with fewer rules so the compiler has less work to do.

But all of that is moot. A Saturn V is slower off the line than a Prius. Measure their speeds 30 seconds down the line, however...