As someone who is not a fan of C++, it was interesting to see how the heck C++ ended up the way it is.
I was aware that prioI found this enlightening.
As someone who is not a fan of C++, it was interesting to see how the heck C++ ended up the way it is.
I was aware that prior to C++, Stroustrup created a predecessor called C With Classes. But what I was surprised to learn was that this language did not have virtual functions... making me seriously wonder what the heck the point was. Just to be able to write object.function() instead of function(object) ?
At each step, the decisions made seem pretty reasonable. And yet (IMO), the end result is a mess. I think the constraints on the design (particularly the need for source compatibility with C; also the lack of garbage collection, though that was necessary) were just too much.
Sadly, I don't think there's any real alternative to C++, even today, in its area. A language that lets you be close to the hardware while still giving you some abstractions. Maybe Objective C for some people. Although fewer programs need to be close to the hardware, and that's good.
It's also crazy to realize there was a time when a new general purpose language could ship without even fundamental features like, say, a collections library, and still go on to be so widely used.
I bought this book when considering writing the network component of a program over ACE... I finished the book wondering exactly what the heck was theI bought this book when considering writing the network component of a program over ACE... I finished the book wondering exactly what the heck was the point of using ACE rather than a small portable abstraction over sockets. ...more
This series is really good and brings to light a lot of C++ related issues people need to be aware of.
It also makes you realize, though, how much C++ This series is really good and brings to light a lot of C++ related issues people need to be aware of.
It also makes you realize, though, how much C++ is your enemy. How you have to fight the language to get stuff done. You may be at a point in your journey where you have become numb to this fact. But then reading this series you think about:
1. The Pimpl idiom, a huge mess of a method to get boxed objects (invisible and automatic in every language of the last 20 years)
2. Slicing, something you have to constantly watch out for in C++ (a complete nonissue in other languages)
3. how basically every component of the C++ standard library except the STL is poorly designed
4. Ridiculous template error messages
5. components of the C++ standard that are almost universally unimplemented and considered stupid (export...)
6. how incredibly primitive is textual inclusion of header files? It's like this is 1965 or something.
7. And C-style macros! Wow.
8. Manual memory management. Oh, wait, now there's shared_ptr! The C++ community has reinvented reference counting garbage collection, only 50 years behind schedule. Oh, and you have to manually write crap for the things you want collected and deal with their interaction with manually collected stuff.
9. The absurd hoops you have to jump through to simulate things like nested functions.
10. Incompatible compilers and library implementations.
And on and on.
Now like I said if you write C++ you are dealing with at least some of these issues all the time, but maybe you have become numb. These books will remind you.