Comment by Bekwnn
7 years ago
I'll second Scott Meyers and add that Essential C++ covers the most fundamental parts of the language. Books beyond that tend to cover much more specific and optional tools.
Reading Essential C++ cover-to-cover was very worthwhile in my job as a programmer in AAA games. Books beyond that have mostly involved thumbing around different items to see which I might find useful at some point. Games in particular tend to be very performance sensitive, but also compile-time and debug-performance-sensitive. A lot of the STL is not as respectful of those latter two, meaning a lot of game code uses little or even none of the STL. (Working with UE4 will involve using none, for example.) I'd definitely focus more attention on understanding core language features that the huge amount of content that exists in the STL.
By far the best element of C++ that a lot of other languages lack is const and const-correctness. The second best would be the robust features templates have in comparison to generics of other languages (though the applications allowed by that robustness can be mildly horrifying at times).
Const correctness in C++ is a nice feature, but to say it is missing in many other languages is a bit exaggeration. Many other languages offer a much superior tool - immutable data types. Immutability is stronger than C++ const correctness and easier to use at the same time.
Templates are nowhere near capabilities and ease of use of languages with proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or languages with modern generic type systems designed from the ground up (Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but hack is still a hack with all the consequences - terrible error messages, slow compile times, difficult debugging, late error detection, a lot of accidental complexity caused by templates not being first-class citizens etc.
> Immutability is stronger than C++ const correctness and easier to use at the same time.
C++-style const appears to be stronger than just immutability, since you can have immutable objects in C++, but you can also pass const references to mutable objects.
A const reference to a mutable object doesn't guarantee that the object won't change contrary to an immutable object. Hence const is weaker than immutable.
You can have immutable objects in C++, but C++ offers almost nothing to make dealing with such objects fast and easy. Also the lack of GC makes designing persistent data structures an order of magnitude harder task than in most other languages.
2 replies →
That's because it is undefined behavior to cast a const object to a non-const object. Instead, you must tell the compiler via the mutable keyword or else it will make optimizations based on the assumption it can't change.
Precisely why it's harder to use. C++ is more expressive, and thus creating self-consistent designs is harder.
7 replies →
> Const correctness in C++ is a nice feature, but to say it is missing in many other languages is a bit exaggeration. Many other languages offer a much superior tool - immutable data types. Immutability is stronger than C++ const correctness and easier to use at the same time.
Technically C++ const can be used to implement immutable types just as they exist in other languages (and can be hidden behind a library entry point) but I agree that conceptually it's easier to think of an immutable string or vector as an inherent property of the object rather than one applied. And in C++ I don't think you can prevent casting away constness.
> Templates are nowhere near capabilities and ease of use of languages with proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or languages with modern generic type systems designed from the ground up (Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but hack is still a hack with all the consequences - terrible error messages, slow compile times, difficult debugging, late error detection, a lot of accidental complexity caused by templates not being first-class citizens etc.
Templates were not an accidental hack for macros; as Stroustrup once said to me, "the ecological niche of 'macro' had already been polluted so templates were my only way to put macros into the language." I agree it sucks next to lisp macrology (but as a lisp developer since the 1970s I would say that wouldn't I?) but hell, the language makes a distinction between expressions and statements so there's only so much you can do.
> And in C++ I don't think you can prevent casting away constness.
Well, UB prevents you from doing it if the object is originally const.
My bigger gripe with the C++ (and C) const system is the lack of transitivity. A function taking a const X& may still modify e.g. the contents of an exposed pointer member of X.
1 reply →
> By far the best element of C++ that a lot of other languages lack is const and const-correctness.
Add to that volatile-correctness... which most people aren't even aware of. http://www.drdobbs.com/cpp/volatile-the-multithreaded-progra...
This article is nearly 2 decades old and gives very bad advice for multithreaded c++ programming. To a first approximation, volatile should never be used for multithreading safety.
That 2-decade-old article took some 5+ pages to thoroughly explain its ideas. Turns out it was (and still is) pretty compelling, and the changes in these past 2 decades don't really affect what it's saying.
You, who've surely carefully read the article, understood it in its entirety, and played around with the notion to get a feel for its upsides and downsides, very insightfully reduced it all down to "very bad advice" with zero elaboration. You find that compelling?
I would be careful with those "first-order approximations".
20 replies →
Despite that it was written by Alexandrescu, I can say that without a doubt this 2001 article doesn't represent the current state of thought around MT programming and volatile. I'd think of it more as a historical artifact than anything.
The fact that it doesn't doesn't mean it shouldn't be. It's a damn useful method, it just didn't become popular.
15 replies →