Comment by gd1 | Hacker News Reader

Comment by gd1 | Hacker News Reader

Parent Full thread

>Write all your code this way and soon you'll stumble with all the nastiness of manual memory management.

See, this is what I never quite understand. I use C++ when I want to do C type things. Manage my own memory. Bit twiddle with speed. Avoid all dynamic allocations. Increase cache coherency. Call inline assembler. Use the CRTP to achieve static polymorphism. Design my own containers. Lock free containers with atomics. Etc. If I'm using C++ I want nastiness. I want to get down and dirty.

Why on earth would you ever want to use it as a higher level lanuage? It sucks balls at that. Just go and use a proper, nice, well designed high level language instead. If I want a language that holds my hand and protects me from the evil pointers, I'm not choosing C++. Using C# or Java (for example) is complete luxury compared to C++.

But apparently, there are a whole bunch of people that do attempt to use C++ for this purpose. Who strive to achieve a language where you never see a raw pointer, but you are still stuck with maybe 30% of the productivity you'd have in a proper higher level language. It boggles my mind. Congratulations, now you have no garbage collection, a crap IDE, you're still wrestling with forward declarations of classes and header files and the preprocessor and linker options and slow compilation and you've now buried the machine under a layer of abstraction. The absolute worst of both worlds.

>brings both the benefits of C-like speed and higher level languages safety.

It doesn't. You end up with neither!

> It doesn't. You end up with neither!

Except that it does. This article clearly demonstrates one way that C++ provides higher level safety without overheads - the allocated memory is guaranteed to be freed.

Nobody is saying you can't do low-level stuff in C++. They're just saying that C++ provides a zero-overhead way to do it safely. Why wouldn't you want that?

Except many provided abstractions are not really zero-overhead and it is even debatable if they are lower-overhead than abstractions found in the higher level languages (like mentioned here Java or C#).

Use std::string everywhere and the (re)allocation rate / fragmentation will make your allocator very sad. C-style strings are not "fast" per-se, but at least they make all the overhead explicit.

Use std::shared_ptr for everything and you'll end up with a higher overhead than any proper GC, particularly on a multicore system.

Use templates too much and your code size will blow away any L1 cache very soon.

Use std::mutex/std::lock to protect shared state and it is going to cost you much more than synchronized in Java, which Java often turns into a noop, but C++ compiler can't.

Use virtual functions and (in all except very trivial cases) they will prevent strong opimizations like inlining in many cases where C# or Java would have no problem.

Want to have safe array access? Sure, still possible to add range checks (e.g. use at instead of []), but are you really sure C++ compilers are as strong in eliding these checks as compilers for the languages with mandatory array bound checking?

Oh, you can even go the Java/C# style very heavily and use Boehm GC. Because you can. Who said C++ is lower-level? Except it is nowhere near the performance levels achieved by proper modern GCs.

Sure thing, C++ is now very slow. That's why big projects like LLVM/Clang, WebKit, Gecko, Internet Explorer, AutoCAD, all Adobe products, all AAA 3D games and most indie ones use C++ instead of Java. If they knew back then when they started that Java and C# have lower overhead than C++!

Funny you listed mostly desktop Windows applications, where C / C++ API were just the only choice in the times when these applications were born. All of the three (Java, C# and C++) are used in performance-critical applications these days, but you just need look at computing as a whole, and not just at a tiny part of the market (desktop).

Also, not sure why if someone points to the obvious places where C++ could be slow, people treat it personally as an attack on "their" language. The fact that many high-level abstractions are not-free in C++, doesn't preclude it from being still highly performing, particularly if you know the cost of these abstractions and you know when to avoid them.

The point isn't necessarily about whether C++'s abstractions are faster than Java's, the point is more that you aren't always forced to use them. If you are willing to commit to the size of your string at compile time, you have the option to use char[N] instead, avoiding heap allocations. Or you can use a stack-based allocator for std::string.

The thing about templates is misleading. Sure, if misused they can hurt your cache. But they also move branching from run time to compile time, which is a very good thing. Google some benchmarks of C++ sort vs C qsort; the former is much faster because the comparator can easily be inlined.

The templates used in my post, for example, either bloat the code not at all, or very little. They are either generating tiny functions that get inlined anyway (like ArrayView; once a function is inlined its irrelevant whether it came from a template or not for code bloat purposes) or they are generating code that would just need to be written by hand (like make_contiguous).

I've actually personally witnessed two fairly detailed accounts of people that actually got themselves into situations where template or template-like bloat became a performance negative, relative to the benefits they provided. They didn't cite a cliche about code bloat, they actually benchmarked and found the cost. What both of them were doing was very extreme; nobody who's not using very extreme template techniques (and therefore is sold on it) is hitting that point.

> cache coherency

Cache locality. Cache coherency is something different.

Reply on news.ycombinator.com