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.'"
Seems like the 0x will be replaced with the year it is ratified by the ISO, eg. 09. The same as the ISO standard C++98.
To us stuffy old farts things keep moving way too fast. I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.
>> When I found the C language, I stopped looking. Ah well.
> Too bad.
I guess I should have qualified my comment, really. I suppose in part it comes down to what problems one is trying to solve. I'm an embedded designer, working on small systems. Assembly and C turned out to be the right tools for the job. So I guess I should really have qualified my rant with "in my line of work".
The red mist has lifted now!
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
C++ template concepts are no better (or worse for that matter) than C# generics constraints, they only bind differently: C++ binds to a name, C# binds to an interface. Both are equally rigid. Both require foresight. In C++ you don't have to derive your class from a specific interface, but on the other hand you still need to implement the function knowing what name it will be accessed through (i.e. should it be named begin or Begin or GetBegin).
> 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.
And if you don't "do it right"?
I personally have more hope in this alternative.
To me, D has surfaced to become what I always thought C++ should have been. I hope (and believe) that it will be giving C++ more competition in the comming years. It might not be ready for full production yet (due to lack of big supporters and libraries, mostly), but I have tried it out on several of my own projects, and I love it.
++ is the increment operator, C++ is C that has been incremented with new OO features (be that for better or worse is a personal opinion in the same league as religion)
>> Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.
Well, you'll at least be able to do that 2009.. Or to quote Stroustrup from the article:
Vec v = { 2.3, 1.2, 6.7, 4.5 };
Huh?!? C++ is a tremendously type dependant language, which is a very different thing from being type safe. If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile. A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected. Yes, that's a programmer error, but a good language should be designed to catch programmer errors at the earliest possible point (compile time).
Support Right To Repair Legislation.
I'm surprised that you feel qualified to make this statement, since it would require you to have the rare combination of having top secret clearange (in order to know about all military projects) and have a "need to know" about each one of them and be in the habit of posting what you know to Slashdot.
But you're simply incorrect in your statement.
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.
From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct".
If you were talking about ML, you might be right, but in the case of C++, that's unadulterated bullshit. C++ can never approach the "if it compiles, it's correct" ideal because it allows unsafe memory operations. I recently worked on a large C++ code base that "compiled" the day I arrived. Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.
Erlang.org: wow
Slashdot has actually already had an interview with Bjarne:
h tml
http://slashdot.org/developers/00/02/25/1034222.s
http://www.talknerdy.org
The problem sound rather like "linking an incompatible library version" than header problems occuring through use of the C++ preprocessor.
.h file by defines in other .h files." was a typo.
Java can have the same problem since it links in EVERYTHING at runtime. Put an outdated class in the classpath before or instead of the correct class and you've got a problem.
I don't think any other language handles the situation any better.
The only way to "fix" this is by doing some sort of version-number (timestamp?) checks, the mechanics of which aren't dependant on a specific language or it's features.
I still don't see how this problem is caused by the C++ preprocessor though, perhaps an example would help?
p.s. I hope "And I hope you can change the "effect" of an
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
No one has used C++ for any major operating system,
t ml
Windows XP, NT, 9x. See: http://public.research.att.com/~bs/applications.h
and no one has used C++ for any hardcore military project.
I'd beg to differ.
-everphilski-
You can be warned about that on almost every C/C++ compiler out there. Most compilers don't by default, but if it's something that you care about, enable it; it takes seconds.
"WANTED: Sinking ship seeks rats."
I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?
As someone who's been paid to program in each of those over my career, I'd say that each of them have their places.
If these are your points, then use another language, like Java.
But I never said that C++ should look like Java. All that I want can easily fit in the C++ style, and they can be optional.
Garbage collection: making this the default would be utterly insane. GC has to run on another thread, thus making a program unpredictable
Nope, not at all. First of all, GC does not need to run in a separate thread. I have programmed several GCs, some of them naive, some of them hardcore, and sent them to Stroustrup. None of them required a separate thread. Secondly, you shouldn't talk about predictability and C++ in the same sentence, since C/C++ pointers can easily make a program unpredictable. And if you want "predictability", as you mean it, then be aware that GC can be optional.
the lack of import declarations: thanks God we don't have them! Keeping headers and implementation in two different files is a wonderful idea
It makes code management difficult. I have to type the same things twice. I have to decide if a piece of code goes in the header or implementation file.
I can ship to the user directly my clean and documented header files. No Java-style cluttered and bloated source files. Btw, Java is different because it's compiled in bytecode.
First of all, you do not need to ship source files. Take a look at programming language D, in which the compiler produces symbol files to be directly imported to programs. Secondly, it is totally irrelevant that a language is in bytecode or not. There are bytecode compilers for C, for example.
C++ isn't, so implementing an import semantic would break C++ ABI (yet) another time.
Importing a file it is just another way of accessing declarations between programs. The difference is that imports are already pre-compiled in compiler format, and therefore faster to compile. As for compatibility between compilers, just define a standard (like D does).
What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages.
But new projects will not use the existing graphical toolkits, but the standard one.
Changing the way they do things without breaking binary compatibility for library users is just impossible.
Nobody said "stop using the other libraries". But the other libraries are a pain in the a$$ to use. Qt requires MOC, GTK sucks, wxWidgets sucks more, Motif sucks even more. Swing is nice though.
No closures: I don't know if I understood your example correctly, but with Gtkmm + sigc++ I do what you said without particular problems.
Nope, you did not. What you are referring to is a callback framework. I am talking about closures. See Smalltalk's blocks, or lambda functions of Haskell/Perl for examples.
No initialization of an object's fields at the point of their declaration: yes, this is left as a boulder for the programmer. No harm in that, you're just speaking about syntactic sugar
properties: mark a member public if you want to spare some typing. Else use an IDE that generates accessors for you. All in all, it's just laziness...
Yes, syntactic sugar, but a very important one: it will save much reduntant work.
No true message passing: use a library that provides them. As simple as that.
Obviously, you have no idea.
Using the assignment library this is easy.
// for 'operator+=()' // bring 'operator+=()' into scope
// insert values at the end of the container
Here's an example from :
http://boost.org/libs/assign/doc/#operator+=
#include
using namespace std;
using namespace boost::assign;
{
vector values;
values += 1,2,3,4,5,6,7,8,9;
}
This, it seems, is not the way it will be implemented in the new C++. But lots of other stuff mentioned is already in boost (smart pointers, threads).
in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects
You'd be absolutely right, assuming, of course, that Python actually supported true lexical closures, which it doesn't...
Of course, I'm not so silly to think that Ruby is unique in supporting this concept. After all, the creators of Ruby stole most of their ideas from Smalltalk, who, in turn, stole many of their ideas from LISP (although, admittedly, LISP didn't switch to lexically scoped closures until somewhat later in it's lifespan). It's just a shame that Python hasn't done the same.
The goal of C++0x is not to add a bunch of new features to the language.
Two of the driving goals of the committee are to prefer library extension
to language extension and to focus on simplifying current features.
Remeber that the standard library specification is a major part of
the standard. And standard library extensions are very different than
language extensions.
The actual "new features" that the Bjarne was discussing focus on
simplifying and streamlining current features and syntax. For example,
while template typedefs and auto iterator types are language
extensions their goal is to simplify a current language feature: templates.
The possible exception to this is the addition of "concepts". However,
information about the design of "concepts" is so sparse in that article
that it is difficult to form an opinion.
Jake
Code generation? Obviously you haven't been doing any serious Ruby on Rails programming to come up with that sort of comment. Code generation is a very small, very insignificant part of the framework, only added to make people who don't know any better go "oooh" and "ahhh" when watching the videos. And code regeneration is unheard of.
If you actually play around with rails, I think you might be pleasantly surprised. Or maybe not, but at least you'll be able to make halfway intelligent criticisms. And ruby itself (separate from the rails framework, and the more natural target for comparison with c++) is a thing of beauty.
For what it's worth, I agree with you re: C++ vs. C# and Java. But ruby is in a class on its own.
The C++ code I posted is straight STL, which calls a function in the Xerces-C++ library - it has a major bug in it as posted because Slashdot ate a critical '<'. See this posting for the details.
...) wrapper isn't needed, but the name of the string comparison function is different:
I object to the C++ STL method of denoting function objects because it's verbose, and it's verbose without being enlightening. In C++, this kind of stuff happens routinely because of having to avoid new syntax and new keywords that might conflict with old C code. Is 'operator()' clear and intuitive to you?
The second line is only cryptic if you don't know Lisp at all. It's short for
(function string<)
and is the standard Common Lisp notation for reference-to-function. In the Scheme dialect, the (function
string<?
The last one in normal Lisp source would be indented like this:
(lambda (s1 s2)
(declare (string s1 s2))
(string< s1 s2))
It's closer to the C++ because of the (optional in Common Lisp, for speed only) declaration in the second line.
None of this stuff is tricky Lisp - it's just a notation you're unfamiliar with.
On the subject of verbosity, one of the real gurus of Common Lisp, Richard Gabriel, agrees with you. See the "Abstraction Descant" chapter in his book Patterns of Software. Great book if you're at all into software patterns, BTW.
To a Lisp hacker, XML is S-expressions in drag.