Re: C++ PATCH: PR 20599 (1/3)

[Benjamin Kosnik <bkoz at redhat dot com>]

> > At the same time, I (still) believe we badly need a global strategy for 
> > the C++0x features, for those features adding keywords, 
> > incompatibilities, and all the others
> 
> We definitely need such a strategy.  I think that this is a big enough 
> deal that we should try to get a meeting of the minds here, and then get 
> explicit buy-in from the Steering Committee.  I would imagine the SC 
> would sign off on our plan -- but I thin we should run it by them, since 
> the decisions we'll make could have a pretty wide-reaching effect on GCC 
> users.

I'm heartened to see a C++ FE maintainer respond to this.

I think it's past time for us to get on the ball WRT these issues.

> In particular, while it seems reasonable to add a c++0x mode, and 
> document it is an explicitly unstable and possibly varying in future, 
> experience tells us that people will build code relying on whatever the 
> current implementation is and that those people will be unhappy when the 
> implementation changes.  The problem of source incompatibility from 
> version to version, in both C and C++, was something that was raised at 
> the GCC Summit, and is also something that has been expressed to me as a 
> concern by many of CodeSourcery's customers.
> 
> It's easy to say "well, we warned the users, it's their problem" -- but 
> I don't think that's necessarily how we best convince people to prefer 
> G++ to competing alternatives.

Right. The problem is, some of these experiments will be immediately
useful. It follows naturally that people will want to use such features.

As a person who gets customer feedback, you must be familiar with the
constant and diametrically-opposite customer demands:

1) stability!
2) latest-greatest!

A small peek at Doug's examples documentation shows some interesting
use cases. A peek at tr1/tuple and tr1/functional will explain my interest....

I really think that compiler support is necessary for the kinds of
library designs that ISO C++ has presented to the C++ community in the
form of TR1. It behooves the compiler implementers to get their hands
dirty with this stuff before we have another export on our hands... and
while TR1 is not set in stone as the next official standard.

> Also, without casting any aspersions whatsoever on Doug or his patches, 
> previous substantial changes to the C++ front end have sometimes 
> unintentionally resulted in oscillations in what is or is not accepted. 
>     (I am personally responsible for much of the damage, including bugs 
> that I still need t fix for the upcoming 4.2 release, so I'm in no way 
> criticizing anybody.)

This is the nature of all large patches.

> So, I'm somewhat hesitant to incorporate changes before the standard is 
> sufficiently final.  At the same time, I of course think that providing 
> support for the latest and greatest form of the C++ language in G++ 
> would be a very good thing.

I think g++ rocking out on the bleeding edge is essential to C++0x.

> I'm not sure how to balance these two things.  One approach would be to 
> put 0x code on a branch, and merge it wholesale at some point in the 
> future.  Another would be to explicitly disable the 0x code, unless 
> enabled with a configure option.  Another would be to print a warning on 
> every compilation when the enable-0x option was used.  All of these 
> options are bad, either because they are ineffective, inconvenience 
> users, or inconvenience developers -- or all of the above.
> 
> Thoughts?

My preference is to explicitly disable, unless enabled with a configure option.

For the library parts, I don't know what to do.

I would really like to start assuming TR1 support, as it's in the WP.
We're not really going to have an idea how C++ + TR1 work together
unless we start using it.

I realize this is problematic. Another approach would be to say
"libstdcxx_so_7-branch" is the C++0x library, period.

-benjamin