"James Russell Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3D8A6560.D2A05077@wizard.net...
> "P.J. Plauger" wrote:
> ....
> > 2) We live in an era where large companies tell large compiler vendors
> > where to get off. A standards committee can remove a feature, and some
> > vendors might even go along; but I promise you that all the serious
> > vendors will keep *all* past language features for many years to come.
> > So deprecation, and even removal, is largely an academic gesture these
> > days, at least for any language standard that retains any commercial
> > importance.
>
> Is there any feature, of any language, that has gone through all of the
> following steps (without the language losing commercial importance)?
>
> The feature is:
> 1) widely used
> 2) officially deprecated
> 3) removed from the standard
> 4) removed from most implementations, at least from the mode that's
> intended to remain standard-conforming
> 5) removed from default mode of most implementations
> 6) removed from all modes of all implementations

I'm guessing, since I haven't done any Fortran programming for 15 years, but
what about arithmetic if statements?  They were certainly widely used in
Fortran 2, stopped being so in Fortran 4, and were wholly obsolete by
Fortran 77.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 25 Sep 02 04:51:43 GMT, Erik Max Francis <max@alcyone.com> wrote:

>James Kanze wrote:
>> Yes, in    6.11.7..  I wonder what the difference is between
>> "obsolescent" and "deprecated".
>
>I would presume that in this context they are synonymous.

In the context of C99 the term obsolescent is "defined" in
Introduction, bullet 2.

>C++97 only
>uses the word _obsolescent_ in reference to the C Standard; _deprecated_
>is defined within C++ in C++97 D/2.  The "obsolescent" C features are
>all defined in C99 6.11.

However P.J. Plauger said that 'deprecated' is an ISO term. Does
anybody know the ISO definition?


Genny.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
news:3u43pu0m2f17sbagjtejl6dh842nli6v2i@4ax.com...

 > >C++97 only
 > >uses the word _obsolescent_ in reference to the C Standard; _deprecated_
 > >is defined within C++ in C++97 D/2.  The "obsolescent" C features are
 > >all defined in C99 6.11.
 >
 > However P.J. Plauger said that 'deprecated' is an ISO term. Does
 > anybody know the ISO definition?

I haven't been a convener for six years. If I still have the ISO
documents, they're now buried deep enough in my office to be half
turned to coal.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:

| On 21 Sep 02 15:29:33 GMT, Hyman Rosen <hyrosen@mail.com> wrote:
|
| >James Russell Kuyper Jr. wrote:
| >> Is there any feature, of any language, that has gone through all of the
| >> following steps (without the language losing commercial importance)?
| >
| >I don't know if anything has gone all the way, but one example
| >is old-style C function definitions:
| >
| > int f(a, b) int a; double b; { return a + b; }
| >
|
| I was surprised, when fiddling with the g++ compiler's code, to find this
| old style used extensively!

Yes, when one principal requirement is to be able to bootstrap a C++
compiler with an old C compiler, you naturally find yourself writing
things like that. However, things have been moving these days: the GNU
C++ compiler is moving to getting rid of K&R requirements.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Russell Kuyper Jr. wrote:
> That hasn't even reached the second step of the process. It's still
> perfectly legal, and not marked as deprecated in the current standard.

Isn't it listed as obsolescent?

> Has that ever been anything but undefined behavior?

Sure. Lots of old code relied on this behavior doing the obvious
thing, that is, treating the bits at the machine address as an
object of the casted-to type. Similarly, lots of code relied on
putting something into one union member and taking it out of
another.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." wrote:
>
> Is there any feature, of any language, that has gone through all of
the
> following steps (without the language losing commercial importance)?
>
> The feature is:
> 1) widely used
> 2) officially deprecated
> 3) removed from the standard
> 4) removed from most implementations, at least from the mode that's
> intended to remain standard-conforming
> 5) removed from default mode of most implementations
> 6) removed from all modes of all implementations
>
> If so, how long did it take between each step?
> If not, what's the farthest along that path that any feature has gone?

Fortran definitely has some features that have advanced as far as (3).
I'm not sure if they've reached (4)/(5) yet or not (and I would expect
it to be a MUCH quicker trip through these stages than (6)).  The
features in question would be anachronisms from FORTRAN 66 that have
passed out of common usage outside of dusty decks because they're
unnecessary and error-prone.

I'd guess that the features will pass into "compatibility"-type modes
within the next major release or two, where they will join a bunch of
other features that were never standardized but became widely used
due to limitations in older standards prior to the introduction of
F77 or F90/95.


(FWIW, the features that my documentation indicates were deleted in
Fortran 95 are ASSIGN and assigned GO TOs, assigned FORMAT, branching
to an END IF from outside its IF block, H edit descriptor, PAUSE
statement, and real and double precision DO control variables /
expressions.  Of those, I believe H edit descriptors saw the most
common usage in the days (before I was born) when FORTRAN didn't have
a character type.)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." wrote:
>
> Hyman Rosen wrote:
....
> > I don't know if anything has gone all the way, but one example
> > is old-style C function definitions:
> >
> >         int f(a, b) int a; double b; { return a + b; }
>
> That hasn't even reached the second step of the process. It's still
> perfectly legal, and not marked as deprecated in the current standard.

Sorry, I was thinking of the C standard, rather than the C++ standard -
don't ask me why. Of course, in C++, it's never even reached the first
step.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
>
> James Russell Kuyper Jr. wrote:
....
[Re: K&R style function declarations]
> > That hasn't even reached the second step of the process. It's still
> > perfectly legal, and not marked as deprecated in the current standard.
>
> Isn't it listed as obsolescent?

Not in C. And, while I'm not sure, I don't think it's ever even been
legal in C++.

[Previously:]
> > >         float f = 7;
> > >         short *p = (int *)&f;
> > >         *p = 0;
> > >         cout << f;      // likely to still produce "7"

....
> > Has that ever been anything but undefined behavior?
>
> Sure. Lots of old code relied on this behavior doing the obvious
> thing, that is, treating the bits at the machine address as an
> object of the casted-to type. ...


That's not only the obvious thing; it's the required thing.

That's what makes it undefined behavior - because you're writing a
'short' into a location that makes up only part of a 'float', and then
trying to read that modified float value. The standard guarantees almost
nothing about how either 'short' or 'float' are represented. It most
certainly does not say anything that makes that procedure safe. It may
be safe for particular values of f, on particular implementations where
you know a lot about how the numbers are represented. It certainly won't
be portable, and in general it's undefined behavior because there's no
guarantee in the C++ standard that the modified float still contains a
valid bit pattern.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> wrote in message
news:<1032797893.403755@master.nyc.kbcfp.com>...
> James Russell Kuyper Jr. wrote:
> > That hasn't even reached the second step of the process. It's still
> > perfectly legal, and not marked as deprecated in the current
> > standard.

> Isn't it listed as obsolescent?

Yes, in    6.11.7..  I wonder what the difference is between "obsolescent"
and "deprecated".

> > Has that ever been anything but undefined behavior?

> Sure. Lots of old code relied on this behavior doing the obvious
> thing, that is, treating the bits at the machine address as an object
> of the casted-to type. Similarly, lots of code relied on putting
> something into one union member and taking it out of another.

That doesn't mean that it isn't undefined.

In fact, it has always had the same semantics as a modern
reinterpret_cast, e.g. implementation defined.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Russell Kuyper Jr. wrote:
 > in general it's undefined behavior because there's no
> guarantee in the C++ standard that the modified float
 > still contains a valid bit pattern.

C has the concept of trap representation which covers
situations like this. It says that if an object holds
such a representation, then trying to access it via a
type other than character is undefined behavior. That
still allows a program which knows what it's doing to
muck around with the bits and produce valid data.

C++ just punted on the whole low-level pointer thing.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

> Hyman Rosen <hyrosen@mail.com> wrote in message
> news:<1032797893.403755@master.nyc.kbcfp.com>...
>
> > James Russell Kuyper Jr. wrote:
> >
> > > That hasn't even reached the second step of the process. It's
> > > still
> > > perfectly legal, and not marked as deprecated in the current
> > > standard.
>
> > Isn't it listed as obsolescent?
>
> Yes, in    6.11.7..  I wonder what the difference is between
> "obsolescent"
> and "deprecated".

I would presume that in this context they are synonymous.  C++97 only
uses the word _obsolescent_ in reference to the C Standard; _deprecated_
is defined within C++ in C++97 D/2.  The "obsolescent" C features are
all defined in C99 6.11.

--
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Once the people begin to reason, all is lost.
\__/ Voltaire
    Church / http://www.alcyone.com/pyos/church/
 A lambda calculus explorer in Python.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 21 Sep 02 15:29:33 GMT, Hyman Rosen <hyrosen@mail.com> wrote:

>James Russell Kuyper Jr. wrote:
>> Is there any feature, of any language, that has gone through all of the
>> following steps (without the language losing commercial importance)?
>
>I don't know if anything has gone all the way, but one example
>is old-style C function definitions:
>
> int f(a, b) int a; double b; { return a + b; }
>

I was surprised, when fiddling with the g++ compiler's code, to find this
old style used extensively!

Cheers,

- Alf
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:
>
> James Russell Kuyper Jr. wrote:
> > Is there any feature, of any language, that has gone through all of the
> > following steps (without the language losing commercial importance)?
>
> I don't know if anything has gone all the way, but one example
> is old-style C function definitions:
>
>         int f(a, b) int a; double b; { return a + b; }

That hasn't even reached the second step of the process. It's still
perfectly legal, and not marked as deprecated in the current standard.

> Another example is forbidding type-punning via pointer casts.
> Many compilers are now doing alias analysis based on strict
> enforcement of the aliasing rules:
>
>         float f = 7;
>         short *p = (int *)&f;
>         *p = 0;
>         cout << f;      // likely to still produce "7"

Has that ever been anything but undefined behavior?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
....
> How about pre-ANSI function declarations?
>
>      void foo(a,b,c)
>          int a, b;
>          char*c;
>      {
>          /* ... whatever ... */
>      }

I'm not sure - did that ever go through the deprecation phase? It never
disappeared from C (it's still legal there, and not deprecated), and I'm
not sure whether it was ever legal C++.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3D8A6560.D2A05077@wizard.net...
> Is there any feature, of any language, that has gone through all of
the
> following steps (without the language losing commercial importance)?
>
> The feature is:
> 1) widely used
> 2) officially deprecated
> 3) removed from the standard
> 4) removed from most implementations, at least from the mode that's
> intended to remain standard-conforming
> 5) removed from default mode of most implementations
> 6) removed from all modes of all implementations
>
> If so, how long did it take between each step?
> If not, what's the farthest along that path that any feature has gone?

I don't know if this meets your criteria, but how about for-loop
scoping:

    for (int i=0; i < MAX; ++i) { ... }
    if ( i < MAX ) { ... }

Prior to the standard, the above was valid. Now, "i" is out of scope at
the
second line. This is certainly in step 4/5 of all current compilers. I
guess
since at least the Sun compiler provides a -compat=4 mode to invoke the
pre-standard rules, then 6 has not been achieved. And that feature of
the
Sun compiler may keep *any* feature from making it all the way to the
bottom
of your list ("all" is a pretty exhaustive word).
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin Astronautics
(303) 971-3846




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" wrote:
....
> 2) We live in an era where large companies tell large compiler vendors
> where to get off. A standards committee can remove a feature, and some
> vendors might even go along; but I promise you that all the serious
> vendors will keep *all* past language features for many years to come.
> So deprecation, and even removal, is largely an academic gesture these
> days, at least for any language standard that retains any commercial
> importance.

Is there any feature, of any language, that has gone through all of the
following steps (without the language losing commercial importance)?

The feature is:
1) widely used
2) officially deprecated
3) removed from the standard
4) removed from most implementations, at least from the mode that's
intended to remain standard-conforming
5) removed from default mode of most implementations
6) removed from all modes of all implementations

If so, how long did it take between each step?
If not, what's the farthest along that path that any feature has gone?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"P.J. Plauger" wrote:
>This discussion so far seems to have overlooked two important facts:
>
>1) ``Deprecated'' is a term of art in ISO regulations. If a standard
>labels some feature as deprecated, then it is *easier* to remove it
>from a subsequent version of the standard. Not required, not even
likely,
>just easier. If a committee tries to remove a significant feature
before
>deprecating it, a much smaller minority can oppose the removal with a
>reasonable chance of success. So it doesn't matter whether you contrive
>a handier definition of the term; ISO will trump your ace.

I was not aware if this.  Is there a definition of this term of art
written down in some ISO document that can be cited?  If so, then
it would seem that an appropriate way to close off #223 would be to
remove the formal-sounding language from D/2 and cite the official
ISO definition.

>2) We live in an era where large companies tell large compiler vendors
>where to get off. A standards committee can remove a feature, and some
>vendors might even go along; but I promise you that all the serious
>vendors will keep *all* past language features for many years to come.
>So deprecation, and even removal, is largely an academic gesture these
>days, at least for any language standard that retains any commercial
>importance.

Understood.

nobody


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Russell Kuyper Jr. wrote:
> Is there any feature, of any language, that has gone through all of the
> following steps (without the language losing commercial importance)?

I don't know if anything has gone all the way, but one example
is old-style C function definitions:

 int f(a, b) int a; double b; { return a + b; }

Another example is forbidding type-punning via pointer casts.
Many compilers are now doing alias analysis based on strict
enforcement of the aliasing rules:

 float f = 7;
 short *p = (int *)&f;
 *p = 0;
 cout << f; // likely to still produce "7"


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." <kuyper@wizard.net> wrote
 > Is there any feature, of any language, that has gone through all of the
 > following steps (without the language losing commercial importance)?
 >
 > The feature is:
 > 1) widely used

If it's really "widely used," it probably won't ever be deprecated.

 > 2) officially deprecated
 > 3) removed from the standard
 > 4) removed from most implementations, at least from the mode that's
 > intended to remain standard-conforming
 > 5) removed from default mode of most implementations
 > 6) removed from all modes of all implementations
 >
 > If so, how long did it take between each step?
 > If not, what's the farthest along that path that any feature has gone?

How about pre-ANSI function declarations?

     void foo(a,b,c)
         int a, b;
         char*c;
     {
         /* ... whatever ... */
     }

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow writes:
>In article <3D829DE9.54625F20@wizard.net>, James Russell Kuyper Jr.
><kuyper@wizard.net> writes
>>I'd prefer it to say that "deprecated" means "will definitely be
dropped
>>from the next version of the standard". However, it's generally not
>>possible to be that precise, when scheduling changes to the standard.
>>With that meaning, it would never be used.
>
>I do not think I would go quite that far but I would like to see
>'deprecated' mean that retention in future releases would depend on
more
>than just the normal requirement for protecting legacy code. I.e. being
>currently in the Standard will not be sufficient justification for it
>continuing to be in it, so those that want it retained need to come up
>with positive arguments for doing so.

That's reasonable, and maybe even enforceable (unlike the vague "has
an unusually high probability of being dropped from the standard in
the near future").  Of course, many people (such as myself) think that
it is important to maintain a useful subset of C++ that is also a useful
subset of C;  for such people, that would be sufficient justification
for retaining many of the deprecated features in Appendix D (e.g., the
name.h headers and file scope static).

nobody


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"nobody" <clcppm-poster@this.is.invalid> wrote in message news:am7geh$8pm$1@localhost.localdomain...

 > >>I'd prefer it to say that "deprecated" means "will definitely be dropped
 > >>from the next version of the standard". However, it's generally not
 > >>possible to be that precise, when scheduling changes to the standard.
 > >>With that meaning, it would never be used.
 > >
 > >I do not think I would go quite that far but I would like to see
 > >'deprecated' mean that retention in future releases would depend on more
 > >than just the normal requirement for protecting legacy code. I.e. being
 > >currently in the Standard will not be sufficient justification for it
 > >continuing to be in it, so those that want it retained need to come up
 > >with positive arguments for doing so.
 >
 > That's reasonable, and maybe even enforceable (unlike the vague "has
 > an unusually high probability of being dropped from the standard in
 > the near future").  Of course, many people (such as myself) think that
 > it is important to maintain a useful subset of C++ that is also a useful
 > subset of C;  for such people, that would be sufficient justification
 > for retaining many of the deprecated features in Appendix D (e.g., the
 > name.h headers and file scope static).

This discussion so far seems to have overlooked two important facts:

1) ``Deprecated'' is a term of art in ISO regulations. If a standard
labels some feature as deprecated, then it is *easier* to remove it
from a subsequent version of the standard. Not required, not even likely,
just easier. If a committee tries to remove a significant feature before
deprecating it, a much smaller minority can oppose the removal with a
reasonable chance of success. So it doesn't matter whether you contrive
a handier definition of the term; ISO will trump your ace.

2) We live in an era where large companies tell large compiler vendors
where to get off. A standards committee can remove a feature, and some
vendors might even go along; but I promise you that all the serious
vendors will keep *all* past language features for many years to come.
So deprecation, and even removal, is largely an academic gesture these
days, at least for any language standard that retains any commercial
importance.

Discuss away.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nobody wrote:
 >
 > Herb Sutter wrote:
 > > On 5 Sep 2002 16:27:14 GMT, alf_p_steinbach@yahoo.no.invalid (Alf P.
 > > Steinbach) wrote:
 > > >Let's deprecate everything in the standard library except the STL.
 > >
 > > That's possible flamebait, but I'll bite. Before we can really discuss your
 > > suggestion, we need more information to understand it. Please:
 > >
 > > 1. Define what "deprecated" means to you. (Caution: This is nontrivial.)
 > > (Hint: See http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223.)
 >
 > I think it would be useful to discuss this item independently of
 > the "immodest proposal" that motivated Mr. Sutter to bring it up.
 > Let me begin by quoting the initial paragraph of core language
 > issue #223 (that's what the URL cited above points to):
 >
 >    During the discussion of issues 167 and 174, it became apparent that
 >    there was no consensus on the meaning of deprecation. Some thought
 >    that deprecating a feature reflected an intent to remove it from the
 >    language. Others viewed it more as an encouragement to programmers not
 >    to use certain constructs, even though they might be supported in
 >    perpetuity.

The standard is not the appropriate place for advice as to good and bad
programming practices. It is a contract, specifying what well-formed
code and a conforming implementation must do in order to produce the
desired effect of the code. It is not intended to distinguish
high-quality implementations from poor-quality ones, but only conforming
implementations from non-conforming ones. It isn't intended to
distinguish well-written code from poorly written code, but only to
distinguish well-formed code from ill-formed code.

It would therefore be inappropriate for the standard to use the word
"deprecated" with the second meaning you describe. As defined in the
current standard, the word "deprecated" is a warning that the specified
feature might not be supported by a future version of the standard, and
that's something that very definitely does lie within the scope of the
standard.

 > Therefore, I would like to see the wording of D/2 changed from
 >
 > 2    These are deprecated features, where deprecated is defined
 >      as:  Normative for the current edition of the Standard, but
 >      not guaranteed to be part of the Standard in future revisions.
 >
 > to something along the lines of
 >
 > 2    These are deprecated features, which means that they are
 >      normative requirements of the Standard but that alternative
 >      mechanisms exist which should be used when possible.

If the official definition were changed in the manner you propose, then
I would strongly recommend that all uses of the word "deprecated" by the
current standard be replaced with something else. A word with that
definition has no legitimate use within the purposes of the standard.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." wrote:
> nobody wrote:
> >
> > Herb Sutter wrote:
[ ... ]
> > > 1. Define what "deprecated" means to you. (Caution: This is nontrivial.)
> > > (Hint: See http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223.)
> >
> > I think it would be useful to discuss this item independently of
> > the "immodest proposal" that motivated Mr. Sutter to bring it up.
> > Let me begin by quoting the initial paragraph of core language
> > issue #223 (that's what the URL cited above points to):
> >
> >    During the discussion of issues 167 and 174, it became apparent that
> >    there was no consensus on the meaning of deprecation. Some thought
> >    that deprecating a feature reflected an intent to remove it from the
> >    language. Others viewed it more as an encouragement to programmers not
> >    to use certain constructs, even though they might be supported in
> >    perpetuity.
>
> The standard is not the appropriate place for advice as to good and bad
> programming practices. It is a contract, specifying what well-formed
> code and a conforming implementation must do in order to produce the
> desired effect of the code. It is not intended to distinguish
> high-quality implementations from poor-quality ones, but only conforming
> implementations from non-conforming ones. It isn't intended to
> distinguish well-written code from poorly written code, but only to
> distinguish well-formed code from ill-formed code.
>
> It would therefore be inappropriate for the standard to use the word
> "deprecated" with the second meaning you describe.

That's an interesting point of view, but it is not consistent with
the actual content of the standard.  Consider, for instance, the
following passages:

7.3.1.1/2
The use of the static keyword is deprecated when declaring objects
in a namespace scope (see annex D);  the unnamed-namespace provides
a superior alternative.

7.3.3/16
[Note: use of access-declarations (11.3) is deprecated;  member
using-declarations provide a better alternative. ]

11.3/1 (footnote)
100) Access declarations are deprecated;  member using-declarations
(7.3.3) provide a better means of doing the same things.  In earlier
versions of the C++ language, access declarations were more limited;
they were generalized and made equivalent to using-declarations
in the interest of simplicity.  Programmers are encouraged to use
using-declarations, rather than the new capabilities of access
declarations, in new code.

Value judgements are being expressed by the words "superior
alternative", "better alternative", and "better means of doing
the same things."  This is non-normative text, to be sure, but
there is nothing wrong with it being in a standard.  (Lots of
standards do stuff like this, BTW.)

[ These passages should also address Attila Feher's remark on the
necessity to provide some rationale for people not to use
deprecated features. ]

> As defined in the
> current standard, the word "deprecated" is a warning that the specified
> feature might not be supported by a future version of the standard, and
> that's something that very definitely does lie within the scope of the
> standard.

But that's silly, because NO feature, deprecated or not, is guaranteed
to be supported by a future version of the standard.  The words that
follow the phrase "Normative for the current edition of the Standard"

> > 2    These are deprecated features, where deprecated is defined
> >      as:  Normative for the current edition of the Standard, but
> >      not guaranteed to be part of the Standard in future revisions.

in the passage above don't really do anything more than to express a
value judgement about the deprecated features, to wit:  that in the
opinion of the committee responsible for this edition of the standard,
these features deserve to be phased out in a future edition of standard.

> > 2    These are deprecated features, which means that they are
> >      normative requirements of the Standard but that alternative
> >      mechanisms exist which should be used when possible.
>
> If the official definition were changed in the manner you propose, then
> I would strongly recommend that all uses of the word "deprecated" by the
> current standard be replaced with something else. A word with that
> definition has no legitimate use within the purposes of the standard.

Do you also think that "value judgement" parts of the passages I quoted
above have no place in the standard?

I think I am beginning to see why #223 is still open.

nobody


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <alr3fs$5i2$1@localhost.localdomain>,
nobody  <clcppm-poster@this.is.invalid> wrote:
>
>"James Russell Kuyper Jr." wrote:
>> The standard is not the appropriate place for advice as to good and bad
>> programming practices. It is a contract, specifying what well-formed
>> code and a conforming implementation must do in order to produce the
>> desired effect of the code. It is not intended to distinguish
>> high-quality implementations from poor-quality ones, but only conforming
>> implementations from non-conforming ones. It isn't intended to
>> distinguish well-written code from poorly written code, but only to
>> distinguish well-formed code from ill-formed code.
>>
>> It would therefore be inappropriate for the standard to use the word
>> "deprecated" with the second meaning you describe.
>
>That's an interesting point of view, but it is not consistent with
>the actual content of the standard.  Consider, for instance, the
>following passages:
....
>Value judgements are being expressed by the words "superior
>alternative", "better alternative", and "better means of doing
>the same things."  This is non-normative text, to be sure, but
>there is nothing wrong with it being in a standard.  (Lots of
>standards do stuff like this, BTW.)

Those words explain *why* the committee is deprecating the features,
i.e. why the features that they supplant are worthy of being removed in the
future.

A standard is inherently a big value judgement: C++ exists because some
programmers think it's a better alternative to C.

>
>[ These passages should also address Attila Feher's remark on the
>necessity to provide some rationale for people not to use
>deprecated features. ]
>
>> As defined in the
>> current standard, the word "deprecated" is a warning that the specified
>> feature might not be supported by a future version of the standard, and
>> that's something that very definitely does lie within the scope of the
>> standard.
>
>But that's silly, because NO feature, deprecated or not, is guaranteed
>to be supported by a future version of the standard.  The words that
>follow the phrase "Normative for the current edition of the Standard"

There's a general expectation that future revisions will not have major,
gratuitous incompatibilities, and that commonly-used features are not
likely to be removed.  Deprecation is a warning that a particular feature
is more likely to be removed.  The committee would have liked to remove it
in this round of standardization, but left it in to give users fair
warning.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nobody wrote:
[SNIP]
 > Therefore, I would like to see the wording of D/2 changed from
 >
 > 2    These are deprecated features, where deprecated is defined
 >      as:  Normative for the current edition of the Standard, but
 >      not guaranteed to be part of the Standard in future revisions.
 >
 > to something along the lines of
 >
 > 2    These are deprecated features, which means that they are
 >      normative requirements of the Standard but that alternative
 >      mechanisms exist which should be used when possible.

Won't this immediately bring up the question of: why should we use
alternative mechanisms?  And the answer I guess should be in that
paragraph.  Otherwise people just won't stop using them - they are
familiar with the old ways - and won't really "get it" why should they
stop.

Attila



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nobody wrote:
....
> the actual content of the standard.  Consider, for instance, the
> following passages:

[many passages cited where features were identified as deprecated, and a
reason was given for the deprecation]

> Value judgements are being expressed by the words "superior
> alternative", "better alternative", and "better means of doing
> the same things."  This is non-normative text, to be sure, but
....
> But that's silly, because NO feature, deprecated or not, is guaranteed
> to be supported by a future version of the standard.  The words that

That's the key point of issue 223. I thing that the issue should be
resolved by defining deprecated as meaning that the specified features
have an unusually high probability of being dropped from the standard in
the near future.

I'd prefer it to say that "deprecated" means "will definitely be dropped
from the next version of the standard". However, it's generally not
possible to be that precise, when scheduling changes to the standard.
With that meaning, it would never be used.

....
> Do you also think that "value judgement" parts of the passages I quoted
> above have no place in the standard?

No - I consider those value judgements to be the explanations of why the
item is deprecated. That is, they explain why it might be dropped from a
future version of the standard.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D829DE9.54625F20@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>I'd prefer it to say that "deprecated" means "will definitely be dropped
>from the next version of the standard". However, it's generally not
>possible to be that precise, when scheduling changes to the standard.
>With that meaning, it would never be used.

I do not think I would go quite that far but I would like to see
'deprecated' mean that retention in future releases would depend on more
than just the normal requirement for protecting legacy code. I.e. being
currently in the Standard will not be sufficient justification for it
continuing to be in it, so those that want it retained need to come up
with positive arguments for doing so.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Herb Sutter wrote:
> On 5 Sep 2002 16:27:14 GMT, alf_p_steinbach@yahoo.no.invalid (Alf P.
> Steinbach) wrote:
> >Let's deprecate everything in the standard library except the STL.
>
> That's possible flamebait, but I'll bite. Before we can really discuss your
> suggestion, we need more information to understand it. Please:
>
> 1. Define what "deprecated" means to you. (Caution: This is nontrivial.)
> (Hint: See http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223.)

I think it would be useful to discuss this item independently of
the "immodest proposal" that motivated Mr. Sutter to bring it up.
Let me begin by quoting the initial paragraph of core language
issue #223 (that's what the URL cited above points to):

   During the discussion of issues 167 and 174, it became apparent that
   there was no consensus on the meaning of deprecation. Some thought
   that deprecating a feature reflected an intent to remove it from the
   language. Others viewed it more as an encouragement to programmers not
   to use certain constructs, even though they might be supported in
   perpetuity.

The deprecated features (and, indeed, the current definition of the
word "deprecated") are to be found in Annex D of the standard, which
is entitled "Compatibility Features".  Many of those compatibility
features HAVE to be there in order to ensure that there is a useful
common subset of C and C++.  I don't want to see that subset go away,
so I don't want the deprecated features removed from the standard.  On
the other hand, most of the deprecated features should not be used
in new programs that are targeted for a pure C++ environment.  So I
subscribe to the second view described in the paragraph above.

Therefore, I would like to see the wording of D/2 changed from

2    These are deprecated features, where deprecated is defined
     as:  Normative for the current edition of the Standard, but
     not guaranteed to be part of the Standard in future revisions.

to something along the lines of

2    These are deprecated features, which means that they are
     normative requirements of the Standard but that alternative
     mechanisms exist which should be used when possible.

If this or some equivalent suggestion is accepted, then I would
have no problem accepting # 167 (that would change the language
of the standard to deprecate static functions as well as static
objects).  If, on the other hand, it is decided that deprecation
of a feature indicates an intent to remove it from the standard,
then not only should # 174 be accepted (to undeprecate static
objects), but also many other C compatibility features should be
undeprecated as well.

nobody


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]