Re: Removal of pre-ISO C++ items from include/backwards

[skaller <skaller at users dot sourceforge dot net>]

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
from 'non-compliant'.

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