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.'"
> 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.
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
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-