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

There is already template "export" (though it's only implemented on one compiler (front end), EDG), but it doesn't work very well. :) That is, due to the way C++ templates work, it doesn't break the dependency between the declaration and definition (unlike non-template functions).

However, the "concepts" may do something about this, as it means that with it, template instantiation site and template definition site can be independently type-checked, giving us a similar type checking for templates, as for non-templates, and this is something you can't do with current templates.

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

As Mr. Stroustrup has said, he gets letters from people complaining that C++ is too complex, but they would still like to add a feature or two... :)

Yes, you have a good point about properties: As Stroustrup has said, a focus of the C++ language development (ever since the start, from what I can tell), is to give general features that work well together, rather than special-case constructs, where possible. As a result of this, a lot of cool stuff is invented or discovered for C++, all the time. As you point out (and others, like Lois Goldthwaite: "C++ Properties - a Library Solution (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)", it's possible to implement properties in the current language.

It's similar with things like lambda (like Boost.Lambda), but we could really use language support, here. However, as has been pointed out in this discussion, it comes down to the available manpower in the committee, who all work for free (and membership is available to all), so the C++ development is really a kind of "open source" project.

GC requires type information. Current GCs do not have type information in their hands, so they have to scan all the available data for finding pointers. And then they have to do various tricks in order to find if something is a pointer or not. And let's not forget weak pointers and GCs, which are not possible as the language is right now.

What I have done in order to have weak pointers in my own GC is to have the high bit set if it is a weak pointer. Since using the high bit makes the pointer point into some unreachable or kernel area, this solution works, and it is quite efficient. But it is a hack.

Regarding properties, whoever said that "The subtle advantage of "hiding" a private data member by treating it as a public data member escapes me" is totally wrong (in fact that article has so many holes in it, I do not know where to begin from; and it is funny that the author then goes on to implement properties at library level). It makes a huge difference in programming, especially in things like GUI frameworks. Properties is about simplicity. Whoever says "it is not C++", well, it is not the C++ you are used to, but I do not see any reason why it shouldn't be there. If you don't like it, don't use it. After all, C++ is the language of freedom: you don't pay for what you don't use.

As for all the other things requested, I was the guy that wrote the long list of "things I want" and "things that are wrong" in Slashdot. Again, I apologize for being bitter, but it just seems so impossibly wrong to wait for 10 years for 'auto' to possibly be adopted (for example).

Thank you Dr. Stroustrup not only for designing an excellent language and providing so many of us opportunity for employment, but also for writing the article and participating in this forum.

I can't say enough good things about the design of C++, but they can't all fit here. Of course I have some suggestions, but this isn't an appropriate forum for them. To be honest, I feel like any suggestions I made here, would fall on deaf ears. Your article is not asking for our feedback, but simply telling us what the committee has decided. The committee seems to have a pretty clear vision of what it is going to do, and how it is going to do it, irregardless of the viewpoints of the community.

The only point I do want to bring up is that it is very hard for people with little or no formal academic background and little funds or resources (e.g. myself) to make contributions or suggestions for the direction to the language. Other languages welcome or encourage community feedback and participation, whereas C++ seems to have an ivory tower approach to the language design.

You may not agree with this characterization, but from my point of view and that of many other enthusiastic C++ users that is the case. The only publicly accessible place for contributions is the comp.std.c++ newsgroup where the attitude is consistently patronizing and dismissive.

As a result the language is moving in direction which is guided more by compiler implementers, experts who've forgotten their humble beginnings, and academics, leaving the rest of us out in the cold hoping you will throw us a bone.

Part of the problem excluding the majority of users from the evolutionary process, is that some very poor decisions get made, and some very good opportunities are overlooked because the knowledge pool you are drawing upon is simply too narrow.

I understand language design isn't easy, but I think more transparency, and community involvment is warranted, especially early on with proposal and such, and is crucial for C++ to continue to be a relevant programming language over the long term. There are a lot of advanced users who may have a thing or two to say about the language proposals.

> Regarding properties, whoever said that "The subtle
> advantage of "hiding" a private data member by treating it
> as a public data member escapes me" is totally wrong (in
> fact that article has so many holes in it, I do not know
> where to begin from;

Since it has so many holes, you say, could you name a few?

> and it is funny that the author then
> goes on to implement properties at library level

The author (Lois Goldthwaite) explains that in the paper:

"It is a foregone conclusion that TG5’s deliverable [C++/CLI] will include support for properties as a feature of the core language. But I want to explore how far a portable C++ library implementation can go in providing the perceived advantages of properties, without requiring any change in the compiler. If this approach proves fruitful, it could lead to a coding style usable in both dialects of C++."

(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)

In other words, she argues that if you want it, you can do it as a library solution: You don't have to change the core language to get it. That makes perfect sense in this context; it's not funny at all.

). It
> makes a huge difference in programming, especially in
> things like GUI frameworks. Properties is about
> simplicity. Whoever says "it is not C++", well, it is not
> the C++ you are used to, but I do not see any reason why
> it shouldn't be there. If you don't like it, don't use it.
> After all, C++ is the language of freedom: you don't pay
> for what you don't use.

A language change has several costs, even for "perfect" features (i.e. ones that don't break backwards compatibility), such as cost of making a proper specification, compiler or library implementation, education, etc. The principle you refer to is about cost in terms of speed/memory use, _not_ about the cost of adding features. Don't muddle the two, they are very different.

> As for all the other things requested, I was the guy that
> wrote the long list of "things I want" and "things that
> are wrong" in Slashdot. Again, I apologize for being
> bitter, but it just seems so impossibly wrong to wait for
> 10 years for 'auto' to possibly be adopted (for example).

As I wrote in the reply to you, there, if people like yourself (who want these things) participate in the language development, we could probably have had done more, by now. The point is that someone has to _do_ these things; it's "easy" enough to propose a bunch of features, and then complain that "noone does the work of implementing them"... The committee has a very long wishlist (similar to the one you posted), but limited manpower to implement it in the language. Even so, C++ is one of the most complex and feature-rich languages around.

First of all, thanks to Bjarne for creating this wonderful language.

Regarding the article, I don't like much the syntax:

template<class T> using Vec = vector<T,My_alloc<T>>;

I would prefer using "typedef" and the possibility of strong typedefs, so that we can predeclare Vec.

I think these new features are ok but we need libraries for network, serialization, inter-process communication, xml, data-base, threads... Boost is a great effort that I think will push C++ a lot in many areas.

Apart from features of the article, and following recent C++ discussions, I'm very impressed with the "move" semantics and their performance boost. We can avoid a lot of memory allocations with them (we can build a container of noncopyable elements, for example).

I don't think garbage collector is needed at all. I think that breaks C++ constructor/destructor model (when are the destructors called?) and that new smart pointers can avoid nearly all manual memory management. And memory is not the only resource you have to manage, so I don't know if garbage collector overhead is justified.

I would also like to see utilities for low-level programming:

-> Controlling alignment.

-> Guarantees of binary layout for structs with constructor/destructor and no virtual functions and inheritance (enhanced POD-s). I think that it can be a good way to make class and struct different (struct would offer guarantees, but class is allowed to reorder members). I think that almost every C++ compiler uses C struct rules when the struct has constructors/destructors, so this wouldn't be breaking. This will be a HUGE help when programming these type of low-level structures.

Anyway, thanks for the article and I will continue reading all WG21 papers. I think C++ has a bright future.

> I can't say enough good things about the design of C++,
> but they can't all fit here.

Thanks

> Of course I have some
> suggestions, but this isn't an appropriate forum for them.
> To be honest, I feel like any suggestions I made here,
> would fall on deaf ears. Your article is not asking for
> our feedback, but simply telling us what the committee has
> decided.

Actually, I often ask for input. For example, http://public.research.att.com/~bs/rules.pdf . This latest paper (being extremely short) just happens not to say so explicitly.

> The committee seems to have a pretty clear vision
> of what it is going to do, and how it is going to do it,
> irregardless of the viewpoints of the community.

I wish the committee had a clearer vision, but then diverse groups rarely have. What the committee does have - which is not well understood in the community - is a rather strong understanding of its own limitations and constraints. There are just so many things we'd like to do, but so littel time and so few resources.

> The only point I do want to bring up is that it is very
> hard for people with little or no formal academic
> background and little funds or resources (e.g. myself) to
> make contributions or suggestions for the direction to the
> language. Other languages welcome or encourage community
> feedback and participation, whereas C++ seems to have an
> ivory tower approach to the language design.

I don't think so, if you want ivory tower approaches, have a look at the hundreds of academic language projects - however, do take an advanced course in type theory before you start. The C++ approach is very pragmatic and seriously constrained by real-world concerned.

Making changes to a language used by millions is challenging, so you can't just walk in and say "I like that so we should do it and expect people to listen". However, all the written material (more than you ever wanted to see) is available on the WG21 site. The standards process is open and - believe it or not - cheap compared to other processes defining our world. Try affecting the way a DVD is encoded or what it takes for a pilot is certified to see what I mean. I believe that the simple fact that a fair part of our civilization depend on C++ code implies some requirements and constraints. However, the investment for an individual is mostly time (weeks a year) and - if you want to vote - $800 a year.

> You may not agree with this characterization, but from my
> point of view and that of many other enthusiastic C++
> users that is the case. The only publicly accessible place
> for contributions is the comp.std.c++ newsgroup where the
> attitude is consistently patronizing and dismissive.

comp.lang.c++.moderated is less rude. The members of the committee makes all the committee documents available (on the WG21 site) and many of us give talks and write papers to raise interest and get feedback. I have now personally been talking about the design of C++0x and listend to responses for 5 years.

> As a result the language is moving in direction which is
> guided more by compiler implementers, experts who've
> forgotten their humble beginnings, and academics, leaving
> the rest of us out in the cold hoping you will throw us a
> bone.

Not a kind characterization and the "throw a bone" is simply unfair.

> Part of the problem excluding the majority of users from
> the evolutionary process, is that some very poor decisions
> get made, and some very good opportunities are overlooked
> because the knowledge pool you are drawing upon is simply
> too narrow.

How do you draw on 3 million people? Many of us in the committee are acutely aware of our limitations. However, we are not excluding anyone, we just don't know how to further lower the barriers to entry and also make progress.

> I understand language design isn't easy, but I think more
> transparency, and community involvment is warranted,
> especially early on with proposal and such, and is crucial
> for C++ to continue to be a relevant programming language
> over the long term. There are a lot of advanced users who
> may have a thing or two to say about the language
> proposals.

It will be hard to increase "transparency" since already every paper is available and every meeting is public.

One problem is actually that *every* programmer (advanced or not) is more than willing to give an opinion after almost a minute of thought. That tends to drown out the thoughtful contributions. Just have a look at yesterday's "discussion" on /.

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

> First of all, thanks to Bjarne for creating this wonderful
> language.

Thanks

> Regarding the article, I don't like much the syntax:
>
> template<class T> using Vec = vector<T,My_alloc<T>>;
>
> I would prefer using "typedef"

So did I initially, but I'm convinced that getting the name being declared up front is very important. My guess is that you'll get used to it or even get to appreciate it when you get to deal with more complex examples.

> and the possibility of
> strong typedefs, so that we can predeclare Vec.

There are several meanings of "strong typedef". Some are being explored and none are directly related to template aliases.

> I think these new features are ok but we need libraries
> for network, serialization, inter-process communication,
> xml, data-base, threads... Boost is a great effort that I
> think will push C++ a lot in many areas.

Yes. That was the idea behind boost.

> Apart from features of the article, and following recent
> C++ discussions, I'm very impressed with the "move"
> semantics and their performance boost. We can avoid a lot
> of memory allocations with them (we can build a container
> of noncopyable elements, for example).

yes.

> I don't think garbage collector is needed at all. I think
> that breaks C++ constructor/destructor model (when are the
> destructors called?) and that new smart pointers can avoid
> nearly all manual memory management. And memory is not the
> only resource you have to manage, so I don't know if
> garbage collector overhead is justified.

but other people vigurously disagree. My guess is that we will find a solution that will be helpful to many and disasterous to none.

> I would also like to see utilities for low-level
> programming:
>
> -> Controlling alignment.

being worked on.

> -> Guarantees of binary layout for structs with
> constructor/destructor and no virtual functions and
> inheritance (enhanced POD-s). I think that it can be a
> good way to make class and struct different (struct would
> offer guarantees, but class is allowed to reorder
> members). I think that almost every C++ compiler uses C
> struct rules when the struct has constructors/destructors,
> so this wouldn't be breaking. This will be a HUGE help
> when programming these type of low-level structures.

The snag is that C doesn't have such layout guarantees either. however, we do encourage layout compatibility of PODs with their C equivalents and I don't know of any C++ compiler that doesn't provide that.

No fundamental distinction between classes and structs will be introduced.

> Anyway, thanks for the article and I will continue reading
> all WG21 papers. I think C++ has a bright future.

So do I.

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

> Your article is not asking for
> our feedback, but simply telling us what the committee has
> decided.

The committee has been soliciting feedback for several years, now, for the next version of standard, and have got lots of feedback and contributions. However, at the Lillehammer meeting last spring, it was decided that in order to be able to publish the standard in 2009 (ISO standards are updated/confirmed in about 10 year intervals, and the current standard is from 1998, with a 2003 revision/correction), a cutoff-date for new proposals was set half a year into the future, to last year's fall meeting, and I think this has been mentioned in articles, etc. about the development of C++. This is because the committee already have more on its plate than can reasonably be implemented (given there's only two meetings per year), but it was also said that new proposals could still be submitted after that time - there just weren't any guarantee that the committee would get a chance to consider it.

> The only point I do want to bring up is that it is very
> hard for people with little or no formal academic
> background and little funds or resources (e.g. myself) to
> make contributions or suggestions for the direction to the
> language. Other languages welcome or encourage community
> feedback and participation, whereas C++ seems to have an
> ivory tower approach to the language design.

C++ is an ISO standard, and as such, there are procedures regarding how, and how often, it may be changed. Independent language developers (like yourself) are not that "constrained" by issues like this (or the concerns of millions of existing users, and ditto lines of existing code).

However, if you or anyone else have any suggestion for ways to improve community interaction, or other ways to improve the development of the language, I'm sure it would be most welcome. Just remember that it typically takes someone to do it, as well...

> I understand language design isn't easy, but I think more
> transparency, and community involvment is warranted,
> especially early on with proposal and such, and is crucial
> for C++ to continue to be a relevant programming language
> over the long term.

Yes, this is all good and fine, but how? The proposals are all publicly available at the standards site. If someone would like to get directly involved in the standards work, they can contact their ISO "national body" (the organization in their country affiliated with ISO), and request membership. Unfortunately, in many countries, this costs a yearly fee, that goes to paying ISO. You then get access to the mailing lists of the committee, and so on. Then there's the newsgroups that have been mentioned.

> Actually, I often ask for input. For example,
> http://public.research.att.com/~bs/rules.pdf . This latest
> paper (being extremely short) just happens not to say so
> explicitly.

My apologies then, you are clearly more interested in feedback than I gave you credit for.

> Not a kind characterization and the "throw a bone" is
> simply unfair.

My apologies again, that was indeed far more rude than I intended.

> How do you draw on 3 million people? Many of us in the
> committee are acutely aware of our limitations. However,
> we are not excluding anyone, we just don't know how to
> further lower the barriers to entry and also make
> progress.

It seems to me it would not be so hard to create a process where the public can submit small semi-formal requests for language changes and language features. These could be sorted and grouped and summarily evaluated by a panel of experts, in order to look more closely at those with the most promise and request more details from the submitters. This process would be useful for the committee to identify trends and general public opinion. Funding such a project could be done by community members who paid a nominal fee (e.g. $25) to join in order to be allowed to submit topics and discuss them.

> It will be hard to increase "transparency" since already
> every paper is available and every meeting is public.

Yes, transparency is the wrong word sorry.

> One problem is actually that *every* programmer (advanced
> or not) is more than willing to give an opinion after
> almost a minute of thought. That tends to drown out the
> thoughtful contributions. Just have a look at yesterday's
> "discussion" on /.

I sympathize with that. In fact I refuse to read Slashdot anymore, the level of discussion there is an embarassment to the technical community. I am actually surprised you bothered to read it.

Well I really appreciate very much you taking the time to write back, and to read what I had to say. I look forward to using the C++ 0x.

Keep up the excellent work. I greatly appreciate the attention to detail and the fine craftmasnship that has gone into the creation of C++.

> As Mr. Stroustrup has said, he gets letters from people
> complaining that C++ is too complex, but they would still
> like to add a feature or two... :)

But seriously, that makes sense at least sometimes. C++ is complex to learn (or at least to master), and not much be done about it, but by adding features like module system (or at least standardized "#pragma once" instead of header guards), type inference, lambda expressions,... it can be made easier to use for working programmers. What's wrong with that?

I think properties should be part of the language. This is just too useful in practice not to have directly in the language. I know of Strousup's reluctance to this, yet I don't get it. This is the single best feature of the language, yet it's not official nor found in most implementations.

I realise that this cannot be changed now that the language has been used for so many years, but the "private" keyword should really have signaled a class as being final and un-subclassable/non-virtual. private should not be allowable if there are virtual functions. This has caused no end of aggravation in code reuse, especially in compiled libraries. An object should always have the right to look at ALL of its own private parts no matter its lineage. Otherwise, virtual functions lose their virtual-ness by possibly using private data. You could blame this on the implementor, but in practice, it's not that easy. You can't foresee how people will use your code.

I also agree with another post that alignment should not be made in pragmas or __attribute__(())'s. They should be in the language itself and should be readable from object code. Otherwise, it's impossible to use two different libraries that use different alignments without purposely padding structures.

These are real-world situations that have caused the most amount of aggravation IMHO.

Gotta watch ctrl-z. I meant to type Mr. Stroustrup. Sorry for the "typo" and I can't find the edit button.

> > As Mr. Stroustrup has said, he gets letters from people
> > complaining that C++ is too complex, but they would
> still
> > like to add a feature or two... :)
>
> But seriously, that makes sense at least sometimes. C++ is
> complex to learn (or at least to master), and not much be
> done about it, but by adding features like module system
> (or at least standardized "#pragma once" instead of header
> guards), type inference, lambda expressions,... it can be
> made easier to use for working programmers. What's wrong
> with that?

I suggest a small exercise: Look back at this brief discussion (less than two days, about 15 participants, about 40 messages) and count the number of suggested extensions, also note which ones were deemed "obvious", "long overdue", "most needed", etc.

That done, try putting yourself in the shoes of the committee and decide how to proceed.

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

PS I saw no suggestion that would have been new a couple of years ago.

> I suggest a small exercise: Look back at this brief
> discussion (less than two days, about 15 participants,
> about 40 messages) and count the number of suggested
> extensions, also note which ones were deemed "obvious",
> "long overdue", "most needed", etc.
>
> That done, try putting yourself in the shoes of the
> committee and decide how to proceed.

Well, I also suggested "obvious" and "most needed" features, while considering other peoples' proposals (such as properties, run-time reflection or GC) " bad", "dangerous" or even "disastrous" :)

The comitee obviously cannot please everybody. However, I can't help but feel that C++ was progressing much faster before it was standardized. Did you really please *everybody* when you introduced multiple inheritance or exceptions, for instance? OK, this is not a fair question, because I read "The Design and Evolution of C++" (great book, BTW!) so I know the answer, but the point is that these features really make our work more enjoyable.

In short, maybe the comitee should pay less atention to "the crowd" (me included) and just push forward. In the past it worked very well - I see no reason why it wouldn'twork in future as well.

And finally (and it should have been really the first sentence in my first message), let me thank you for the great job you have done so far, and wish you success in the future. C++ is a great programming language; I have enjoyed programming with it in the past 10 years and hope to continue so at least for another decade.