Bjarne Stroustrup Previews C++0x 741
Szplug writes "Bjarne Stroustrup has a sneak peek at the additions to C++ that he expects will be completed (hopefully) by 2009. Included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts. From the article: 'The list of current proposals is still quite modest and not anywhere as ambitious as I'd like. However, more proposals are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports.'"
Worth it? (Score:1, Insightful)
Time will tell, I guess.
Re:Worth it? (Score:4, Insightful)
I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?
C/C++ have been around for many years and show no signs of going away - C++ was initially developed in 1983, while C itself hails from the early 1970s - and they're still popular to this day. And, of course, C++ "bolted on new features" to C. In fact, C++ was initially called 'C with classes'.
As far as I'm concerned, as long as C++ is "the standard language" in so many places we may as well make it not suck in comparison to other languages, which we can do by appropriating the nice features of those other languages.
Just my $0.02,
Michael
Adding new features is not always an improvement (Score:5, Insightful)
I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass. In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified. At the moment moving around code from one DLL to another is a lot of work, while in my perception, it could have been completely transparent from the users point of view.
I do realize that keeping backwards compatibility was one of the design features of C++, and that it also determined the success of C. But as many C++ tools are now able to make use of precompiled headers, it seems that the problem should be able to be done away with.
More features - is that what C++ really needs? (Score:5, Insightful)
If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.
Re:What a name! (Score:5, Insightful)
Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?
Actually, the correct pronunciation will be "See Plus Plus". The name of the language won't change, just as C is just called C, even though K&R C, C89 and C99 are quite different animals.
This has brought out the C++ haters (Score:5, Insightful)
My wish-list for c++ (Score:4, Insightful)
interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.
Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature.
Re:2009? (Score:5, Insightful)
(See Stroustrup's C++ Applications page [att.com] for more.)
Re:Worth it? (Score:5, Insightful)
C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right. It seems to deliver on a lot of the promise of ADA, really. If they can improve access to its features without compromising that type safety, I'm all for it.
Comment removed (Score:2, Insightful)
Re:Worth it? (Score:5, Insightful)
Re:Heh (Score:3, Insightful)
It might be nice if he could.
Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.
Compare to Objective-C: You'll note that these new C++ "concepts" feature are extremely similar to Objective-C's "protocols"- only not only can a moderate programmer produce a fast Objective-C compiler, they'll know exactly where it can be slowed down and why.
It'll also already be able to do these things in C++ that are so new and innovative.
Meanwhile, some C++ compilers can make "cout << 1 << endl;" slow- and others only do it when the programmer tries to make their own "cout" like device.
If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind [systems programming] of tasks.
No, it's if those libraries imposed greater responsibilities on the runtime. As it stands, the C++ runtime already has an awful lot to do- albeit less than Java or Objective-C.
Worse still: The C++ runtime isn't a peer to your own code as it is in Objective-C: With Objective-C you can interact with the runtime as if it were regular library calls.
C has a mountain of library code available, and the functionality of that library code drives new extensions to the C core language (TLS extensions, for example)
But then, C has almost zero runtime (and if you reject certain extensions: it actually has no runtime), and that's what makes it suitable for systems programming.
I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.
Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.
The inventor of C++ can't even do this, but any moderate programmer could do this for Objective-C.
Re:Downhill at a fast rate (Score:3, Insightful)
The GUI. (Score:3, Insightful)
Although this might be considered a disappointment, his citing the fact of low resources, time and money are best spent in other areas. Lets get something out the door that we can use now instead of waiting for the GUI. I'm no C++ expert, as a matter of fact I'm only into about 400 pages of my first teaching book
Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed. Its probably good to have commerical interest in the GUI space, since the desktop is forever evolving faster than a C++ committee could handle.
Re:Heh (Score:5, Insightful)
Well, the power of most languages is in the libraries anyway. What is Java or C# without the standard libraries? I program in C++/Qt and rarely if ever touch all that is ugly about C++. The very few places I allocate memory myself for operation with other code I check it rigorously, Qt objects handle themselves. I use QString and QBytearray and never have issues with zero-termination or buffer overflows. Signals and slots will never crash on a dangling pointer. The new Qt4 containers with foreach are brilliant. So yeah, core C++ may be functionally poor but if you need the equivalent of java or C# it's a library away.
Kjella
Re:More features - is that what C++ really needs? (Score:3, Insightful)
Sorry, I have.
Ruby and Python are more or less equivalent languages, extremely similar in most constructs and ways of life, and rougly 90% of the "differences" between the languages boil down to syntactic sugar.
And please, I beg you, don't bring Blocks in this by saying something as stupid as "woohoo, blocks are liek magic, no one else has it, they're cruise control for greatness", blocks are anonymous functions period (in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects), the concept is more than 30 years old... (and not OO at all, meaning that the "top of the line" feature of the OO herald language is purely functional).
Ruby is an extremely fine dynamically strongly typed language with an extreme object orientation, Python is likewise. None of them is "better than the other one" in an absolute sense and claiming the opposide is stupid, the one you choose is purely a matter of taste. You prefer Ruby? good for you, I prefer Python, and that makes neither "the ultimate language".
This fucking ruby hype is becoming extremely tiring, and doesn't help Ruby.
End of the rant
Re:The GUI. (Score:4, Insightful)
If you're right, WTF would you want to use a MS product? You can do a hello world in C++ with just 3 lines (TUI) or 12 (GUI with QT).
Concerning XML-based GUI descriptors, it is in general not smaller. It is smaller to define and place the components but things goes wrong when you have to manage events. In fact, from my experience, a GUI in HTML+JS, C++/QT and Java/Swing has more or less the same number of SLOC.
Re:My wish-list for c++ (Score:2, Insightful)
Headers make things vastly more efficient when dealing with system libraries; it would be crazy to compile everything
There is no reason the compiler shouldn't be able to ignore the implementation section when you are just using the interface. Of course you need the entire source, instead of just the header files, but that's a minor inconvinience in my opinion.
And whether it makes coding easier is a matter of taste.
Btw: I am a total Delphi fan..
Is the C++ standards committee serious? (Score:5, Insightful)
Why do they want so many years to decide on so simple things that are other languages take for granted for more than 15 years now? Let's see what they have in store:
But what makes the most negative impression is the willingness to recognize that the programming language world has made huge steps in the last few years, and C++ is light years behind. Here are some of the negative points, in random order:
Re:This has brought out the C++ haters (Score:5, Insightful)
Not all of them. I've worked for 6 years as a game developer, and I've seen (and written myself) some pretty horrible stuff.
Yet I actually love C++ now, even though I hated it at first.
What I hate are people not thinking thing through before they code and hence writing monstruous code.
And most of these monstruosities are not C++ specific. A programmer who is not able to figure out what to put in a separate function or how to make a proper class hierarchy won't magically do better in Java, C#, Python or whatever else.
How fascinating (Score:3, Insightful)
1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.
2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.
3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).
4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.
It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.
NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.
Re:The GUI. (Score:3, Insightful)
All the frameworks I know tend to use their own string class, their own containers, etc -- and obviously as well their own threading library.
Re:Should've just done it in Python/Ruby anyways (Score:3, Insightful)
ohh...
wait...
(reads 30 years of literature on databases, furrows brow)
I think I've seen a problem with that!
(looks up brightly)
Stop complaining about things you don't know! (Score:5, Insightful)
1) people complaining here about C++ or its will-be features either aren't C++ users or don't understand much of C++;
2) people who have at least managed to RTFA to the end are complaining about new features of the _language_, that will be _few_, while the biggest efforts will be oriented towards extending the STL, which is the really important part.
Btw, only a C user that understand C++ poorly could complain about references. If you find yourself at ease with C, by all means, use it. But don't spit on another well engineered language without the necessary knowledge to do so.
By the way, about references: what's so different when passing to a C function a pointer to a struct, instead of a reference to a C++ one? Don't you have still to read the prototype to know you must pass a pointer indeed? There's just one small difference between C and C++: guess what, if the prototype is a const reference in C++ you've more guarantees the object won't change than with a const pointer in C, since C++ enforces constness. And you don't even have to worry about pointers referencing to free'd memory.
It would also have been nice if this
Oh, well: it's Slashdot after all. What was I expecting. Sigh.
C++ is not a type-safe language (Score:5, Insightful)
Re:Downhill at a fast rate (Score:1, Insightful)
That's actually pretty libellous. You need to read "The Design and Evolution of C++" and get back to us.
Re:This has brought out the C++ haters (Score:4, Insightful)
I don't know about that, depends on how you classify "commercial applications right now"
-Number of stand alone applications running on people's PCs around the world? Definitely not.
-Number of programmers employed and/or counting webapps as applications? Probably yes.
Re:More features - is that what C++ really needs? (Score:3, Insightful)
Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).
Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.
Re:Is the C++ standards committee serious? (Score:5, Insightful)
If these are your points, then use another language, like Java.
I don't want C++ to look like Java.
I want C++ to solve a different kind of problems in an easy way.
Frankly _none_ of your points would be something that I'd like to see added to the language; it would be likely to introduce complexity and confuse users even more, instead of helping them; and maybe it would also break compatibility with old C++ programs. It seems that the ISO committee agrees with this idea.
Some of your points debated:
So please: change programming language and don't complain non-sensically trying to look cool because you can speak a little jargon.
Re:C++ template concepts vs. C# generics constrain (Score:3, Insightful)
concepts.
Here's an example. I'm writing a concept for a Stack, which might look like this:
template
concept Stack
{
typename value_type = S::value_type;
void push_to_top(S& s, const value_type& value);
void pop_from_top(S& s);
value_type& get_top(S& s);
bool is_empty(const S& s);
};
I picked some silly names on purpose. Now, std::stack doesn't match the syntax of this concept. So what if we try to pass a std::stack to a function like the following, which expects something that is (we use the term "models") a Stack?
template
void clear_stack(S& s)
{
while (!is_empty(s)) {
pop_from_top(s);
}
}
It's going to fail to compile, because std::stack does not match the syntax of the Stack concept. If C++ concepts had the same restrictions as C# generics in this regard, we would be stuck writing an adaptor class. Yuck.
Retroactive modeling saves the day. We can fix the problem by writing a model definition like this:
template
model Stack >
{
typedef T value_type;
void push_to_top(std::stack& s, const T& value) { s.push(value); }
void pop_from_top(std::stack& s) { s.pop(); }
value_type& get_top(std::stack& s) { return s.top(); }
bool is_empty(const std::stack& s) { return s.empty(); }
};
In this model definition, we're meeting all of the requirements of the concept by providing function definitions that transform the syntax of the Stack concept (pop_from_top, is_empty, etc.) into calls to the std::stack itself (see the function bodies). Now, when we call clear_stack() with a std::stack, it "just works": the calls to is_empty() and pop_from_top() in clear_stack() go through the model definition. Of course, if we picked more standard names and member functions in our Stack concept, the model definition could be empty or (for implicit/structural concepts) omitted entirely.
Retroactive modeling is *really* important for making it easier to reuse template code. You won't need to be paranoid about matching syntax *exactly* with every concept you need to model, because the compiler will detect any mismatches and you can fix them through a model definition---without having to change the data types, templates,
or concepts. Of course, people will still try to agree on names and concepts when possible, because it saves typing. You can check out the actual proposals before the C++ committee (references follow) for more information. There are two active proposals, but the groups are working together, so expect a final "combined" proposal in the future.
There are other differences between C# generics and C++ concepts. Before starting to design concepts for C++, most of the authors of one of the concepts proposals (N1849; see below) did an extensive study of the generics facilities of several languages (e.g., C# generics, Java generics, Haskell, ML functors, C++ templates). They ran into trouble with every language they tried, and we designed our C++ concepts to avoid those problems. Here's the original paper; there's an extended version (with more languages and more detail) under review:
Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages,
Re:Is the C++ standards committee serious? (Score:3, Insightful)
(I think "you don't pay for what you don't use" is a fundamental design flaw of the language, but if you dismiss it, you're no longer arguing about how to extend C++; you're arguing about what language to replace C++ with.)
Re:Adding new features is not always an improvemen (Score:3, Insightful)
As a systems language, right now, no. But there is some really interesting-looking work on the MS Research page (the Singularity project, if I remember) with using it as that with some crazed tools they have, and exploiting the features of "safe" languages to make a different sort of system.
As for "C+=2", have you looked at Objective C? I believe that its general purpose is to provide a "better" OO implementation, although I've never used it myself. That said I think it runs all C code (where C++ does not) so possibly not all that OO from the ground level...
Try reading your own post. (Score:4, Insightful)
In size, maybe... (Score:5, Insightful)
They don't have writers the caliber of Guy Steele or Kent Pitman, so it'll still read like gargling razor blades
Their legacy syntax straightjacket will insure the code stays verbose and hard to read. Compare:
struct ltXMLCh {
bool operator() (const XMLCh* s1, const XMLCh* s2) const
{
return XMLString::compareString(s1, s2) 0;
};
};
with
#'string<
or (comparing apples to apples):
(lambda (s1 s2) (declare (string s1 s2)) (string< s1 s2))
Yep, c++ == good, but not for prototypes (Score:3, Insightful)
Re:This has brought out the C++ haters (Score:4, Insightful)
An earlier poster commented that the very programmers who have to write the C++ apps are the ones who hate C++.
I would like to add that the very users who have to use the Java apps are the ones who hate Java.
Re:Worth it? (Score:3, Insightful)
Re:More features - is that what C++ really needs? (Score:3, Insightful)
Re:Why wait to 2009? (Score:3, Insightful)
That depends on your benchmark. Mine is pragmatism, where it remains unrivalled for many jobs.
And while C++ has many theoretical design flaws that could be improved in a language without the historical baggage, lack of bounds checking on a vector isn't one of them. Just use at() instead of [] if your implementation doesn't do bounds checking already.
Re:Worth it? (Score:1, Insightful)
C++ isn't even a proper superset of C.
C++ doesn't die because it became vastly popular and it will take a long time for people to rewrite all that code or even move it to better compilers.
I view C++ as a nightmarish half-step between systems programming and high-level languages. It's only advantage over c is support for OO programming styles. That's nice, but when other languages offer: OO Programming that doesn't seem tacked on, managed memory, and complete libraries: C++ looks less and less attractive.
People will probably be writing videogames in C++ for ages though. So, I suppose this excites them.
Re:Is the C++ standards committee serious? (Score:3, Insightful)
I disagree since if you knew of a reasonable sample of declassified or public military projects and none of them used language X, there's no reason to assume that secret or top secret projects are going to be more inclined to use language X so it would be a reasonable statement.
That said, I doubt the grandparent had a reasonable sample.
Re:Adding new features is not always an improvemen (Score:2, Insightful)
"powerful" in the sense of "as powerful as a Turing machine", I suppose.
Template/preprocessor metaprogramming is a horrendous hack. It basically happened by accident because the addition of templates "upgraded" the compiler to have a Turing-complete language embedded within it. Not that anyone realized this while they were actually *designing* templates.
Well-designed "metaprogramming" would use, get this, a programming language, with sane syntax, not the mess that template syntax is; C++ was already so crowded with line-noise operators, they had to separate less-than signs with spaces. It would also have real programming semantics, instead of hijacking the type system to provide flow-control.
Lisp basically got this right, by allowing meta-programming to use the same language and operators that the underlying language has.
Re:In size, maybe... (Score:3, Insightful)
So let me get this straight: an in-place function definition isn't clear unless you like graph theory; but a structure pretending to be a function that takes two pointers to unmodifiable hieroglyphics and promises not to change the data members it doesn't have as it calls another function that belongs to another class or namespace and tests whether the answer is negative is nice because (if and only if you know what all the syntax means) you can read it out loud and understand what it's doing?
Wow, you must really hate graph theory. :-)