Slashdot Mirror
Stroustrup Says New C++ Standard Delayed Until 2010 Or Later
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!"
C++0x
Yes, well, that just rolls off the tongue, doesn't it?
Maybe he can get one of those hieroglyphs like Prince.
Or C++0x0A no need to change the name.
"C++0x... Yes, well, that just rolls off the tongue, doesn't it?"
Well, it does if you just pronounce it "Cocks".
It's not a bombshell by a long measure. Anyone who had been tracking C++0x standardization process (reading comp.std.c++, and WG papers) knows that the goal of getting the standard out by 2010 was fairly unrealistic, mostly because of concepts. The joke that "x" in C++0x is actually a hex digit and not decimal has been around for several years now.
The latest version of Cobol (eagerly expected by 6 people) will also be delayed till January 2011.
Or a crowbar for anybody who thinks languages make things automatically safe.
If you are a good programmer, you can do safe programs in C++ or any other language.
If you are a bad programmer, you can't do that in C++ or any other language.
This sig does not contain any SCO code.
The headline completely misses the central part of the article and focuses on a very minor point. Everyone has known for quite a while that C++0x would actually be C++1x. There's only a few months left in 2009, so there's absolutely no surprise there. The real meat of the article is that support for "concepts", a key (and arguably the most anticipated) part of C++0x, is being dropped. That's a major disappointment to many people, including Stroustrup.
With that definition of good programmer, are there in fact any good programmers?
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
If you are a good programmer, you can do safe programs in C++ or any other language.
So it must just be that there are no good programmers. Because I haven't seen any safe web browsers, word processors, or PDF readers.
# (/.);;
- : float -> float -> float =
No new C++ features like threads, proper enum classes, or hash tables
Cause one thing C++ sure doesn't have is enough features, right?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I haven't been following C++0x, but after reading the C++0x FAQ I am very pleased. It really fills a lot of the simple, practical holes in the language.
I think the success of C# is part of why these things are being considered. For example, C# recently added an advanced form of initializer lists - which is now in C++0x. Another example is the scoping of enums, which has long been a pain. Many coding standards require enums to be ALL_CAPS_WITH_UNDER_SCORES because they don't obey scoping rules: this is fixed. NULL is now replaced with nullptr, which is a minor improvement that looks much like how this was done in C++/CLI. (That's the bastardized C++ for .NET). Namespace cleanups, foreach, ... the list is huge, and it looks like C++ is "borrowing back" from Java and C#.
Competition is good.
I know that everything I just listed probably exists in many other languages, but C# and Java are very prominent in enterprise development, and are making huge gains. I will be very very glad to see a real ISO standard gaining ground again.
C++0x is a goofy name no wonder no one wants to work hard on it. How would you like that on your resume. C+=2 is much more consistent with the language and is much easier to read.
C++ has reached staggering complexity already; I don't think adding another 40 pages of complicated features is going to make the language any better.
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. Also, even when the spec does come out, how many years before we can trust that most compilers can use it effectively... two, three? Then after we've been using it for a while, how long before books come out that tell us that we've been using it all wrong and we have to start over (ie: the Exceptional " " and Effective " " books from Sutter and Meyers)?
Okay, so I can use C++0x well in 10 years, okay I'll probably be so burned out by then I'll be a manager, or I will have convinced someone to let us use D for embedded work and something managed for everything else.
"We need a fourth law of Robotics: Stop Fingering My Wife"
Or better yet- take the crowbar and whack programmers who can't write in C++ until they leave the industry.
Because C++ is the pinnacle of programming knowledge? *giggle*
If you can't understand memory allocation and pointers, you aren't competent to be in this profession.
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. There is a reason why there are auto_ptrs in C++ and it's not because those people are "noobs", it's because people want to actually spend their time writing the program rather than having their time eaten up by writing tons of boilerplate memory management code.
"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"....
www.eFax.com are spammers
C++ can't be fixed by adding features.
C++ can only be fixed by removing features.
My minivan won't get me to Jamaica, so I need to add wings or pontoons? Or maybe I should buy an airline ticket instead?
Use the right tool for the job. Sticking another bag on the side of a language that's almost entirely bags isn't going to fix it. If you need a better language than C++, maybe you shouldn't be using C++.
There are two basic problems with your code. First, there are unbalanced parenthesis. Second, this is a thread about C++. Not Perl. Next time, be more careful. Thanks.
Some years ago, the C++ committee went off into template la-la land. Most of the work there focuses on template features that will be used by few, and used correctly by fewer.
Templates are useful, but "generic programming", doing arbitrary computation at compile time with templates, was a terrible idea. Templates can be abused as a recursive term-rewriting system, and through some clever and obscure tricks, recursive computations can be run at compile time. As a programming language, this trick is awful; awful from a syntax point of view, awful from an understandability point of view, and awful from a debugging point of view. If you need to do work at compile time, there have been much better approaches. LISP "macros" were standard LISP, not a second language. And even they created such a mess that Scheme had to be invented to clean out the language.
Orignally, templates were conceived as a saner way to do what C programmers did with macros, providing a way to have some type independence at compile time. But the template crowd got out of control.
The obsession with templates has led to a neglect of things C++ really needed, like better memory safety (C++ still has buffer overflows, and most of the security holes today stem from this), and better approaches to concurrency (the compiler has no idea what locks what, and it needs to know). Anything that wasn't template-related tended to be ignored by the committee.
The result of this failure has been C++ spinoffs - Java, C#, etc. Even Objective C has made a comeback in the Apple world. C++ has never even been able to displace C, twenty years on.
I've written a lot of C++, and I'm disgusted with this mess.
There is nothing they can add to any language that cannot be done effectively with C and C++ with a good support library like BOOST and STL.
The whole point of concepts was to make C++ libraries that heavily rely on templates, such as STL and Boost, easier to use. As it is, C++ templates are effectively compile-time duck typing, which means that error is reported not at point of call, but where it actually leads to non-compilable code produced during template instantiation (which is usually inside the library you're calling). Ever made a mistake while calling boost::bind (or, Heaven forbid, while using Boost lambdas)? Do you remember what the error message looks like when it happens?
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.
The problem is the amount of C programmers/thinkers who think they're writing C++ just because they type "class". It doesn't work that way, C++ is a totally different language.
eg. If you're Doing It Right then it's impossible to get a "buffer overflow" in C++. Most of the exploits you see are down to buffer overflows so I leave you to draw your own conclusions about the programmers.
Problems with C++ that will catch C programmers:
No sig today...
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.
No sig today...
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.
Any garbage collected language requires more memory to operate than the program actually needs.. Otherwise you'd be garbage collecting 24/7. So yes, if you want to minimize GC cycles/pauses, your memory usage can be vastly higher than what the program would actually require in a traditional language. That's probably the big reason, for example, that the iPhone doesn't support GC in its Objective-C implementation.
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.
I used to have a better sig but it broke.
Take a look at something like Acronis TrueImage (or any Norton program) before/after their transition from C++ to C++-with-C#-user-interface.
As someone who worked in Acronis, and wrote a bunch of code for True Image, I feel obliged to tell you that there's no C# code in it at all - it's all pure C++. Acronis SDK (which is a separate thing, and IIRC comes only with True Image Enterprise) has component that exposes .NET API, and that's written in C#, but it's separate from True Image proper, and those C# APIs are just sanitized wrappers on top of the original COM API (which is implemented in C++), and, in fact, most of C# code there is automatically generated from COM interfaces (I know that because I'm the guy who originally designed that part of it).
As for GUI in True Image (and pretty much all other Acronis products) - it's FOX Toolkit, or rather, forked and heavily-customized version of it (since it's LGPL'd, you can request the source code with customizations here).
anything which continually scans the entire heap when you're out of RAM is a showstopping problem and makes GC useless for real applications.
Luckily, GC has advanced since the 1960s.