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.'"
There's a reason why languages come and go.
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
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.)
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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:
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.
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.