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!"
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Re:How about a REAL C++ feature.... (Score:5, Insightful)
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.
And nothing of value was lost (Score:1, Insightful)
Why the #$%! do computer scientists believe that languages are like movies and you need to release a sequel? 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. Language-specidic Threads? Enum classes? Hash tables? All of those are ALREADY possible without another language being introduced.
The purpose of new languages? To sell books. To sell compilers. To keep academics publishing about their new inventions. But lets face it, we have enough languages now. If you can't accomplish what you want to do in a relatively short time with the options that are now available, the problem isn't the language.
Re:Headline misses the point completely (Score:5, Insightful)
Yeah, but it is reasonable. Concepts are a complex feature, and C++ is an (overly) complex language. 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?
Re:How about a REAL C++ feature.... (Score:5, Insightful)
Re:How about a REAL C++ feature.... (Score:5, Insightful)
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.
Re:And nothing of value was lost (Score:1, Insightful)
Why the #$%! do programmers believe that operating systems are like movies and you need to release a sequel? There is nothing they can add to any operating system that cannot be done effectively with Windows 3.1 with a good virus scanner. Multitasking? Network support? Memory protection? All of those are ALREADY possible without another operating system being introduced.
The purpose of new operating systems? To sell licenses. To sell books. To keep journalists publishing about their new registry tricks. But lets face it, we have enough operating systems now. If you can't accomplish what you want to do in a relatively short time with the options that are now available, the problem isn't the oeprating system.
Comment removed (Score:5, Insightful)
Re:How about a REAL C++ feature.... (Score:3, Insightful)
"Can" does not imply "must".
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Or better yet- take the crowbar and whack programmers who can't write in C++ until they leave the industry. If you can't understand memory allocation and pointers, you aren't competent to be in this profession.
Re:Namespace (Score:5, Insightful)
Re:How about a REAL C++ feature.... (Score:3, Insightful)
who cares? (Score:5, Insightful)
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.
So in reality we shouldn't use it until 2015 then (Score:5, Insightful)
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.
Re:How about a REAL C++ feature.... (Score:5, Insightful)
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.
Re:And nothing of value was lost (Score:2, Insightful)
If so, then you haven't stumbled upon C++'s many problems. Like, lack of rvalue references. Or, lack of a proper lambda.
I think \bigger problems are C++'s complexity, the presence of pointers, the use of include files, and the lack of garbage collection.
Forty acres and a flying car... (Score:5, Insightful)
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++.
Re:But will they be useful without concepts? (Score:2, Insightful)
The problem with the current proposal is that it tried to be too many things to too many people. Concept supporters need to regroup and come up with a streamlined concepts proposal that concentrates on making the language easier and simpler.
Template la-la land. (Score:5, Insightful)
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.
Re:And nothing of value was lost (Score:5, Insightful)
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?
Re:How about a REAL C++ feature.... (Score:5, Insightful)
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:
Re:C++0x is really good though (Score:5, Insightful)
but C# and Java are very prominent in enterprise development, and are making huge gains.
When discussing languages with coworkers, I've frequently opined that C# is the best thing to have happened to Java in many years. Java had stagnated for a long time without any competitive threat to its domain, which eventually caused me to stop developing in it entirely and focus on C++/Qt.
A couple years ago, I looked into it again out of curiosity, and saw how far it had come since the introduction of a credible competitor (C#). Swing (it's GUI system, for those who aren't familiar with it) had gotten fast, printing turned from a lame dog into a sports car, and the core language had gained features it lacked until they appeared in C#.
As much as I despise Microsoft, the competition has been fantastic for Java.
Re:And nothing of value was lost (Score:3, Insightful)
Funnily enough, all the features you mention are ones which CAN be fixed with "a good support library".
(Apart from the include files...)
Re:Headline misses the point completely (Score:4, Insightful)
Any topic (Score:4, Insightful)
Any topic that involves geeks and C++ is just asking for flame wars, I'll submit my name to the mix.
Although I've been coding in c++ for more years than half of you have been alive, and am rather biased, I feel good programmers write good code independent of the language they use.
Re:Headline misses the point completely (Score:3, Insightful)
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Re:in related news... (Score:1, Insightful)
Re:Template la-la land. (Score:5, Insightful)
You mean C++ being a clusterfuck of ugly syntax isn't a reason for using C?
I learned C++ first. I thought the 'limitations' of C were silly and archaic. Then I grew up and realized that having straight-forward, easy-to-maintain code is much more important. /feeding the troll
Re:How about a REAL C++ feature.... (Score:1, Insightful)
And how do you think those other languages were written?
Re:C++0x is really good though (Score:3, Insightful)
I'd still lurrrrve to see properties in Java.
Re:How about a REAL C++ feature.... (Score:4, Insightful)
And btw before someone mentions something like Azureus as a counterexample, I've seen Firefox still eat up more RAM than that program if they are running for the same period of time and that's with about 10 or so torrents running in it.
And just as pointlessly, I've seen Photoshop eat up far more memory than my Java "Hello World" program. Seriously, pitting a modern web browser to a BitTorrent client to compare the languages used to code them is beyond absurd.
As someone else noted below, compare Azureus's memory footprint (as well as speed and responsiveness) to uTorrent, which has virtually identical functionality to Azureus but is written in C++.
Re:How about a REAL C++ feature.... (Score:3, Insightful)
"Could that be because Bjarne first named it "C with classes"?"
It's because writing good C++ requires a lot of patience and self-discipline, something that most "programmers" simply don't have (or they're always up against a deadline or some other excuse for "just get it working, we can tidy it up later",- which never happens and you go into a downward spiral).
Re:How about a REAL C++ feature.... (Score:3, Insightful)
eg. If you're Doing It Right then it's impossible to get a "buffer overflow" in C++.
Is it? STL iterators (and therefore containers) do not guarantee (and usually don't provide) any bound checking, so they aren't really any safer than good old memcpy in that respect.
Re:And nothing of value was lost (Score:4, Insightful)
The big problems with GC are:
a) Resources are more than just RAM. All files, network connections, etc., have to be manually closed in Java. There's no way to automate this (no equivalent to C++ stack unwinding) and it ends up being more work than managing RAM in C++ (where the compiler does 99.99% of the work for you).
b) Even if you're only managing RAM, a garbage collector will totally destroy your performance if you run out of it and start paging to disk. To me, anything which continually scans the entire heap when you're out of RAM is a showstopping problem and makes GC useless for real applications.
Re:C++0x is really good though (Score:3, Insightful)
I read the FAQ and I can't shake the feeling that C++0x is a joke that someone's taken way too far.
It's kind of like how I believe pop icons like Britney Spears are famous because of music industry execs betting they can make anybody famous and then trying to one-up each other when it works.
Anyway, my favorite part:
"Try to imagine what the superset of C99, C#, Java, Haskell, Lisp, Python, and Ada would look like."
I imagine it would look very similar to Common Lisp.
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Code is complex, sure, but where does the RAM usage come from? At the end of the day the data being processed is a few kb of text and some bitmaps.
Re:Oh, please. (Score:3, Insightful)
don't like new features, DONT USE THEM, this is one of the few cases where teh new version will not degrade in performance if you ignore the new features!
Re:How about a REAL C++ feature.... (Score:4, Insightful)
Complete rubbish. Compiler writers aren't stupid, they know how to optimize std::vector. Go and disassemble some std::vector code before posting stuff like this.
Re:Template la-la land. (Score:5, Insightful)
Ditto here. When I got my first "modern" PC, a Pentium 75 I wanted to learn how to program on it and got Microsoft's compiler. The books that came with it actually did a pretty good job of teaching C++. I wrote a fairly large program in C++--A program for editing VRML. I had to link in libraries for JPEG and PNG. When I saw how elegant and cross-platform these libraries were, I realized what a mess C++ was. I also realized how Object-Oriented Programming tended to paint people into a corner. I ended up having to instantiate Foo in order to access function Bar, when I should have simply written all the functions as stand-alone functions, using only the structures they needed.
By the time I was done messing around with VRML (which does in fact model well as a class hierarchy) I had come to the conclusion that maybe 10% of the problems out there require an OOP language.
Now I tend to think it's an even lower number, and I would just as soon work around it when necessary by rolling my own objects in C (function pointers, yay!).
I wrote more and more C. I haven't written C++ for myself, or professionally, in 10 years.
I know this is controversial; but I think OOP has polluted and hopelessly corrupted the minds of an entire generation of programmers. I find myself taking an interest in FORTH lately, and to a lesser extent, Lisp.
Re:How about a REAL C++ feature.... (Score:4, Insightful)
Yes, if you need to grow your business and all you can hire are dumb@$$3$ then yes, stick with Java (or C#).
Wow, so all the programmers you hire are perfect little automata that never make mistakes? Impressive! Where did you find such miracles of science?
And how much of a hit in performance are you taking when garbage collector turns on? How many times a minute does it fire and what happens to all those threads that are blocking?
Depends on the GC. There's a reason Sun provides a bunch of alternative implementations which have various performance characteristics that are better for different workloads.
On the flipside, how often do you see a crash because of a bad pointer reference, or worse, a security hole available to the world because of a buffer overflow in the code your perfectly little automata hacked up?
There was a time when people expected computers to be fast.
They also expect them to be stable and secure. Hint: speed isn't the sole requirement for most applications, and in fact isn't even the top one most of the time.
The problem with C++ (Score:4, Insightful)
The advantages of C and C++ have always been the speed of execution, and it's ability to get really close to the hardware. The problem now is that the speed of execution advantage is fading. Interpreted byte code languages like Java and C# are getting faster and faster, and they byte code has always made them more portable. Add to that that the extra complexity of C++ is often unnecessary, and you start reaching a point where more and more applications which would once have been written in C++ are now being written in C# or Java, this trend is only likely to continue with more and more applications moving onto the web, and continued improvements in the byte code languages themselves.
There is certainly still a need for C and C++, they are really the only viable languages for writing device drivers and certain core OS components, not to mention all the interpreters necessary for running all these byte code languages. The problem, as I see it, and I'm by no means an expert, is that C++ is continually trying to compete with languages like Java, which it will never be able to functionally do without giving up all of the things which make it powerful and which java can't do. Java is powerful because you don't have to worry about all the things you don't really care about, and C++ is powerful because when you do need to care about them you have the level of control you need(C# tried to allow both, but it doesn't really work that way). The more libraries and features you add to C++ to make it like java, the more complex and bloated you make it, and you're still chasing an unachievable goal because you can't make C++ into Java and you wouldn't really want to.
I'm not sure why the language is going in this direction, but it seems to me better to use C and C++ where they're appropriate and use Java/C# where they're appropriate and to stop trying to create some jack of all trades language which can't exist.
Re:Template la-la land. (Score:2, Insightful)
Okay, IAAEOC++0x (I am an expert on C++0x), one of my group's PIs is Bjarne Stroustrup and my committee consists of members from both the Indiana & Texas concepts proposal; the extended group is responsible for lambdas, concepts, variadics, for-each constructs, etc. Credentials aside, "templates" != "generic programming". Concepts were designed to provide a predicative type-system for templates [think of this as a kind-system] which allows us to get rid of most of the template metaprogramming hacks (SFINAE enable-if/disable-if, type computations, etc.). Variadics (also for templates) get rid of list-like type-computations. At the cost of adding a relatively light-weight description of an interface (think of a concept as a compile-time only interface) we can get rid of almost all of the hairy bits of template coding.
The reason why concepts was rejected is due to some of the uglier corner cases stemming from a requirement for soundness in the type-system using concepts. As we are slowly approximating second-order types with C++ (all typeful languages end up doing this to increase expressivity) there are bound to be some hiccoughs. What happened at ISO (as far as I know) came from an argument on the reflector which revolved around the default of whether a concept was auto(matically) satisfied by a type or if it must be explicit [a fairly arcane argument], in addition to the handling of associated and intermediate generated types. It is not clear if a simpler solution can be constructed for a decidable type-system.
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Most of C++'s superior performance comes back once you start using metaprogramming. Note, modern C++ does not outperform Java because of low-level bit fiddling, it outperforms Java because of its ability to do work at compile-time. Once one starts to do this, it becomes apparent just how many class hierarchies actually never require run-time polymorphism (and only polymorphism at compile-time). As a result, the actual class hierarchies are dramatically reduced, because most classes in Java are just poor man's concepts (as in C++ concepts) or poor man's Haskell typeclasses.
Also, C++ is multi-paradigmatic, and does not try to shoehorn everything into the OOP paradigm, which means the code can fit the problem better. For instance, I lost count of how often I use boost.lambda, or boost.phoenix, or bind, which all are sort of implementations of lambda.
Then there are expression templates, which allows you to do things like matrix multiplications which even outperform Fortran.
Re:And nothing of value was lost (Score:3, Insightful)
Include files are used as some sort of interface 99% of the time. Count the amount of include files without include guards. This means that include files are used in one limited way almost always. If headers are used like module interfaces, then it would be better to support modules in the first place.
Plus, you have to manually take care that stuff isn't defined multiple times (which can happen even with include guards), templates have to be re-evaluated all the time, headers included in include files propagate and can affect compile time as well....
As for why they are still around: backwards compatibility...
Re:And nothing of value was lost (Score:3, Insightful)
No, because there is nothing that can replace it. Look at the range it covers. Give me a language that can replace this, and I'm truly happy, because C++ is not a shining beacon of light, C++ is a necessary evil until something can truly replace it.
Oh, and mind the amount of C++ code out there I'd need to interface with. D is the closest thing out there, but it still falls short (well, perhaps until D 2.0 comes out).
Re:How about a REAL C++ feature.... (Score:4, Insightful)
When I'm programming, certain things set off red flags. If I see myself doing something similar many times, I extract that stuff into a function if "the thing" is parameterised by values. If it's parameterised in terms of types, I use a template, if there's obvious structure, I use a class. If it's small and gets done a lot, I use a loop. These structures are things that are not technically necessary for programming, but each mechanism cuts down on redundancy and reduces the chance of errors by having to remember where all the changes are. In addition, reducing the boilerplate makes it easier to see the structure in the program.
The auto variable is an example of type inference, and the fact that C/C++ doesn't have it is really a nuisance once one has gotten used to languages with more powerful type systems like Haskell.
Re:How about a REAL C++ feature.... (Score:3, Insightful)
Yes, but you will dump core with a bad_index or an assertion if you write outside iterator bounds instead of overwriting arbitrary memory, opening up opportunities for exploits.
Except that you won't. Alright, checked iterators are an option, which is normally disabled by default in release builds in all implementations that I know of. So normally your std::vector iterators are just thin wrappers over pointers with no checking. And, of course, an implementation that checks iterators can check pointers just as well.
In Java, C# or about any other language I've ever programmed indexing outside the bounds arrays or other containers will b0rk your program, it's all about _how_ it borks, and in that regard C++ code that only uses STL (properly) is pretty safe against buffer under/overflow exploits.
To reiterate: there's absolutely no guarantee of that. Dereferencing an invalid iterator is U.B.; moving iterator before first element, or more than one past the last element in container, is U.B.; std::vector::operator[] with out-of-bounds index is U.B. The only thing that Standard guarantees is that std::vector::at() will throw if index is out of bounds, and almost no-one uses that (I've yet to see it in production code). It is absolutely not like Java or C#, where you're guaranteed that any out of bounds index, or any invalid iterator/enumerator, will throw upon use and not corrupt anything.
C++ is demonstrably not a totaly different lang (Score:1, Insightful)
Since C++ is a super set of C by definition, your suggestion that it is a totally different language is clearly wrong.
As for, 'If you're Doing It Right then it's impossible to get a "buffer overflow"'. That's like saying if you don't make a mistake there won't be any mistakes.
I suggest you take time out to reflect.
Re:Oh, please. (Score:1, Insightful)
And then convince everyone else whose code we will ever have to work with not to use them either.
Fantastic idea!