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.
Order by: Score:
a bout a day late
by dacresni on Tue 29th Mar 2011 16:30 UTC
dacresni
Member since:
2009-08-26

I am most interested in the inherited constructors

Reply Score: 3

Finally!
by moondevil on Tue 29th Mar 2011 17:41 UTC
moondevil
Member since:
2005-07-08

I've been waiting for the standard to finalize for quite some time now. Sadly concepts did not make it until the end, but better so as having another broken feature like export.

Most compilers already implement part of C++2011, so there is already the possibility to play around with some of the new language features.

Reply Score: 4

Overview of support in compilers
by siki_miki on Tue 29th Mar 2011 18:18 UTC
siki_miki
Member since:
2006-01-17

Here are two links that I googled a few weeks ago.

http://wiki.apache.org/stdcxx/C++0xCompilerSupport

MSVC only:
http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-languag...

Halfway through in most cases, support in gcc is seems to be the most complete.

I read a story about concepts. It took long and still wasn't ready. So maybe we will see it in the future. Also a header-less C++ (like Java) would be a nice feature.
All together, it seems as a bunch of very useful and "right" extensions.

Reply Score: 3

RE: Overview of support in compilers
by MORB on Tue 29th Mar 2011 20:59 UTC in reply to "Overview of support in compilers"
MORB Member since:
2005-07-06

Clang is also progressing fast:
http://clang.llvm.org/cxx_status.html

This is not up to date, someone just submitted a patch that implements for range loops.

Also, clang's implementation of the standard c++ library implements almost all of c++0x, whereas gcc's libstdc++ is still missing things such as regexps:
http://libcxx.llvm.org/index.html

I expect clang to catch up with gcc's implementation of c++0x by its next release cycle (ie the next release after 2.9 which is imminent). I just hope they'll sort the platform dependent bits of libc++ soon, because on linux it still requires to be linked with gcc's libsupc++ to provide exception handling stuff.

Reply Score: 3

moondevil Member since:
2005-07-08


I read a story about concepts. It took long and still wasn't ready. So maybe we will see it in the future. Also a header-less C++ (like Java) would be a nice feature.


It is planned for a TR (technical release), please see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html

They just did not managed to have it as part of the newly released standard.

Reply Score: 3

Features
by vivainio on Tue 29th Mar 2011 21:12 UTC
vivainio
Member since:
2008-12-26

Page 2?!?

Anyway, here's what I'm looking forward to in rough order:


Auto

http://www2.research.att.com/~bs/C++0xFAQ.html#auto

(yay, finally! 'var' from C#)

Lambda

http://www2.research.att.com/~bs/C++0xFAQ.html#lambda

(nice for those used to 'scripting' languages like Python; I use closures all the time, much handier than classes)

Initializer lists

http://www2.research.att.com/~bs/C++0xFAQ.html#init-list

Rvalue references

http://www2.research.att.com/~bs/C++0xFAQ.html#rval

Reply Score: 2

RE: Features
by phreck on Wed 30th Mar 2011 08:48 UTC in reply to "Features"
phreck Member since:
2009-08-13

The new auto is even better than C#'s var in that it allows multiple declarations. That can be very handy depending on code-style:

auto inprecise_pi = 3.14159,
inprecise_pi2 = 2 * inprecise_pi,
inprecise_sqrt_pi = sqrt (inprecise_pi);

whereas in C# you are forced to:

var inprecise_pi = 3.14159;
var inprecise_pi2 = 2 * inprecise_pi;
var inprecise_sqrt_pi = sqrt (inprecise_pi);

Reply Score: 2

RE[2]: Features
by transputer_guy on Wed 30th Mar 2011 16:23 UTC in reply to "RE: Features"
transputer_guy Member since:
2005-07-08

us_pi = 3,

According to Huffington Post there is legislation pending from Martha Roby (R-Ala.) to declare Pi as 3. This seems to have widespread support of Republicans, what more can one say!

Reply Score: 3

RE[3]: Features
by jim9000 on Wed 30th Mar 2011 17:22 UTC in reply to "RE[2]: Features"
jim9000 Member since:
2011-03-30

http://roby.house.gov/press-release/%E2%80%9Cpi%E2~...

"The “Pi” story is a hoax and is untrue. It was written by a liberal blogger in the comedy section of the Huffington Post. No such bill exists, as evidenced by a quick check of http://thomas.loc.gov/. Thank you for not falling for the joke (even though it is humorous)."

Reply Score: 2

RE[4]: Features
by ameasures on Wed 30th Mar 2011 19:01 UTC in reply to "RE[3]: Features"
ameasures Member since:
2006-01-09

"The “Pi” story is a hoax and is untrue."


Brings to mind the British Member of Parliament who was allotted time to ask a minister about "the decline in the export of merkins?" .... in the debating chamber.

After much research he discovered that a merkin was a 16th century word for a wig ... for the other place humans grow hair!

Similarly puerile ... and charming!

Reply Score: 2

someone explain C++ popularity?
by project_2501 on Tue 29th Mar 2011 21:49 UTC
project_2501
Member since:
2006-03-20

Can someone please explain C++ popularity?

I've worked with a number of languages and I just don't get where C++ sits in the problem space. It's not close to the hardware like assembler. It's not a representation of human concepts like lists. It's not a designed to minimise the jump from human idea to computer language. It's not designed to be a declarative (descriptive) language.

All the clever stuff with C++ seems to be effort into the wrong place. You could do it all in C just in longer form - but becuase the language and rules of C are simpler there is less scope for error and readability by someone else is greater. Probability of error and readability in C++ seem to be very poor.

I would even go so far as to say that you could most easily obfuscate code with C++. It effectively allows you to totally hide both the low-level effects and also the semantics of what you're doing really easily.

So why the principle of "simplest language, least error" not given much weight in C++, are the benefits so great? What are they?

Reply Score: 4

RE: someone explain C++ popularity?
by olafg on Tue 29th Mar 2011 22:27 UTC in reply to "someone explain C++ popularity?"
olafg Member since:
2010-05-27

The popularity of C++ is easier to explain than the popularity of Objective-C…

Both languages allow you to optimize for speed when you need it. That's why C++ is popular, that and OOP + operator-overloading which allows you to create your own efficient ADTs, for say 3D engines.

Reply Score: 3

RE: someone explain C++ popularity?
by rom508 on Tue 29th Mar 2011 22:35 UTC in reply to "someone explain C++ popularity?"
rom508 Member since:
2007-04-20

Two main reasons:

1) Good compatibility with C. This is important when you want to do systems programming. Most operating systems and system libraries are written in C, so for example, if I want to program in Ada and I need to have the ability to call system library functions, etc., I need Ada bindings. With C++ you can use all C constructs directly.

2) Object-oriented programming model. You can do OO programming in C, but it's a bit more effort and requires discipline and experience. Certain programming constructs are expressed better with OO paradigm. I mainly write C code, however when needed I tend to write C code that uses abstract data types, inheritance and polymorphism. If you have a large team of programmers C++ makes OO programming more formal, this makes it easier for inexperienced programmers to write conforming interfaces.

Personally I'm not keen on C++, I find it too messy and wacky. The language as a whole has too many holes, i.e. it allows you to do things which result in undefined behavior and are hard to debug. I would really like to switch to Ada 2005, however until major Unix platforms (Linux, BSD, Solaris) decide to fully support Ada and provide complete Ada bindings for all their system libraries, I will stick with C.

Reply Score: 4

project_2501 Member since:
2006-03-20

Thank you for your response - I appreciate it. I am still not convinced.

(1) You can bind to C using lots of other languages. If you're primarily doing high level programming - you shouldn't need to do this often. So I still don't see why we pay the price of C++ just for this reason. Binding to C is done rarely and therefore the effort can be done there .. eg Python to C bindings. The majority of time is spent doing high level coding in a nicer language.

(2) There are lots of other much less hazardous OO languages. Again why use something like C++ to gain the safety and convenience benefits of C++ when the language itself has so many pitfalls that negate these benefits?

I can only conclude that C++ is a macho choice. Like driving manual cars whenin fact automatic or even driver-less cars would be safer, more convenient, but just wouldn't be seen as macho.

I'm still open to ideas ... keep them coming.

Reply Score: 2

dsmogor Member since:
2005-09-01

C++ was just at the right place/ right time.
It capitalised on C syntax popularity (java, c# in turn capitalised on C++ syntax ) and delivered good natural integration with existing C code / libs.
Other languages / runtimes provide some support for C ABI but none of them can consume C headers directly. This made C++ a natural "upgrade" path for projects that were moving up abstraction ladder.

Current popularity is mostly outcome of that reinforced by excellent tool support (hundreds manyears of optimization compiler research) and availability of libs of all kind (both low and high level).
Actually, when used dilligently it delivers.
It's biggest advantage is that the progammer has a big freedom in deciding how highlevel his/her code is going to be. From the C/asm level to almost java levels with a good library (ask QT devs). And all of this in a single codeset! Most advanced / dangerous features are for use of libs developers, usuall code cruchers will get by by using only a small subset of the language and sticking to usage patterns mandated by the standard lib of choice.

Edited 2011-03-29 23:44 UTC

Reply Score: 5

vivainio Member since:
2008-12-26


(2) There are lots of other much less hazardous OO languages. Again why use something like C++ to gain the safety and convenience benefits of C++ when the language itself has so many pitfalls that negate these benefits?


C++ is an industry standard, cross platform, vendor neutral language without a fat runtime (i.e. runs on metal). It will be around long after C# and Java (both vendor specific languages, to varying extent) are gone. C++ is not a lot "worse" than those languages, esp. after C++11, and it will always be faster and have leaner memory profile in practice.

With Qt being LGPL and C++11 coming, C++ is more relevant than ever.

The pitfalls of the language are not really a problem unless you want to make it a problem, i.e. write contorted code. Libraries like Qt mostly eliminate the memory management headaches, which has been the main gripe against C++.

Reply Score: 5

dsmogor Member since:
2005-09-01

Just a question, how well is QT and C++0x goodies playing together?

Reply Score: 2

vivainio Member since:
2008-12-26

Just a question, how well is QT and C++0x goodies playing together?


Didn't try yet, but my current assumption is there will be no problems with any of the features.

I would expect Qt to gain some new goodies like initializer lists for containers as the standard gets deployed. Qt can also deprecate some features that are now provided by the language itself (foreach).

Reply Score: 2

MacMan Member since:
2006-11-19

I would expect Qt to gain some new goodies like initializer lists for containers as the standard gets deployed. Qt can also deprecate some features that are now provided by the language itself (foreach).


Yeh, kind of how they've adopted std::string instead of QString and std::vector instead of QList and std::map instead of QDict???

Why use something standard when you can roll your own.

Reply Score: 1

ndrw Member since:
2009-06-30

3. C++ was around when Microsoft was deciding the language to write most of their software in.

Just like Obj-C, which unless picked by Apple would be a yet another language used only by enthusiasts.

To me, C++ is lacking only one feature - a garbage collector. GC isn't only for convenience, it allows more abstract data structures be used in the API. In C++ a function/method may take objects as parameters and return objects but someone has to specify who is responsible for their allocation and, more importantly, for cleaning them. Often, if the object is a part of a larger data collection, or if is being passed between object many times it is simply impossible to decide who should clean it up.

This is why most of frameworks written in C++ still feel like a set of C functions (operating on primitive data) conveniently grouped into classes.

Reply Score: 3

dsmogor Member since:
2005-09-01

There are number of GC solutions for C/C++ info form of libraries. One of them is even used in GCC compiler code AFAIK.

Reply Score: 3

ndrw Member since:
2009-06-30

You're right, they are. But that brings another issue to the table:

Many C++ features are not standardized or were standardized late. This led to proliferation of alternative incompatible implementations. That's OK for application code an single libraries but not good for frameworks.

Say, you want to use some imaginary Qt and Boost at same time. But then you find out that one of them requires GC #1 to handle the memory, while the second has standardized on GC #2. Oops!

This is not just about GC, same thing happens when you want to reuse any abstraction in two different frameworks, although here you may have some luck with wrapping or monkey patching.

Reply Score: 2

MORB Member since:
2005-07-06

Regarding garbage collection and objects ownership, shared_ptr and weak_ptr help a ton (and you can have them using boost in pre c++0x compilers).

There's the downside compared to GC that you have to be careful to avoid cycles, but on the other hand the deterministic aspect of it (objects are finalized as soon as no one needs them anymore and not some indefinite time later on) make some things easier than with GC.

Reply Score: 4

Tuishimi Member since:
2005-07-06

I would really like to switch to Ada 2005, however until major Unix platforms (Linux, BSD, Solaris) decide to fully support Ada and provide complete Ada bindings for all their system libraries, I will stick with C.


Just for liking Ada, I like you.

Reply Score: 2

ricegf Member since:
2007-04-25

I invested several full-time years into Ada 83, and moved some of the code to Ada 95. In my experience, Ada had the pleasant property of minimal debug - if we could get our code to compile, because of the explicitness, it would probably work pretty well.

I rather miss that.

I can't find a reference now (and my memory may be off - if you have a reference pro or con, I'd be much obliged), but I recall that in the twilight of the Ada Mandate, a commission studied what was required to launch Ada as a successful commercial language. The commission recommended that the government invest either $15 million (which would make Ada a success) or $0 million (which would allow Ada to fail), because anything less than $15 million wouldn't achieve widespread success anyway.

Naturally, the government "saved" money by investing $10 million.

The US fiscal crisis distilled.

Reply Score: 3

Tuishimi Member since:
2005-07-06

I don't (have a reference)... but I love Ada. My favorite language but no one uses it. I love the rigid explicitness, even with "pointers", and then there is the surprising power of attributes... just a great language!

Because PL/SQL is loosely based on Ada it's the only thing that makes working with an Oracle database bearable. ;)

My second favorite language is very different in many ways from Ada: euphoria. Again, not an oft-used language. Ah well. For work it's all Java with a smattering of Ruby and Php.

Reply Score: 2

boldingd Member since:
2009-02-19

I'll join the OsNews Ada fan-club. I had to use Ada for a project a year ago, and I really loved the language. It managed to include a lot of the higher-level features that C++ added to C -- like an exception mechanism, implementation-hiding, classes and polymorphism -- in a much more predictable and consistent fashion.

The biggest thing that keeps me from actively using it is how verbose and picky it is -- I can't be as rapidly productive in Ada as I can in C++. A great example is string handling. IIRC, strings of different lengths are considered to be different sub-types, and their ranges are considered to be different sub-types. This makes operating on groups of strings More Work than it Should Be -- your code gets bogged-down with lots of specific type conversions (to map the range of one string onto the range of another), any one of which could potentially raise a range error.

Reply Score: 2

Tuishimi Member since:
2005-07-06

True, but if you make a mistake, you know about it. ;) You could also write your own unb ound dynamic, or even fixed dynamic string package. (Been there, done that - loved the old Booch utilities).

Reply Score: 2

moondevil Member since:
2005-07-08

In the TIOBE index Ada has been steadily rising since early 2010.

http://www.tiobe.com/index.php/paperinfo/tpci/Ada.html

No idea how to explain it.

Reply Score: 2

RE: someone explain C++ popularity?
by copx on Tue 29th Mar 2011 23:11 UTC in reply to "someone explain C++ popularity?"
copx Member since:
2008-02-05


All the clever stuff with C++ seems to be effort into the wrong place. You could do it all in C just in longer form - but becuase the language and rules of C are simpler there is less scope for error and readability by someone else is greater.

With C++0x that's definitely no longer true. "constexpr" alone makes C++ a better C. The new strongly typed enums are less error-prone than C enums, templates are less error-prone than function-style macros (IF you use them only like function-style macros - not talking about advanced template voodoo here). Etc.
I only do C-style programming (no OOP, no template voodoo, no STL), and C++0x is clearly superior to C99 for that IMO.


I would even go so far as to say that you could most easily obfuscate code with C++. It effectively allows you to totally hide both the low-level effects and also the semantics of what you're doing really easily.


Yes, it's possible to write code in C++ where you have to look all over the source base to parse a single line of code. However, nobody forces you to write code like this. You can write utterly hard to parse code in plain C, too. The preprocessor alone is worse than anything C++ added.

Reply Score: 4

TheMonoTone Member since:
2006-01-01

C++ tends to fill the space of high performance application that still want the syntax niceties so RSI doesn't set in for the developer team. Think any large multimedia production suite or game development kit and its almost always going to be C++ in some form or another. C++ is really different languages to different groups and individuals.

While C is ok for large programs at some point you want your inheritance and virtual functions without the cost of a hash table lookup (like in a higher level language such as python) and well, C++ adds that just-enough syntax goodies to make it worth the added pain of readability sometimes.

But most of the time I'd agree, C is overall the better easier to read language, if only humans never got RSI and man hours were infinite.

Sometimes I think too, C++ can do some clever things that would be arduous to accomplish in C (though always possible). Think the Eigen matrix library for example. Its only competitor is intel's mkl at this point, both C++ template libraries that do lots of compile time optimizations using templates, yet the syntax still looks something like using a statically typed numpy.

Its really quite an amazing library and doing the same in C would require lots of macro magic that would surely turn your code in to a very difficult pile to figure out.

Reply Score: 3

vivainio Member since:
2008-12-26

But most of the time I'd agree, C is overall the better easier to read language, if only humans never got RSI and man hours were infinite.


Take a look at how OO in C looks like:

https://maemo.gitorious.org/fremantle-hildon-desktop/libhildondeskto...

Reply Score: 2

rom508 Member since:
2007-04-20

Or something like this:

#include "utc_date_clock.h"
#include <stdio.h>

/*
Object inheritance hierarchy:

simple_clock (Current time)
|
+-date_clock (Current time + date)
|
+-utc_date_clock (Current date + UTC time)
*/

int main(void)
{
/* Clock object */
utc_date_clock_t uc;

/* Constructor */
utc_date_clock_init(&uc);

/* Calls simple_clock set_time() function */
utc_date_clock_set_time(&uc);

/* Calls date_clock set_date() function */
utc_date_clock_set_date(&uc);

/* Calls utc_date_clock set_utc_time() function */
utc_date_clock_set_utc_time(&uc);


/* Cast to (simple_clock_t *) object pointer */
printf("\n");
/* Calls virtual display() function */
simple_clock_display_rtb((simple_clock_t *)&uc);
/* Calls non-virtual display() function */
simple_clock_display((simple_clock_t *)&uc);


/* Cast to (date_clock_t *) object pointer */
printf("\n");
/* Calls virtual display() function */
date_clock_display_rtb((date_clock_t *)&uc);
/* Calls non-virtual display() function */
date_clock_display((date_clock_t *)&uc);


/* Cast to (utc_date_clock_t *) object pointer */
printf("\n");
/* Calls virtual display() function */
utc_date_clock_display_rtb((utc_date_clock_t *)&uc);
/* Calls non-virtual display() function */
utc_date_clock_display((utc_date_clock_t *)&uc);


printf("\n");
/* Virtual destructor */
simple_clock_free_rtb((simple_clock_t *)&uc);

return 0;
}

atom$ gcc -O -Wall simple_clock.c date_clock.c utc_date_clock.c clocks_main.c
atom$ ./a.out
simple_clock_init() returning
date_clock_init() returning
utc_date_clock_init() returning

30/03/2011 (UTC 12:37:51)
12:37:51

30/03/2011 (UTC 12:37:51)
12:37:51 30/03/2011

30/03/2011 (UTC 12:37:51)
30/03/2011 (UTC 12:37:51)

simple_clock_free() returning
date_clock_free() returning
utc_date_clock_free() returning

Reply Score: 1

vivainio Member since:
2008-12-26

You don't have the class declarations in your example. Of course calling stuff is trivial.

Reply Score: 2

alexeiz Member since:
2011-03-30



Frankly, I can't see the forest for the trees in that code.

Reply Score: 1

vivainio Member since:
2008-12-26


Frankly, I can't see the forest for the trees in that code.


That was my point.

Reply Score: 2

RE: someone explain C++ popularity?
by MORB on Wed 30th Mar 2011 08:03 UTC in reply to "someone explain C++ popularity?"
MORB Member since:
2005-07-06

C++ is as close to the hardware as C. One of the core principles of the language is that you don't pay for features you don't use, and you know the cost of the features you do use.

I used C++ in gameboy advance projects.

C++ offers a lot of features over C that improve readability and maintainability, IF used properly. I've noticed that C++ is most often misused by people trying to be too clever instead of just doing the simplest, most obvious thing.
Look up for instance the RAII pattern and think about how much redundant (and error prone) code writing is saves you compared to C.

I also disagree that C is a very good language. For instance, people work around limitations in C by constructing lots of clever things above it, for instance using a lot of clever macros, which are an awful thing to have to rely upon. You don't end up with very clear or even standardized code.

You also have to do everything by hand, such as containers, and everyone does it differently. What's the standard way to make a linked list in C? What's the standard way to emulate object oriented programming? What's the standard way to implement a sorted container?
I could come up with such questions all day.

Another huge advantage of C++ is that a lot of incorrect constructs simply won't compile, instead of resulting into a runtime bug. The weak type system in C just doesn't cut it.

Reply Score: 4

moondevil Member since:
2005-07-08

I think that one reason why many people fail to learn C++ properly is because they just lack proper programming skills.

Many people can use C, but you need to be a good developer to make proper use of C++.

Reply Score: 5

boldingd Member since:
2009-02-19

Humbly, I think that's backward. I would argue that writing elegant C is at least as hard as writing elegant C++.

The worst C++-learning disaster I've seen was a Java developer who essentially assumed that all similar constructs in C++ must work like the roughly-equivalent Java features. In particular, he didn't get how constructors and destructors worked, and wasn't interested in learning.

I expect stories like that one are at the root of a lot of terrible C++ learning experiences -- people coming from newer, cleaner languages who aren't prepared for a language with the subtleties and rough edges that C++ has.

Reply Score: 3

moondevil Member since:
2005-07-08

Humbly, I think that's backward. I would argue that writing elegant C is at least as hard as writing elegant C++.


No it isn't. There are many C++ concepts that simply do not exist in C. You can code all your life in C, without knowing anything about generic programming, meta-programming, object orientation, functional programming, for example.

The use these paradigms properly requires good developer skills.

I expect stories like that one are at the root of a lot of terrible C++ learning experiences -- people coming from newer, cleaner languages who aren't prepared for a language with the subtleties and rough edges that C++ has.


Yep, I do agree.

Reply Score: 2

rom508 Member since:
2007-04-20

C may not be the best language ever designed, however compared to C++ I don't think C is any worse.

All the things you mentioned about C not having standard containers and algorithms is not a big issue. What people tend to do is write their own libraries, or use libraries provided by third parties.

In fact I can say the same thing about C++, until recently there was no standard way in C++ to use hash tables, or do multi-threaded programming. You had to rely on libraries from third parties. A lot of C++ programmers rely on STL, however quite a few people dislike STL for various reason. So if you tend not to use STL because you think it's flawed and not designed properly, then there is really no good reason to use C++ in the first place.

Reply Score: 2

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 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 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 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 Score: 1

MORB Member since:
2005-07-06

Done.

Here is the first test as I compiled it, on a 32 bits kubuntu linux using gcc 4.4:

#include <iostream>
#include <list>

struct struct01{ int n1; int n2; };

int main( int a, char** b )
{
std::list< struct01 > list01 { {1,2}, {2,3}, {2,3}, {2,3} };

for( auto it = list01.begin(); it != list01.end(); ++it )
std::cout << "derp\n";

return 0;
}


I've initialized the list with stuff and printed out something in the loop to make sure it's not optimized away for having no side effect. This gives additional overhead but still a far cry from what you claim, so I don't care.

Compiled with gcc 4.4.1 in i386 code, with optimization:
g++ derp.cpp -o derp -O3 -std=c++0x

The binary weights a whopping 7816 bytes. After striping (with strip -s), it's 5608 bytes.

And now for the second test:

#include <iostream>
#include <list>

struct struct01 { int n1; int n2; };
struct struct02 { int n1; int n2; };
struct struct03 { int n1; int n2; };
struct struct04 { int n1; int n2; };
struct struct05 { int n1; int n2; };
struct struct06 { int n1; int n2; };
struct struct07 { int n1; int n2; };
struct struct08 { int n1; int n2; };
struct struct09 { int n1; int n2; };
struct struct10 { int n1; int n2; };

int main( int a, char** b )
{
std::list< struct01 > list01 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct02 > list02 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct03 > list03 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct04 > list04 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct05 > list05 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct06 > list06 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct07 > list07 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct08 > list08 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct09 > list09 { {1,2}, {2,3}, {2,3}, {2,3} };
std::list< struct10 > list10 { {1,2}, {2,3}, {2,3}, {2,3} };

for( auto it = list01.begin(); it != list01.end(); ++it )
std::cout << "derp\n";
for( auto it = list02.begin(); it != list02.end(); ++it )
std::cout << "derp\n";
for( auto it = list03.begin(); it != list03.end(); ++it )
std::cout << "derp\n";
for( auto it = list04.begin(); it != list04.end(); ++it )
std::cout << "derp\n";
for( auto it = list05.begin(); it != list05.end(); ++it )
std::cout << "derp\n";
for( auto it = list06.begin(); it != list06.end(); ++it )
std::cout << "derp\n";
for( auto it = list07.begin(); it != list07.end(); ++it )
std::cout << "derp\n";
for( auto it = list08.begin(); it != list08.end(); ++it )
std::cout << "derp\n";
for( auto it = list09.begin(); it != list09.end(); ++it )
std::cout << "derp\n";
for( auto it = list10.begin(); it != list10.end(); ++it )
std::cout << "derp\n";

return 0;
}


It compiles to a vastly bloated binary of 11913 bytes. After striping, it's 9704 bytes.

Reply Score: 4

moondevil Member since:
2005-07-08

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

Great decision.

Reply 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 Score: 3

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 Score: 2

boldingd Member since:
2009-02-19

All the clever stuff with C++ seems to be effort into the wrong place. You could do it all in C just in longer form - but becuase the language and rules of C are simpler there is less scope for error and readability by someone else is greater. Probability of error and readability in C++ seem to be very poor.


You've got that exactly backwards.

Most C++ features are tools designed to solve specific, recurring problems in C. STL containers save you the trouble of implementing the same container types over and over again ad infinitum. Classes and polymorphism save you having to use nested unions-and-structs with macros to cobble together trees with heterogeneously-typed nodes. Classes, ctors, dtors, new, delete and references also give the developer powerful techniques for minimizing the amount of explicit memory management they have to do. Exceptions provide the developer much more elegant error-handling and state clean-up than return-value checking coupled with explicit in-code clean up.

All of these tools help a programmer to generate more robust code much more quickly than is possible in plain C. They allow the programmer to sometimes defer common grunt-work to the language, which saves time, reduces errors and improves readability. (Well, when those tools are used correctly; then again, sloppy C can have consequences that are just as catastrophic as sloppy C++.)

If you don't believe me, try hacking together a trivial GTK application in C, then do a Qt version in C++ (or if you feel like it, for more accurate results, use Gtkmm and C++). If your results are like mine, you'll notice that one takes a lot longer than the other.

So why the principle of "simplest language, least error" not given much weight in C++, are the benefits so great? What are they?


Because C++ is not a single, integrated language. It's C with a bunch of extra tools.

Reply Score: 4

Comment by Luminair
by Luminair on Thu 31st Mar 2011 15:52 UTC
Luminair
Member since:
2007-03-30

This debate between C and C++ has never happened before.

Reply Score: 2

RE: Comment by Luminair
by moondevil on Fri 1st Apr 2011 05:49 UTC in reply to "Comment by Luminair"
moondevil Member since:
2005-07-08

Sure it did, you are just too young to remember.

Reply Score: 2