Recent slides by Stroustrup on C++0x: http://www.arcos.inf.uc3m.es/~jdaniel/sem-cpp-11/Madrid-bs.pdf

The Reddit thread: http://www.reddit.com/r/programming/comments/gqwei/

The graph at page 20 (about list Vs vector) seems a bit too much good to be true. There is no link to the benchmarking code. This benchmark by Stroustrup is much worse than the ones I used to show here.

>The primary value of a programming language is in the applications written in it<

The main value of certain languages, like Algol (or even Simula), was to lead the way and help the development of widely used languages.


>Make C++ easier to teach and learn Through increased uniformity, stronger guarantees, and facilities supportive of novices (there will always be more novices than experts)<

C++0x adds useful things, but it's more complex than C++, there is more stuff to learn.


>C++0x [...] Every feature is implemented somewhere<

Really?


> Example: Strongly-typed enumerations
> enum class Color { red, blue, green };
> int x = Color::red; // error: no Color->int conversion
> Color y = 7; // error: no int->Color conversion
> Color z = red; // error: red not in scope
> Color c = Color::red; // fine

Good. I'd like D2 to do something similar.

----------------------

The Stroustrup slides also cite (page 38) the JSF++ (C++) coding standard, that's interesting. I leave the discussion of those rules to another time, but in the meantime I have found a higher level description of this coding standard:
http://www.ldra.com/nologindownload.asp?id=134

> Language Selection: C++ or Ada95?

Ada95 has some problems, like less tools and compilers, but you don't want safety-critical software written in a language that has hundreds of known traps.

This kind of programs are a small niche of the whole amount of programmers that may want to use D2, but I think it's good to take a look at what those people like or don't want from C++.


> Ban features with behaviors that are not 100% predictable (from a performance perspective)
> Free store allocation (operators new and delete)
> Exception handling (operator throw)<


> C++ provides safer alternatives to many dangerous C constructs E.g. polymorphism rather than switch statements<

Maybe there are ways to improve D2 final switches further (like covering all 8 cases if the final switch is done on a n%8, or with class instances).


> C-Style casts ==> C++-style casts
> JSF++ strongly encourages elimination of casts


> AV Rule 48: Identifiers will not differ by:
> - Only a mixture of case
> - The presence/absence of the underscore character
> - The interchange of the letter ‘O’, with the number ‘0’ or the letter ‘D’
> - The interchange of the letter ‘I’, with the number ‘1’ or the letter ‘l’
> - The interchange of the letter ‘S’ with the number ‘5’
> - The interchange of the letter ‘Z’ with the number 2
> - The interchange of the letter ‘n’ with the letter ‘h’.
> Rationale: Readability.

This is interesting, and seems good.


> prohibit dependence on evaluation order and side-effects.
> manage memory layout issues (unions, bit-fields, casts, etc.)
> address overflow issues
> prohibit mixed-mode arithmetic and comparisons

Good.


> Public and protected data should only be used in structs -- not classes.


> AV Rule 101: Templates shall be reviewed as follows:
> 1. with respect to the template in isolation considering assumptions or requirements placed on its arguments.
> 2. with respect to all functions instantiated by actual arguments.
> Note: The compiler should be configured to generate the list of actual template instantiations.
> Rationale: Since many instantiations of a template can be generated, any review should consider all actual instantiations as well as any assumptions or requirements placed on arguments of instantiations.

In DMD there is no switch to see a list of actual template instantiations.


> Where possible tools will be used to automate coding standard enforcement.

A first good tool to avoid similar bugs is the compiler itself.

Bye,
bearophile

pfff... I really don't know what to say about C++0x.  Everyday I fall more in love with D.  To know that I'll have to spend time learning all the new things in C++ just depresses me.  Sure, there are some nice features, but I rather spend that time on improving my D and Python.  Life is too short, and I don't want take the abuse from C++ anymore.  Besides, how long are they going to continue to add crap to C++, or "improve" it, while retaining backward compatibility?

Caligo:

> Besides, how long are they going to continue to add crap to C++, or "improve" it, while retaining backward compatibility?

From the things they are adding and changing in Fortran today, I think at least some more decades :-)

Bye,
bearophile

On Apr 17, 2011, at 11:44 AM, Caligo wrote:

> pfff... I really don't know what to say about C++0x.  Everyday I fall more in love with D.  To know that I'll have to spend time learning all the new things in C++ just depresses me.  Sure, there are some nice features, but I rather spend that time on improving my D and Python.  Life is too short, and I don't want take the abuse from C++ anymore.  Besides, how long are they going to continue to add crap to C++, or "improve" it, while retaining backward compatibility?

For a long time yet, seeing as how they're required to do so.  Overall, I think there are a lot of nice features in C++0x.  The problem is as you said however: they've added even more stuff to an already large and complicated language.  And with all the legacy code, the crufty old approach to doing things will stick around for a Long Time Yet.  Still, if D isn't an option, at least 0x eases some of the pain of using C++.

== Quote from Sean Kelly (sean@invisibleduck.org)'s article
> And with all the legacy code, the crufty old
> approach to doing things will stick around for a Long Time Yet.  Still,
> if D isn't an option, at least 0x eases some of the pain of using C++.

Exactly how I feel about C++1x.  It adds a lot of (though far from all) the interesting features of D.  However, I can't stand the crufty old way of doing things in C++ and want to abandon it wherever I can.  No matter how soon C++0x gets finalized and implemented, the ecosystem of idiomatic C++0x code is going to be small for ages, probably behind D.  (Full C++0x implementations will probably be behind D implementations for a while, too.)  Similarly, D has plenty of libraries if you count its ability to link to C.  It's just that you have to write in crufty C style or write non-trivial D-ified wrappers to use them.

On 4/17/2011 11:44 AM, Caligo wrote:
> pfff... I really don't know what to say about C++0x.

A comparison of new C++0x features with D:

http://www.digitalmars.com/d/2.0/cpp0x.html

On Wed, 20 Apr 2011 20:02:58 +0300, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
>> And with all the legacy code, the crufty old
>> approach to doing things will stick around for a Long Time Yet.  Still,
>> if D isn't an option, at least 0x eases some of the pain of using C++.
>
> Exactly how I feel about C++1x.  It adds a lot of (though far from all) the
> interesting features of D.  However, I can't stand the crufty old way of doing
> things in C++ and want to abandon it wherever I can.  No matter how soon C++0x
> gets finalized and implemented, the ecosystem of idiomatic C++0x code is going to
> be small for ages, probably behind D.  (Full C++0x implementations will probably
> be behind D implementations for a while, too.)  Similarly, D has plenty of
> libraries if you count its ability to link to C.  It's just that you have to write
> in crufty C style or write non-trivial D-ified wrappers to use them.

We still need years to see a full implementation of proposed features. Even the latest compilers lacks many features, sometimes half.
I NTL enjoy seeing benchmarks on new features, not a change in user code but dramatic performance gains as a result of the standard library and language changes (rvalue).