This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 criticizing anybody.)

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.


Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]