Linked by anonymous on Tue 29th Mar 2011 16:05 UTC
General Development The C++ programming language is about to be updated, as the ISO steering committee for the language has approved the final draft specifying its next version. The ISO/IEC Information Technology Task Force will review the steering committee's Final Draft International Standard will review and, barring any complications, publish the draft later this year. It will be known as C++ 2011.
Thread beginning with comment 468333
To view parent comment, click here.
To read all comments associated with this story, please click here.
MORB
Member since:
2005-07-06

Yeah, so until recently STL was missing a couple things. It's still a far cry compare dto not having anything at all.

And I would submit that people who dislike the STL are bad programmers prone to reinvent the wheel anyway. There is pretty much no valid reason not to use the STL. There is a lot of bad excuses, though.

Reply Parent Score: 3

rom508 Member since:
2007-04-20

Right, so when the speed of linked lists in C vs C++ is the same, however the code bloat due to STL is 200K extra (and grows in proportion to the number of linked list objects in use), you call this a bad excuse not to use STL?

Now take this code size overhead and multiple by the number of different containers in use and the number of container instances and you end up with a hefty bloat.

Reply Parent Score: 0

MORB Member since:
2005-07-06

Right, so when the speed of linked lists in C vs C++ is the same, however the code bloat due to STL is 200K extra (and grows in proportion to the number of linked list objects in use), you call this a bad excuse not to use STL?

You're not stating on which compiler, with which compilation options (debug builds don't count) or even how you measure this 200k difference (if you don't strip symbols from the binary it's obviously going to be a lot bigger, but it doesn't count either).

Now take this code size overhead and multiple by the number of different containers in use and the number of container instances and you end up with a hefty bloat.


You don't have 200k of container code implementation, that's simply wrong. And don't tell me "prove it" when you didn't even provide any detail as to the origin of that "200k" overhead claim.

Also, either it depends on the number of different container types (non-inline code) or the number of times containers are used (inline code).

Interestingly, a plain C container implementation would either involve inline code, or functions and their overhead would scale similarly.

Bad excuse? You betcha.

Reply Parent Score: 3

moondevil Member since:
2005-07-08

So you prefer to loose productivity in order to gain 200 KB?!

Great decision.

Reply Parent Score: 2

dsmogor Member since:
2005-09-01

Horror error messages (at least on GCC) would be one reason to make.
If I can recall properly I managed to generate error messages that were literally half screen size, 80% of which were the typedefs for some obscure implementation specific stuff I saw first time in my life.

Thats my biggest complaint for template libs. They fail to hide implementation details the moment you put a character in a wrong place.

I even recall some tool that user perl magic to turn those error messages into something at least mercifull.

That was few years back though, I don't know what does it look now.

Reply Parent Score: 2