This is the mail archive of the
mailing list for the GCC project.
Re: Removal of pre-ISO C++ items from include/backwards
On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
> 'deprecated' in the standard does not carry much semantics weight,
> unless the feature is also removed. But, even then we would have to
> worry about existing codes that were written using the feature. That
> is one of the reasons why I'm unsympathetic to proposals before the
> committee to `deprecate' things.
I think this is the wrong idea. Deprecated does carry a lot
of weight. It allows a new compiler without a legacy
to elide the feature and specify it is ISO compliant
'minus' the deprecated features, which is quite different
In particular, for a product like gcc it means a switch
like --no-deprecated-features can be added and then
used by a client without risking 'all bets are off
since the compiler isn't conforming'.
Note I'm entirely agreeing with your the first line I quote
from you above, but questioning lack of sympathy with proposals
to deprecate features considered undesirable.
A shop writing new code may tell programmers not to use
deprecated features because the committee of 'experts'
thinks they're undesirable, and enforce that with a switch,
thereby attempting to enforce an improvement of code quality,
and i would not laugh at such a policy, so I think 'deprecating'
features really can have positive impacts.
In fact if I may cite a REAL example from my own code in the
last few days .. gcc 4.2 is now complaining about 'conversion
of string literals to char* is deprecated'.
Thanks you gcc! I have fixed all the examples. I believe
my code quality is now better. By gcc 5.0 I expect and hope
this deprecated feature will cause a hard error unless
I specify a --allow-deprecated-features type of switch.
Deprecation is a migration path -- isn't that what C++
is all about with respect to C?
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net