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.
I am most interested in the inherited constructors
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.
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.
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.
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.
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
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);
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!
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).“
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!
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?
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.
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.
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.
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
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++.
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).
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.
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.
There are number of GC solutions for C/C++ info form of libraries. One of them is even used in GCC compiler code AFAIK.
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.
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.
Just for liking Ada, I like you.
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.
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.
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.
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).
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.
Maybe it coincides with military deployments or contracts or something… :/
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.
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.
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.
Take a look at how OO in C looks like:
https://maemo.gitorious.org/fremantle-hildon-desktop/libhildondeskto…
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
You don’t have the class declarations in your example. Of course calling stuff is trivial.
Frankly, I can’t see the forest for the trees in that code.
That was my point.
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.
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++.
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.
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.
Yep, I do agree.
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.
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.
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.
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).
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.
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.
Done.
Here is the first test as I compiled it, on a 32 bits kubuntu linux using gcc 4.4:
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:
It compiles to a vastly bloated binary of 11913 bytes. After striping, it’s 9704 bytes.
Sorry I made a mistake, it was some time ago when I did the tests and I don’t have the sources. It wasn’t 200K I got confused, I think the size difference was something like 2K.
Your test program is a bit simplistic, you need to call functions to insert items into list, then traverse the list, deleting every item. This is more or less what real code does.
So 2K is not a huge size, but it’s still much more than similar implementation in C. In a large program bloat from STL can add up pretty quickly.
I implemented the test program that you suggested, and mainly with the goal to dispel that bogus 200k claim. Making a more complicated test program would only allow a meaningful comparison if compared to a program doing the same thing in pure C.
If you keep comparing a concrete C++ example with some undefined “similar implementation in C”, then yes, the concrete implementation is going to lose the comparison to the imaginary implementation every time.
There are many parameters. Would the C version be implemented as inline code or separate functions? Would it use a custom allocator or not? Are we talking about a thread-safe implementation or not?
You have yet to make a compelling case that it is “bloat” and not “stuff one have to implement themselves if not using the STL”. And “pretty quickly” compared to what? How do you define “pretty quickly” in this context anyway?
I would also note that it’s probably going to take a lot longer to write the “equivalent C program.” C doesn’t have abstract containers: you get to write the linked-list implementation yourself, and you get to wade into lots of explicit memory management while you do it. The more complicated your use of those containers, the wider the difference in developer time cost is going to get.
The realization that made C++ so popular, and has made Java, C# and Python so popular after it, is that in many applications — particularly, desktop applications — greater developer productivity is significantly more valuable than the performance efficiency of the resulting implementation.
The size of the binary increased because you wrote more code (ten lists objects initialized instead of one, ten lists traversed), not because you used list with 10 different structs. If you do ‘objdump’ on the binary I think you’ll find only a single instantiation of the list.
I didn’t expect the number of different types to be a factor but I was humoring mr “OMG STL adds 200k of code for a linked list”.
So you prefer to loose productivity in order to gain 200 KB?!
Great decision.
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.
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.
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.
Because C++ is not a single, integrated language. It’s C with a bunch of extra tools.
This debate between C and C++ has never happened before.
Sure it did, you are just too young to remember.