Slashdot Mirror
Bjarne Stroustrup Previews C++0x
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.'"
Having programmed in numerous languages I can't help wonder if it's really worth it. There's a reason why languages come and go. Bolting on new features might be more like treating the symptoms rather than the cause?
Time will tell, I guess.
.: Max Romantschuk
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.
If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.
You're an immobile computer, remember?
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.
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.
I doubt Google, Adobe, or many of the thousands of other companies depening on C++ will be throwing their code base away any time soon. Rather, they will want their C++ code to be more robust and more managable. The features the article lists all seem to do this.
(See Stroustrup's C++ Applications page for more.)
I still think C++ was invented as a joke.
Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."
The upshot is a language that is accreted instead of designed.
When I found the C language, I stopped looking. Ah well.
Too bad.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
What would you prefer - Stroustrup does it all single-handed?
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.
It's not that hard to see if there's a 'const' in the function prototype, is it?
I was pleased to notice that Bjarne Stroustrup has acknowledged that they won't be pursuing to include a GUI framework into the new C++ standard.
;)
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.
Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work.
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
Live today, because you never know what tomorrow brings
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:
Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:
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.
I'm not going to change your sheets again, Mr. Hastings.
On the other hand, we could use COBOL, as that has really good facilities for putting data inline with imperative code.
ohh...
wait...
(reads 30 years of literature on databases, furrows brow)
I think I've seen a problem with that!
(looks up brightly)
--------------------------------------------- "In the end, we're all just water and old stars."
As far as I can see:
./ discussion were about the new features of C++0x instead of the old "C is better than C++", "python is better than C" and "x86-assembly beats the pants off both".
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.
42.
While C++ is more strongly typed than C, C++ is not type safe. Type safety means that the language ensures that no operation will ever be applied to a variable of the wrong type. However, C++ supports the ability to access arbitrary memory locations, allows type casting, and automatically converts types in many instances. Java is more strongly typed than C++, as it doesn't allow access to arbitrary memory locations, but it also supports casting and automatic conversions, and so is not type safe. If you want type safety, try a language like Ocaml or SPARK Ada.
Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."
That's actually pretty libellous. You need to read "The Design and Evolution of C++" and get back to us.
You bring up an excellent point about the rigidity of C# generics constraints. One of the crucial features of the proposals for concepts in C++ is retroactive modeling, which allows you to adapt to the specific syntax of a concept *without* changing your data type. So the problem you mention for C# generics is not actually a problem with C++
// the type of values on the stack
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,
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...
Blocks are just anonymous functions with closures, so ruby and python are equals? But python doesn't have proper first class anonymous functions with closures. It only has a half-assed crippled version that is supposedly being removed in python 3. So clearly python is missing functionality that languages like ruby and pike have.
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))
To a Lisp hacker, XML is S-expressions in drag.
Not to add a pointless "me too", but I would also agree with this. I'd just like to add that this massive time for dealing with types does make C++ very unwieldy for quick prototypes if you just want to test an idea. To that end, I find the common approach of prototyping or doing quick utilities in python, and re-doing mission-critical stuff in C++ to be a great compromise.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
preprocessor metaprogramming. It's a very powerful tool
"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.