Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
Thread beginning with comment 548278
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: true, but some libraries...
by shmerl on Fri 11th Jan 2013 00:03
in reply to "true, but some libraries..."
RE: true, but some libraries...
by rexstuff on Fri 11th Jan 2013 00:30
in reply to "true, but some libraries..."
What are you talking about?! The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors. (Admittedly the ugliness of those errors are partly due to C++'s template implementations, and STL and Boost are far and away the best set of libraries for C++)
RE[2]: true, but some libraries...
by kwan_e on Fri 11th Jan 2013 01:14
in reply to "RE: true, but some libraries..."
What are you talking about?! The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors. (Admittedly the ugliness of those errors are partly due to C++'s template implementations, and STL and Boost are far and away the best set of libraries for C++)
The problem there is the lack of adequate tooling for C++. C++ templating should have been largely fixed by having Concepts. Too bad it didn't make it into the standard.
RE[2]: true, but some libraries...
by dorin.lazar on Fri 11th Jan 2013 01:26
in reply to "RE: true, but some libraries..."
The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors.
I see little bloat in STL, although for a while I was misguided as well, and thought that STL was too bloated. It isn't. STL is quite small and quite elegant; I would not be afraid of using it.
With Boost I can agree that it's a bloated animal, but nobody says you should use Boost. It's just too big, and sometimes you need a smart pointer.
But now, C++11 really comes in and saves the day. It does make the STL more efficient, and makes you need less features of Boost. It adds the smart pointers you need in the standard, as well as threading and timing. It's quite nice, you should try it.
The errors are indeed awful; but maybe this is something that can be improved.
RE: true, but some libraries...
by Vanders on Fri 11th Jan 2013 11:25
in reply to "true, but some libraries..."
The STL and Boost are just awesome, even when not using a OO programming style a C++ programmer has some very nice libraries available. Being able to use vectors is nice.
Vectors are nice (as are Lists) but those alone aren't good enough reasons to use C++.
One thing that's always confused me is the odd separation between the STL and language features. For example, why are Iterators an STL class rather than being a language construct, along with some syntactic sugar like a foreach statement?
RE[2]: true, but some libraries...
by kwan_e on Fri 11th Jan 2013 11:51
in reply to "RE: true, but some libraries..."
One thing that's always confused me is the odd separation between the STL and language features. For example, why are Iterators an STL class rather than being a language construct, along with some syntactic sugar like a foreach statement?
One of the biggest reasons why C++ is the complicated language it is is due to the design principle they used that most of the heavy lifting be done in libraries.
The STL and TR/Boost libraries serve as a demonstration of C++ language features.
There's also the other principle of "you don't pay for what you don't use". Having library features as part of the language features could result in unwanted features being pulled into low level code. Having a separate library is a very strong signal that the inclusion of heavy weight stuff is intentional when it's in code.





Member since:
2005-07-06
The STL and Boost are just awesome, even when not using a OO programming style a C++ programmer has some very nice libraries available. Being able to use vectors is nice. Having many good libraries is nice:
http://en.wikipedia.org/wiki/Category:C%2B%2B_libraries
But otherwise, I mostly agree with the author. C has shortcomings, but they are well documented and tools are available to deal with them.
Edited 2013-01-11 00:07 UTC