4 ms·
I'm using C++ right now but tend to write very "thin" C++ that is mostly C-like. I just like the object syntax for grouping things together, I sometimes do use
by api 14y ago
I'm using C++ right now but tend to write very "thin" C++ that is mostly C-like. I just like the object syntax for grouping things together, I sometimes do use a little bit of templates/inheritance when it makes sense, and I like the STL core data structures. C has nothing like STL -- no good portable data structure library. (STL isn't that great, but it's passable and ports to everything.) Operator overloading is nice in places, like with data structures and for mathematical code, but should not be over-used. Exceptions can also be useful, though in my current code base I am not using them much.
Boost is somewhat tempting but it's just too convoluted in places. Haven't had a reason to use it yet. Qt is nice for GUIs.
The thing about C++ is that it's a language that lets you do almost anything, and it has no stylistic traditions. It's like Linux if it has absolutely no filesystem layout standard or LSB. Each C++ sub-community (Microsoft, Qt, Boost, etc.) has its own conventions that are in conflict with one another. The language imposes no internal sense of discipline and carries no de-facto coding standard. As a result, I find most C++ libraries to be annoying to use even in my own C++ code. I tend to use it as a top abstraction layer gluing together underlying C libraries and system calls, and to use most C++ libraries (except STL) reluctantly.
It's too bad... well-done C++ can be very clean, efficient, and safe from things that dog C such as memory leaks, buffer overflows, or rare core dump crashes due to things that could be caught and handled as last-resorts in a try{} catch ( ... ) {} construct.
- hosay123 14y agoIn my experience there's only 3 major C++ styles: BusinessObjects *(Java-ish Qt), std::cavedwelling<stl_guru, guru_cavedwelling_tag<const _Type<T &> >::const_value_type, and void _rather_be_writing_c(); Often code you'll come across is some combobulated identity crisis mixture of those 3. In terms of sheer readability and extension, I'm a major fan of Qt's design style (their most elaborate use of C++ appears to be virtual functions and the pImpl idiom), although that approach leads to heavy heap usage. Really detest simple problems "overly" expressed in guru-ified STL. Can't read it, can't modify it, can't extend it, can't debug it. Naturally this means I'm not a great fan of Boost.
- eropple 14y agoCan't read it, can't modify it, can't extend it, can't debug it. Naturally this means I'm not a great fan of Boost. The STL in particular is designed the way it is largely for performance reasons. Ditto for Boost. I am not a fan of writing template soup, but theirs has a purpose. I mean, it can totally be frustrating (the inheritance hierarchy for collections/iterators recently gave me grief), but the reasons for their design decisions, when you take into account their goals, are generally very sound. In any event, I have never had to introduce template soup to my code when using Boost. Even the boilerplate annoyances have been largely mitigated with C++11 and type inference.
- cageface 14y agoI can see why Stroustrup finds so much C++ criticism annoying - language design is all about tradeoffs and many of the less elegant parts of C++ are compromises made to preserve performance. Stroustrup himself has said there's a cleaner, simpler language trying to get out of C++. C++11 seems like a good step in that direction.
- emmelaich 14y agoIndeed. Not only that, the criticisms are often poor echoes of Stroustrup's own considered, well presented discussion of shortcomings and trade-offs as presented in say, "The Design and Evolution of C++"
- ___1___ 14y agoC++ is a multiparadigm language, all of the styles you mention are extreme bastardisations of the style laid out in books like Accelerated C++, Effective C++, Exceptional C++. Modern C++ Design and so on. That style tends to be similar to that used in the STL with some OOP thrown in - when suitable. It is about selecting the abstraction that is appropriately ensuring the code is abides by RAII. I am convinced that the Javaish/Qt way of coding is destructive for C++ as inheritance is not as simple as the generic programming style once you get to grips with it and has a lot of gotchas. And the C - style is to me just plain wrong, especially if you are using any of the C++ standard library as they are privy to throw and without reliance on RAII your code will not be exception safe, if you want C use C.