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 468344
To view parent comment, click here.
To read all comments associated with this story, please click here.
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

rom508 Member since:
2007-04-20

Bad excuse? You betcha.


Use STL linked list for storing and traversing struct01{int n1, int n2;} data type, note executable size. Then create 10 linked lists, storing struct01{int n1; int n2;}, struct02{int n1; int n2;}, ... struct10{int n1; int n2;} and note executable size.

Reply Parent Score: 1

moondevil Member since:
2005-07-08

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

Great decision.

Reply Parent Score: 2

boldingd Member since:
2009-02-19

Indeed. Stating the obvious: for a lot of projects, developer productivity and code correctness are significantly more important than byte-counting efficiency. And that's been true for a Some Time Now.

Reply Parent Score: 3