Hacker News Reader

Comment by Impossible | Hacker News Reader

It's interesting that with a modern C++ compiler all of these programs are equally valid. This is both the biggest strength and the biggest flaw of C++.

I imagine the size differences are overhead from bringing in STL and maybe template instantiation and are relatively fixed? I would have liked to see performance benchmarks as well as executable size to see if the program has gotten slower, faster, or remained basically the same.

View on HN

No, the majority of that overhead is from the use of `iostream`s (which are known to be pretty bloated compared to `printf` and friends), the use of exceptions (try/catch is a morass of stack-unwinding code), and the added bloat of class information (RTTI and symbols in particular).

If it were compiled with full optimizations and the final binaries stripped, they'd be much closer in size. Moreso if exceptions are disabled or if the class is replaced with a simple function taking/returning tuples.

Not only is iostream bloated, but it often injects a static constructor into every translation unit (which visibly angers the – usually calm – LLVM style guide[1]). Oh and it's really godawfully slow unless you turn off a magic flag somewhere[2].

Friends don't let friends use iostream.

[1]: http://llvm.org/docs/CodingStandards.html#ll_iostream

[2]: http://stackoverflow.com/questions/9371238/why-is-reading-li...

There's a huge difference between using exceptions and littering your code with a bunch of try/catch blocks. When exceptions are used properly, you see very little error handling code.

Templates typically expand to one chunk of code per type handled, so no, executable size does expand if you use a lot of them.

(A C++ fan would counter that they are faster than pointer-based generic algorithms like C's qsort and that you'd get the same code size manually typing it out.)

Whether or not you are a C++ fan, templatized algorithms ARE often faster than their C-based, generic counterparts. Any decent C++ compiler should be able to inline generic code while C often relies on function pointers. I'm not saying this is always the case, but often. std::sort beating qsort is a typical argument, though I'm not sure the two algorithms are equivalent excepting language-specific constructs (http://stackoverflow.com/questions/4708105/performance-of-qs...)

As for size, you're absolutely right, though for many scenarios that appears to be less and less a pressing concern. Perhaps the biggest drawback is compilation time.

Compilation time is becoming less of an issue as well with compilers getting faster and faster. For example the same codebase using GCC 4.6 and clang 3.0, clang is almost 20% faster at compiling the same codebase.

Even so, making heavy use of templates I have not yet found any major issues or that compile time has increased so drastically that it became a concern for the project.

Thankfully you're right; compilers have come a long way and Clang in particular has done a lot for easing the pains of template programming in a number of ways.

I'm knee deep in the development of several header-based, fully templated libraries, so I still certainly feel the pains of compilation times. And while the tests/samples I deal with tend to be somewhat extreme in their (ab)use of templates, I think you'll still find that the average Boost user would give a lot for yet speedier compilation.

std::sort is stable, IIRC. Otherwise, they are similar; and yes, std::sort is typically faster.

Do note that instruction caches are not unlimited, though: bloated code does have a performance cost (sometimes, caches are hard.)

std::stable_sort exists and is the stable one.

I agree with what you're saying but C can be persuaded to make template like code:

http://attractivechaos.awardspace.com/ksort.h.html

Any decent C++ compiler should be able to inline generic code while C often relies on function pointers.

What makes you think that a decent C compiler can't inline runtime-generic code using void* and virtual functions?

Sure, erasing types only so that the optimizer has to figure the information out again using constant propagation is far from optimal, but the underlying issue is actually source code inclusing vs modular compilation -- most of the speed gain of templates comes from the fact that it only works with the former, whereas C-code traditionally does the latter.

Reply on news.ycombinator.com