Stroustrup Says New C++ Standard Delayed Until 2010 Or Later 501
wandazulu writes "At the end of an article written by the creator of C++, where he talks about removing a feature from the new C++ standard, he drops a bombshell: The new C++ standard (typically referred to as C++0x) has been delayed until 2010 or later. What does this mean? No new C++ features like threads, proper enum classes, or hash tables. C++0x is dead, long live C++1x!"
Poorly worded (Score:1, Interesting)
"No new C++ features like threads, proper enum classes, or hash tables"
"Concepts" is the only thing being removed from the new standard due to time constraints (which is a shame since they seemed like a great new feature).
I think you meant to say 'No new C++ features .... _until next year at the earliest_'
Of course if you want to try some of the new features in the meantime feel free to checkout the expiremental branch of gcc [gnu.org] geared towards implementing C++0x.
Re:How about a REAL C++ feature.... (Score:3, Interesting)
Forget about type safety... just give me the "auto" variable type [wikipedia.org]. :P
Re:How about a REAL C++ feature.... (Score:1, Interesting)
The unchecked bloat that is being output by these latest college grads who know nothing but c#, vb, and java are serving no one's interest besides the hardware vendors.
That's funny cause I've never seen a single C# or Java apps that uses as much memory as C++ programs like Firefox (currently using 350 megs of RAM) or OpenOffice.org (current using 250 megs of RAM). On the other hand I have 5 different .NET apps and a Java app running and their combined RAM usage isn't even 200 megs.
But will they be useful without concepts? (Score:5, Interesting)
"Do you really want to hold back all the other very important features like lambda, rvalue references, variadic templates, type deduction etc. just because of concepts?"
Unfortunately, without concepts, many of the templates that would make features like those REALLY powerful aren't implementable due to silly things like the compiler insisting upon being able to instantiate member functions that don't make sense for a class and won't be used, just because there isn't a means to tell the compiler "and if this member doesn't make sense, just don't instantiate it, and throw an error IF AND ONLY IF somebody tries to use it." (and yes, I know about SFINAE, but that gets REALLY UGLY to do).
I've been bit by this, where I ended up having to create two completely separate template classes, one for objects that don't have sub-members and one for objects that do, just because I couldn't tell the compiler "Look, if operator . doesn't exist for this method, then don't worry about it!"
That said: I will say, I felt that some of the implementation details of concepts felt "forced" to me, in the same way that the streams library feels "forced": they "hacked" (in the bad way) the library in using language semantics that weren't a good fit.
<sigh/> - I hope the extra time will allow them to put a bit more polish on how you actually express things, and make it feel less "forced"....
Re:How about a REAL C++ feature.... (Score:4, Interesting)
Re:So in reality we shouldn't use it until 2015 th (Score:5, Interesting)
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade.
I would disagree on this part. I'm already using some C++0x features actively in production code, and I can say that they are well worth it. Lambdas are extremely handy as they finally let you use STL (and Boost) algorithms properly without lots of unneeded hand-waving. This may sound a minor thing, but remember how things have changed in C# world when anonymous delegates were introduced in C# 2.0, and their syntax simplified in 3.0? All of a sudden, everyone shifted to functional ("LINQ") techniques of writing code, abandoning hand-coded loops. The same thing happens here.
The second big part is rvalue references. They really do give major performance benefits for STL containers, especially of user-defined types (as smart implementations of C++03 already optimize their containers for standard types to avoid copy by using swap instead - but they can only legally do it for types they control...).
One other thing. C++0x may take a while to be released, but you'll see quite a few of its features in production-quality compilers before the spec is finalized. I've already pointed out that some are in VC++2010. There's even more in newer g++ versions (IIRC, they implement all that stuff, and also variadic templates). I've also seen mention of rvalue references and lambdas in the feature list of the most recent C++Builder release. All in all, this means that you'll have them at your disposal within a year or so one way or another.
Re:How about a REAL C++ feature.... (Score:3, Interesting)
Lynx vulnerability [securityfocus.com]
Re:How about a REAL C++ feature.... (Score:3, Interesting)
So, if I'm understanding your argument, there are good programmers, but none of them are actually trying to program securely.
They could stop writing vulnerabilities if they wanted to...
Re:How about a REAL C++ feature.... (Score:5, Interesting)
That's funny cause I've never seen a single C# or Java app.
Where are they? If C# and Java are so great, where are the apps? It's been, what, twelve years since it was announced that they'd take over the world and make C and C++ obsolete but I've yet to see a C# or Java program that wasn't some simple sort of utility or the GUI layer over a C++ app (eg Norton products).
What I have noticed is that all those "GUI layer over a C++ app" programs are enormous. 200Mb for a disk backup program (both Norton Ghost and Acronis TrueImage went from 20Mb to 300Mb during their transition-from-C phase and neither of them seems any better off for it.
Firefox memory usage is a mystery to me. I can't conceive of how it uses so much memory just to show a few pages of text with embedded images. The other browsers aren't really far behind though so maybe I'm missing something.
Re:How about a REAL C++ feature.... (Score:4, Interesting)
To make the comparison fair, you should be measuring Firefox against a more or less even-featured competing web browser written entirely in
I'm not saying Firefox and OpenOffice are especially lean applications. They definitely do seem like resource hogs. But the most logical explanation for the lack of proprietary or open source Java and
Re:And nothing of value was lost (Score:1, Interesting)
lack of garbage collection.
Really. I hear this a lot yet I have yet to believe it. C++ creates very little garbage because of destructors. If you're fooling around with new and delete then you are a poor C++ programmer. Smart pointers fill pretty much all of the gaps. The remaining one is where you have mutable cyclic graphs. The only way of cleaning them up is with a scheme that equates to garbage collection. I don't think I have ever had one of those in any program I have ever written.
Re:How about a REAL C++ feature.... (Score:4, Interesting)
Just because one can understand memory allocations and pointers doesn't mean one wants to have to deal with them manually in all their programs.
I fully agree with this. I've learned all about the use and necessity of pointers and allocation, and I've done my time with the debugging and memory leaks because I didn't do it right. Lots of great lessons from that. And I can really appreciate languages that handle that for me so I don't have to fuck with it. It saves me so much time and frustration.
Although it irks me that colleges start people off with these languages now. Most students I teach were brought up on a strict diet of Java and so to them, variable declaration is just a formality and pointers (or references, as the Java people insist) are just part of the magic that happens behind that friendly, colorful compiler.
These are the types I fear for in the industry.
Re:And nothing of value was lost (Score:5, Interesting)
I think bigger problems are C++'s complexity, the presence of pointers, the use of include files, and the lack of garbage collection.
Funny - I see all of those things as advantages.
Re:How about a REAL C++ feature.... (Score:3, Interesting)
If C++ wasn't based on C, it might have been a decent language...
OOP, metaprogramming, RAII, exceptions are all decent concepts. Too bad it also inherited C's "arrays are just pointers" idiom, and extended C's already stupid grammar to the point of grotesqueness. And it's not going in the right direction nowadays either. The syntax they chose for lambdas in C++0x is awful.
Re:How about a REAL C++ feature.... (Score:5, Interesting)
Back in the day they used to have little children crawling around under cotton stipping machines. The children were needed to pick up fluff and other debris that would cause the machine to break the thread it was working on. Some children would get crushed in the machine because they weren't fast enough to get out of the way etc.
C++ is a bit like that machine. It works fine if you have the luxury of being able to pick only the fastest most able children but there comes a time when you need to grow your business beyond the limits of what the best can achieve. At that point you need to either accept that some of the less able children will get crushed (bugs in the code) or you need to make the machine safer. It's often cheaper and simpler to make the machine safer and hopefully those most able children will then be able to perform more complex and hopefully profitable work.
To paraphrase... everytime you argue for a language without safety features god kills a child.
Re:Template la-la land. (Score:3, Interesting)
Templates are what makes programming in C++ a joy compared to other languages. And concepts would have completed the generic programming framework in C++. Concepts are like typechecking for templates. With templates + concepts, programming in C++ would have been almost as elegant as Haskell, except 10 times faster.
Without generic programming you not have typesafe containers, no smart pointers, no typesafe variadic functions. In fact templates have almost replaced OOP in C++ - libraries like ATL use templates for compile time polymorphism, instead of runtime polymorphism using virtual functions.
I suggest you read Alexandrescu's Modern C++ Desing before commenting on generic programming. Modern C++ is not the C++ of 1990s.
Re:How about a REAL C++ feature.... (Score:3, Interesting)
Like the guy who wrote Hello, World. Completely safe.
It is because of both it's triviality and the fact it doesn't deal with untrusted data (or any data).
Real systems are a lot more complex and they often have to deal untrusted data. Noone is perfect and it is almost a certainty that a coder will overlook something or make an incorrect assumption sooner or later. Of course some coders will do it more often than others. If they are lucky they spot it during testing and/or it is not exploitable. If they are unluky they have just introduced a security hole.
You can reduce the bug rate in code by hiring better programmers or by doing a lot more testing and inspection of code, but you quickly get into very high costs and diminishing returns and some bugs still slip through (see: NASA).
C (and some C++ subsets*) has very little checking built into the language. As a result of this it is easy to end up with bugs that allow overwriting memory the code was never meant to even touch and thus allowing injection of code.
*C++ is a huge language (it's not quite a strict superset of C but it's pretty close) with an even bigger standard library. Some constructs in it are much safer than others and so it's vulnerability depends on what subset you work with.
Re:How about a REAL C++ feature.... (Score:4, Interesting)
The use case for auto is stuff like this:
There's absolutely no good reason why I have to spell out the map type in full twice on two adjacent lines of code. Yes, one can use typedef, but it actually makes code harder to read (I'd rather see std::map<...>, and immediately know what is meant, than see MapOfFooBar, and try to guess if it's std::map, or std::multimap, or maybe one of the fancy Boost containers, or a custom class). With auto, this becomes:
Re:How about a REAL C++ feature.... (Score:3, Interesting)
And there are times when you want the memory management code for performance, and you can't get to it.
That's actually one thing I appreciate about C# over Java - it defaults to GC and memory safety, but it also has raw pointers with arithmetic, stack allocation, unions, and unchecked fixed-size buffers for when you need them.
Re:But will they be useful without concepts? (Score:4, Interesting)
Oh I remember those days. Less good than you imagine. The language might have been simple but the compilers were a complete bitch. Some of them were not even compilers, they were preprocessors.
They would throw up the type of errors that Visual Studio did when I tried to compile Google Chrome when it came out, 'Type *QWUejw::int(*float) is not equal to *QWUejw::int(*float)'. So instead of taking a week to write your code you could spend three days coding and a month debugging the compiler.
Thats the real reason everyone jumped onto Java. It was clear that C++ was the product of very confused minds but it was the successor chosen by AT&T labs themselves, it was odds on to win. The only other player in the game was Objective C which was being touted by Steve Jobs, but you had to have a $!0,000 NextStation game cube to run it on. Eifel was maybe interesting but looked highly unlikely to win.
Switching away from c++ is difficult. (Score:3, Interesting)
Every time I try to start using some other language, it fails. Mostly because other languages do not provide necessary tools to build correct programs.
1) java failed to support variables in stack, and the whole VM/GC thing is horrible.
2) haskell failed in supporting for-loops (MapM_ is not exactly the same thing)
3) erlang failed when it made it too difficult to use existing libraries made with some other language
4) python failed when it's performance is not very good
5) C# failed because it's from microsoft
6) C failed because of it's lack of support for abstractions
So I keep coming back to c++ every time. It provides combination of performance, low level programming, high level programming, good abstractions, rich tools to build your programs, proper tools for debugging your programs, plenty of libraries available, caveats are well known and workarounds exists, and it keeps working year after year without any compability problems in all supported environments.
C++0x dropping concepts is a big news. This is because c++ is important. It also means that the concepts proposal was not good enough. Only the best proposals will survive. If concepts needs to go, then they go. C++ is too important to get ruin by proposals that do not work or leads programmers to deadends. Concepts looked like a fine proposal at first, but seems it was still not good enough.
This might make other languages think they're progressing faster and providing new features faster. The other languages are still struggling to provide even basic support for things that programmers need. It's not the new features that the languages provide that determines if the language is useful. It's what the language fails to provide that counts. If there are big gaps in it's support, the tool is just unusable for use.
Re:How about a REAL C++ feature.... (Score:3, Interesting)
He's only putting auto_ptr pointers on the stack, not whole objects. That is what he meant by "automatic".
But also don't discount putting things on the stack. It's not a good idea if your functions are recursive, but for leaf functions it is. I just did some tests today, replacing a stl stringstream with a 256 byte stack buffer and using snprintf and it literally was 4 times faster. I wasted some time trying to improve the stringstream, by putting it outside the loop and clearing it instead of recreating it each time, and performance got worse (I think because the only way to clear it is to do s.str("") which created a temporary std::string and the compiler was too stupid to remove it). Changing the called code to take a const char* instead of a const std::string& did improve it about 1.5 times, but that was just doing a portion of the conversion to old fashined C code, and was still worse than the one that kept the std::string and used the buffer.
Anybody who claims C++ stl stuff is just as fast is lying. They are safer (for instance nothing stopped me from sending the wrong number to snprintf, and my code did truncate if the answer was too big for the buffer, though I knew that the input (identifiers) would never be that long). But they are never faster, even compared to rather stupid code. I'm sure if I went and replaced snprintf with various strlcat calls it would be even better.
Re:How about a REAL C++ feature.... (Score:3, Interesting)