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.'"
Re:What a name! (Score:2, Informative)
Re:Worth it? (Score:3, Informative)
Re:Downhill at a fast rate (Score:3, Informative)
> 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!
C++ template concepts vs. C# generics constraints (Score:2, Informative)
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).
Re:Downhill at a fast rate (Score:5, Informative)
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.
Telling Comment (Score:1, Informative)
And if you don't "do it right"?
Why wait to 2009? (Score:2, Informative)
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.
Re:Naming... (Score:2, Informative)
Re:Should've just done it in Python/Ruby anyways (Score:1, Informative)
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 };
Re:Worth it? (Score:4, Informative)
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).
Re:Is the C++ standards committee serious? (Score:5, Informative)
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.
From a former C++ fan (Score:5, Informative)
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/ [http]">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 [gccxml.org]. 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 [okmij.org].
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 [scsh.net]. 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 [boost.org]. 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 [boost.org]. 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.
Re:Worth it? (Score:5, Informative)
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.
Re:Slashdot interview? (Score:3, Informative)
http://slashdot.org/developers/00/02/25/1034222.s
Re:Adding new features is not always an improvemen (Score:3, Informative)
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
Disagree (Score:5, Informative)
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-
Re:Why wait to 2009? (Score:3, Informative)
If you read "The C++ Programming Language" you will find out exactly why this isn't enabled in the default libraries. Also how to provide a trivial wrapper with just a few lines using at() and why it is left to you to do so instead of specified by the standard and implimentation details. Granted you said it's not "even possible to even enable..." when in fact this is not true. There are implimentations of C++ that actually do enable such switches during compilation.
Re:Why wait to 2009? (Score:4, Informative)
That may be true (subject to debate). But the main reason is that it's everywhere. It spread and support is simply unmatchable. Even a huge corporation like Microsoft, trying to push an alternative (.Net) has a tough time making a dent in C++. Whatever shortcomings C++ may have, it's already here, everywhere, and it's not that bad as to provoke mass migration.
Re:Disagree (Score:3, Informative)
Those kernels are mostly written in C. They allow you to use C++ for drivers but they even "discourage" it in the documentation. Userspace is another matter.
As a linux kernel hacker said: "a language where '+' is allowed to do something that it's not really '+' is not a good choice for a kernel"
Re:Worth it? (Score:3, Informative)
Re:Worth it? (Score:3, Informative)
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.
Re:Is the C++ standards committee serious? (Score:4, Informative)
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.
Re:Disagree (Score:3, Informative)
As for military projects, I know since I work in that sector. Ada is the primary language in these 'hardcore' military projects.
You can now with boost (Score:1, Informative)
Here's an example from :
http://boost.org/libs/assign/doc/#operator+= [boost.org]
#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).
Re:More features - is that what C++ really needs? (Score:3, Informative)
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.
Committee doesn't want to add features!! (Score:2, Informative)
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
Re:C++ vs Retards on Rails (Score:1, Informative)
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.
Re:In size, maybe... (Score:3, Informative)
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 [dreamsongs.com]. Great book if you're at all into software patterns, BTW.
Re:From a former C++ fan (Score:3, Informative)
The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well.
CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or .NET bytecode actually AFAIK. Later Open Genera [rcsri.org] was released that allows one to run the Lisp OS on Alphas. Using high-level opcodes is
not critical for Lisp (most modern CL compilers save CLisp produce native machine instructions for their target architectures).
Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!
Yes, it's rather hard to do so, just because Linux kernel and X.org are written in C. If they were written in Lisp, it would be hard to write drivers in C unless authors cared to provide proper FFI-based "foreign" driver loading mechanism. There's nothing wrong with Lisp itself concerning low level stuff. For example, take a look at this beast [common-lisp.net] (Lisp on bare metal).
As a matter of fact, I agree that C/C++ is safer bet in our world, but not because C and C++ are more general languages than Lisp is. It's just because most of stuff in use is written in these languages. Lisp machines failed (mostly due to management & political reasons), Lisp itself became the scapegoat for failed AI promises, so now curly braces are almost inevitable for serious programmers.
But nevertheless Lisp is worth learning as it can be the best tool for complex problems in many cases, and also due to the fact that it makes programmers more broad-minded. It's actually much more general than C++ in the sense that it easily supports almost any paradigm one can imagine. For instance, it's possible to seamlessly embed SQL, Prolog, HTML, etc. rewritten using S-expressions in Lisp programs.