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.'"
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.
How about having a slashdot interview about C++0x with Strousrup? I think it would be a good forum to gain more insights about C++ and a fine possibility to allow a community (in this case the slashdot readers) to make and to vote on feature proposals.
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.
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.)
Tell me about it! And those fancy editor thingamajiggs? A-phoooey! Real Programmers use cat(1) and do it right the first time!
sudo ergo sum
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?
> And reference variables?
There is no such thing as a reference variable, you clearly don't know the C++ language. references are not variables. references are newly defined identifiers that refer to an object that already has identifiers referencing it, they don't change, ever, hence are not variable... But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.
BTW, when you say "fancy allowing standard operators to be overloaded" I think you mean "overrided". C has overloaded operators (+ is defined for int, char, short, long, float, double, etc). overriding lets you tell the compiler how to do addition for your custom bigint library, or whatever. You can misuse operator overriding, or you can misuse macros, each are there for a purpose, and each get misused by bad programmers.
> And now garbage collection? That just a feature to fix poorly written code.
No it isn't, it is a feature to simplify the determination of object lifetime when that lifetime depends on complex (or more likely, merely chaotic) runtime factors. Bad programmers use it to fix poorly written code. Sure, every lifetime can (maybe) be determined by some complicated equation, but when you have limits on how much CPU you can use and limits on how much time you can spend on maths, you use garbage collection.
The trick is only to use garbage collection when you know that you need it and what it means. There's the problem with most dynamic languages.
Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.
Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/">Boost C++ libraries.
At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.
Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to "emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL.
After playing with Scheme for a while, I've found out (to my surprise) that the language can be used for many other purposes besides list (tree) processing and simple scripting (as in Gimp). As an example, there are wonderful things like Scsh. It's possible to write Web applications, many Schemes can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.
So I've begun to try to do some real things in Scheme. Disillusionment has come rather quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is not standardized and thus is 100% non-portable between implementations. Moreover, every implementation has its bugs and limitations, and when you come to the point when you need to change your implementation you discover that most of your code needs to be rewritten from scratch.
I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.
What quickly became apparent to me from my CL experience is that most of problems Boost guys are fighting against are just plain nonexistent for Lispers. Look at this, for example: variant.hpp. A good workaround for C++ typing model. What do we have in Common Lisp?
(sorry for mangled indentation)
Now look at this beauty: boost::lambda. Don't forget error messages it produces when you mistype something or stumble across a bug. CL example?
Not to mention Lisp's GC versus boost::shared_ptr.
OK, these are areas where dynamic languages like Perl, Python and Ruby, and even statically typed like C# or Java are catching up to some degree. Now let's look at some CL's more-or-less unique features.