This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH: PR 20599 (1/3)
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
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.
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
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'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.
(650) 331-3385 x713