/* What about more advanced features, like "import"? Putting templates into headers is not would I want to do.
*/

I believe that precompiled headers offers what the "import" crowd is asking for. Precompiled headers *are* available in C++, but like GC they aren't mandated, just allowed.

/* On Slashdot site people are asking for other features that are interesting for me too: Vtable manipulation,
*/

This is interesting. Objective C allows it (if "it" is what I think it is), as does calling Lua, Perl, or Python from C++. Or even using something like Amulet did (http://www.cs.cmu.edu/~amulet/ ).

/* ... (skip several that I'm not familiar with)

Closures are also nice, but they will require GC, because otherwise it will be difficult to track all internal objects and clean them up.
*/

How about function-like objects? (http://public.research.att.com/~bs/bs_faq2.html#function-object ).


/* And now - standard socket and threading libraries.
*/

They are nice. I understood Stroustrup's post to mean that there will be standard threading libraries, but as sockets require OS support, I wouldn't expect the language committee to cover them.

Function objects work, but they need automatically include references to all external data, including data on a stack (that will not exist after the function object is returned). Java does it automatically with local classes. Maybe instead of "closures" we should ask for local classes.

I think that (some of) you are reading far too much into one short and "popular" article. If you want to understand what C++0x might be in any detail, you have much more information available to you. For starters see: http://public.research.att.com/~bs/papers.html
and the "wish lists" on http://public.research.att.com/~bs/C++.html .

For gluttons for punishement there is the standards committee website: try google("WG21").

Please remember that until the final votes nothing is final; C++0x is work in progress. We (the members of the committee) would like feedback and suggestion, preferably feedback and suggestions based on more than a couple of seconds thought. We are working for a huge community: http://public.research.att.com/~bs/applications.html .

-- Bjarne Stroustrup; http://www.research.att.com/~bs

I forgot one more thing - is it possible to get overloading by result type?

> I forgot one more thing - is it possible to get
> overloading by result type?

Don't hold your breath. The additional complexity of the overload resolution would be significant. It would take a lot of demonstrated need for C++0x to go that way.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

How about lambda expressions?

Also, I would add that C++ is moving too slowly. Even C#, which was a joke in version 1.0 and mediocre at version 2.0 offers very interesting features in version 3.0, and it will be out probably just a couple of years from now. C++ 0x enabled compilers will not appear before 2010, and I am afraid we will be hopelessly behind other languages by that time.

> How about lambda expressions?

Maybe. There is much talk, but no concrete proposals. I think that simple lambdas could be a good thing. However, syntactically heavy lambdas or an attempt to completely support functional programming could be complete disasters.

> Also, I would add that C++ is moving too slowly. Even C#,
> which was a joke in version 1.0 and mediocre at version
> 2.0 offers very interesting features in version 3.0, and
> it will be out probably just a couple of years from now.
> C++ 0x enabled compilers will not appear before 2010, and
> I am afraid we will be hopelessly behind other languages
> by that time.

In terms of "sexy new features" maybe, but other languages have their own problems where it matters: to deliver correct, well-performing, and maintainable software. C++ isn't perfect, but neither is any of its competitors.

Note also that C is still very much alive despite its complete absence of modern features.

Web discussions may be beauty contests, but real-world software development rarely are just that.

I think that the greatest strength of "other languages" is not that they are better languages, but that they come with larger collections of "free" libraries.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Garbage collection is necessary if C++ wants to support closures which outlive the scope of their creation (upward closures), where free variables are determined implicitly from the set of names used in their bodies, instead of being explicitly named and copied (as in function objects created by binders or manually).

Optional GC is not enough. Upward closures are just incompatible with the C++ semantics of storing observably copied objects inside local variables. The function has no way to refer to the object through a local variable if the variable is already destroyed when the function is applied. Implicit observable copying of free variables would be insane, incompatible with the treatment of global variables.

I don't believe that C++ will support real GC, and thus it will not support upward closures either.

Here is one thing which I wish C++ had, which would improve the possibility of linking it with other languages, and which I believe seems realistic to add.

It's currently impossible to write a generic wrapper around a piece of code which catches arbitrary exceptions it might throw, and materializes them in a form which allows to check their type dynamically and rethrow them from elsewhere.

This means that when we are wrapping a C++ library in another language which implements exceptions differently than C++ does, for each piece of wrapped C++ code we must statically know all types of exceptions it might throw.

For others we can at most add a generic catch (...) clause, and there the exception object will be lost, even if the control flow tunnels through the other language to another piece of C++. We can't save the exception object for later if we don't statically know the possibilities for its type!

> In terms of "sexy new features" maybe, but other languages
> have their own problems where it matters: to deliver
> correct, well-performing, and maintainable software.

Don't get me wrong - I wouldn't dream of picking anything but C++ for a mid-size or big project. It just scales so beautifully - you can use advanced abstraction mechanisms and inline assembly in the same file, and I am not aware of any other popular language that offers this ( hopefully Walter Bright will not jump in with his D evangelism here ;) ).

However, "sexy features" are needed at least to attract CS students and enthusiasts in general. You created C++ to make programing more *enjoyable* experience, and that was a great goal. Why not continue that path?

First of all, I would like to give you two thumbs up Mr.Stroustrup for a language I've been using with passion for so many years.

There's two things I find missing in the article, and I hope it doesn't mean they won't appear in C++0x.

The first one is a module concept. I find #includes and everything they imply, like include guards, separated .hpp and .cpp, compiler-dependent precompiled headers, etc. to be the worst part of C++. I would hope the standard would define common grounds, something like an #import statement or proposed namespace<< syntax, that would simplify our day-to-day lives while still leaving compilers flexibility in the implementation.

The second thing is better meta-programming tools. I don't know if a solution as ambituous as metacode keyword is possible, but there's a lot of things that could be simplified and possible with a complete compile-time language. Among these things, introspection, could also be possible with a more complete RTTI (but something like CTTI sounds better to me). Having the capability of iterating through members of a class would be wonderful for both implementers and users of libraries like Boost.Python.

(I'm aware on some Daveed Vandevoorde papers on these subjects, so I guess it is still possible to see them in next standard.)

Regards,
Nicolas Fleury

> First of all, I would like to give you two thumbs up
> Mr.Stroustrup for a language I've been using with passion
> for so many years.

Thanks

> There's two things I find missing in the article, and I
> hope it doesn't mean they won't appear in C++0x.
>
> The first one is a module concept.

As you obviously know, there is work in progress on modules, but as ever "no guarantees".

>
> The second thing is better meta-programming tools. ... Among these things, introspection, could also
> be possible with a more complete RTTI (but something like
> CTTI sounds better to me). ...

Most forms of meta-programming with a run-time representation of types are very expensive. For example, I'm told that common C++ applications under windows are 80% code and 20% data; when compiled under .Net (with .Net metadata) they become 20% code and 80% data. Calculate the bloat for yourself.

Many applications cannot afford that. Also it is a huge amount of work to formalize a representation and finally, I worry about the correctness of code depending on "ad hoc" climbing of metadata graphs.

I woudn't give high odds on this.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

> > I forgot one more thing - is it possible to get
> > overloading by result type?
>
> Don't hold your breath. The additional complexity of the
> overload resolution would be significant. It would take a
> lot of demonstrated need for C++0x to go that way.
>
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

I do not see why it is difficult. It is already possible by returning a wrapper that lazily executes different actions in cast operators. So overloading by result type would just make it official.

- Alexey.

> As you obviously know, there is work in progress on
> modules, but as ever "no guarantees".

Fair enough:)

> > The second thing is better meta-programming tools. ...
> Among these things, introspection, could also
> > be possible with a more complete RTTI (but something
> like
> > CTTI sounds better to me). ...
>
> Most forms of meta-programming with a run-time
> representation of types are very expensive. For example,
> I'm told that common C++ applications under windows are
> 80% code and 20% data; when compiled under .Net (with .Net
> metadata) they become 20% code and 80% data. Calculate the
> bloat for yourself.

I agree that meta-programming in C++ should remain compile-time (sorry, I realize I wasn't clear).

I'm more thinking of CTTI (compile-time type information) than RTTI. I remember having a quick exchange with David Abrahams where he ended suggested it would be nice to have the capability to get a mpl::vector of types of members. A compile-time list of member types for a type.

> Many applications cannot afford that. Also it is a huge
> amount of work to formalize a representation and finally,
> I worry about the correctness of code depending on "ad
> hoc" climbing of metadata graphs.

The way I see it, the representation is already formalized, since members already have types. What is needed is a standard compile-time type list (so far, just extending STL) and a way to get 2 type lists, one of members of a type and another of its base classes. STL could contain the compile-time functions/typedefs to get these. It doesn't sound too bad to me. The only run-time overhead is the memory used to have also access to member names (but since it's compile-time, it's only for used member names).

I believe compile-time introspection would be a very powerful tool (and that includes some compile-time checks that will be available in C++0x). I've actually developed a system adding introspection to C++ for our needs where I work and compile-time introspection would simplify both users life and mine (I would like to go on details on that system, contact/tell me if interested).

> I woudn't give high odds on this.

Even compile-time based?

Regards and thx for reading me,
Nicolas Fleury

Original text
==========================
no properties. For example, GUI libraries have 100s of widgets, yet we still have to write getFoo(), setFoo(), isFoo() etc. By using properties, code would be greatly simplified, and there would be no run-time overhead since properties is about syntactic sugar
==========================

Sorry, but I must demur.

There is a perfectly effective, 100% speed-efficient, and, syntax aside, adequate mechanism of implementing properties in C++, as described in Chapter 35 of (my book) Imperfect C++. (To tame the syntax, it uses macros, which is a bit of a shame, but other than that it is without substantive flaw. It also facilitates the user having an overhead of one byte (+packing) per class, irrespective of the number of properties.)

The latest release of the recls library incorporates properties into the recls/C++ and recls/STL mappings. (Downloadable from http://recls.org/)

I'm currently working on a substantial library, called XMLSTL, which is a library that wraps (currently) MSXML and Xerces DOM, with SAX and other XML libs to come. It unifies syntax between the underlying libraries, has minimal coupling, and uses my C++ Properties technique. I am hoping to get an alpha out for the people who've expressed interest thus far (and anyone else) to play with this month. (Perhaps lacking in humility / realism, I see no reason at this stage that this won't be an adequate answer to the call for submissions on XML presented in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html, and will be working towards that this year.)

On a broader point, I don't see what all the fuss is about. Apart from auto, which will be a huge boon, there's precious little lacking in current C++ for anyone willing to apply a little imagination. Sorry if that's a too-last-century opinion. :-)

Cheers

Matthew