> Bret Pehrson wrote:
>>
>> Since C++ is (and always will be) a growing language, and since that
>> growth causes the deprication of various elements, how about some help
>> from the language in the form of a deprication notification, something
>> of the form of:
>>
>> #depricate identifier
>>
>> which would issue a compiler diagnostic along the lines of:
>>
>> warning:  'identifier' is marked as depricated.

Marcelo Cantos writes:

>   #define identifier !@$%

> Your compiler will then flag all the occurring instances as errors.
> An easier approach is to use grep.

I guess the intent of the poster is similar to the @deprecate comment
in Java.  the compiler should issue just a warning message, so that
code will still compile, but the user will be warned that this feature
may not be available in future releases of the compiler/language.

It should actually be a declaration or a pragma, visible by the
compiler, not only by the preprocessor, so that scope and overloading
can be addressed.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Marcelo Cantos <marcelo@mds.rmit.edu.au> writes:

>I assume the purpose of #deprecate is
>to get the compiler to tell the programmer where all the instances
>of this keyword are located.  This could easily be addressed by going:
>
>  #define identifier !@$%
>
>Your compiler will then flag all the occurring instances as errors.

No, you misunderstand the purpose.  The aim is to flag all uses of the
entity _without_ breaking the code.  As a library vendor, breaking your
users' code will make you unpopular.  It's much better to use a warning
to encourage them to change their code than to just come out and break
it.

>An easier approach is to use grep.

No, that's not going to help at all.  There's no way that a library
implementor can `grep' all their client's code.

Anyway, both `grep' and the proposed `#deprecate' have the wrong
granularity; you want to deprecate particular member functions,
for example, not identifiers.

>In reality I don't think many identifiers are deprecated and the
>compiler vendors usually issue warnings of this nature anyway.

Yes, compiler vendors do this sort of thing often.  The point of this
extension would be to give library implementors the power to do the same.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,
Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote:
: Yes, compiler vendors do this sort of thing often.  The point of this
: extension would be to give library implementors the power to do the same.

But I don't really see, why this should be limited to deprecated
features (although this would be a start...):  I think, if something
like this is supposed to go into the language it should be a general
mechanism which may issue a warning. For example, I would like it if it
were possible to add extensions to the standard library, eg. the file
descriptor members to the IOStream library on UNIXes, and issue a
warning if the compiler is invoked with the correct options: Enabling
such warning would be reasonable for software which is supposed to be
portable while other software can just use these system specific
extensions. Then, the same mechanism can be used for deprecated
features, extensions, and so on.

Here is an example of what I think is a reasonable situation:

  class ostrstream warn(true, "use of 'ostrstream' is deprecated'")
  {
    // ...
  };

  class ofstream
  {
    // ...

    void attach(int fd) warn(STD_ONLY == 1, "'attach()' is a non-standard member");
  };

Of course, the messages could be improved but this is not the point.
The point is that this would yield a possibility to issue different
kinds of warnings depending on how some constant expressions evaluate:
If the first argument of 'warn', which has to be a constant expression,
yields 'true' the second argument is issued as messages if the
corresponding symbol is used. In the first case, the message that
'ostrstream' is deprecated is issued if this class is used. In the
second case, it is warned about 'attach()' being non-standard if
'STD_ONLY' evaluates to '1' and the attach member is used for an
'ofstream'.

I can imagine another bunch of potential warning which would make life
easier for library vendors and large developments. For example:

- Warn that a certain function/class is not yet completely implemented
  (of course, this should never be the case in a distributed library
  but may be reasonable during development)
- Warn about dependencies e.g. for objects with static linkage
- Warn about the use of a function which has a superior equivalent
  (e.g. use of 'qsort()' instead of 'sort()')

Although I think that issuing warnings about deprecated features of
standard components is a reasonable thing, I think that if something in
this direction is added to the standard, it should be more general. In
fact, a standard conforming C++ compiler is free to issue warnings
about use of deprecated features of the library anyway (since it may
issue whatever diagnostic it want as long as it compiles standard
conformant code and issues the required diagnostics) and there would be
no need to add anything to the standard.
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bret Pehrson <bretp@strata3d.com> wrote:

>Since C++ is (and always will be) a growing language, and since that
>growth causes the deprication of various elements, how about some help
>from the language in the form of a deprication notification, something
>of the form of:
>
>  #depricate identifier
>
>which would issue a compiler diagnostic along the lines of:
>
>  warning:  'identifier' is marked as depricated.
>
>The evaluation of identifier would happen during the pre-processing
>phase, after all macro substitution(s) have been performed.
>
>Does this sound useful, or is there a currently-supported way or method
>to do this type of thing.

I think this would be a job for the compiler vendor, which they can do
with a pragma.  In fact, Borland C++ has a under-documented #pragma
obsolete for that very purpose.

rm


---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

>Although I think that issuing warnings about deprecated features of
>standard components is a reasonable thing, I think that if something in
>this direction is added to the standard, it should be more general.

I agree that something more general would be nicer, but there are
drawbacks; it might be slightly more difficult to implement, and it would
be a bit more costly in terms of compilation time and memory
consumption.  A `pragma obsolete' or equivalent needs only a single bit
flag in each symbol table entry, and most compilers already have a set
of such flags, so adding one more is easy, whereas a more general
mechanism would probably require a whole word.

>In fact, a standard conforming C++ compiler is free to issue warnings
>about use of deprecated features of the library anyway (since it may
>issue whatever diagnostic it want as long as it compiles standard
>conformant code and issues the required diagnostics) and there would be
>no need to add anything to the standard.

A compiler can only issue warnings about use of deprecated features in
the standard library; it can't usefully warn about deprecated features
in third-party libraries, unless the third-party libraries use an
extension such as `pragma obsolete', because otherwise there's no way
for the compiler to know which features the third-party developer
has deprecated.

If all the compiler vendors end up implementing `pragma obsolete'
or something like that so that they can issue warnings for deprecated
features of the standard library, then it would make sense to provide
a standard way for library developers to have access to that functionality.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Since C++ is (and always will be) a growing language, and since that
growth causes the deprication of various elements, how about some help
from the language in the form of a deprication notification, something
of the form of:

  #depricate identifier

which would issue a compiler diagnostic along the lines of:

  warning:  'identifier' is marked as depricated.

The evaluation of identifier would happen during the pre-processing
phase, after all macro substitution(s) have been performed.

Does this sound useful, or is there a currently-supported way or method
to do this type of thing.

The reason that I bring this up, is because after a project gets to a
certain size, the change-everything-at-once becomes a real chore.  I
think that if a deprication mechanism were introduced, it would allow
for easier and more predictable project maintenance.

Any takers???

--
Bret Pehrson        mailto:BretP@strata3d.com
*Please post all questions to newsgroup
*Please carbon-copy all responses to newsgroup
--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bret Pehrson <bretp@strata3d.com> suggested:
> Since C++ is (and always will be) a growing language, and since that
> growth causes the deprication of various elements, how about some help
> from the language in the form of a deprication notification, something
> of the form of:
>
>   #depricate identifier
>
> which would issue a compiler diagnostic along the lines of:
>
>   warning:  'identifier' is marked as depricated.

It's spelled "deprecate".  An alternate spelling could be "obsolete".
("Deprecate" means that you pray strongly that a thing would go away, while
"obsolete" means that it really is no longer useful.)

It would be similar to the 'obsolete' keyword in Eiffel, which is used to
flag a class member as obsolete (no longer supported).  The compiler
issues a warning/error if a client of the class attempts to access an
obsolete member.

> The evaluation of identifier would happen during the pre-processing
> phase, after all macro substitution(s) have been performed.

No, this would be not be a good idea.  What if class Foo and class Bar both
have a member named baz, but you only want class Foo's baz to be obsoleted?
Having this logic done in the preprocessing phase entails problems similar
to those using #define, since the preprocessor doesn't recognize class-scope
namespaces.

> Does this sound useful, or is there a currently-supported way or method
> to do this type of thing.

Not that I know of, but I verify class and client compatibility using the
preprocessor.  Each class header defines a 'version' macro:

    // class.h

    #define Foo_VERS  213   // Class version 2.13

    class Foo
    {
    ...
    };

The client code can then verify that it's using the right (expected) version
of the class, otherwise it causes a compiler error to be issued:

    // client.c

    #include "class.h"

    #if Foo_VERS/100 != 2   // Expected class version 2.xx
    #error Wrong version of class "Foo"
    #endif

    ...

File client.c will get a compile-time error if it needs to be updated for
a new version of class Foo.

The 'Foo_VERS' macro is incremented by 100 whenever a major change is made
to class Foo that would impact client code.  Incrementing by 1 indicates a
minor change that does not require recompilation of the client code.
(This is one use of the preprocessor that you can't replace with straight
C++.  Sorry, Bjarne.)

-- David R. Tribble, david.tribble@central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> "BP" == Bret Pehrson <bretp@strata3d.com> writes:

 BP>   #depricate identifier

 BP> which would issue a compiler diagnostic along the lines of:

 BP>   warning:  'identifier' is marked as depricated.

Sounds like a pretty useful feature for programming in the large.  But we'd
probably want to go with the more standard spelling of `deprecate' :-) and I
would think a non-preprocessor-ish syntax would be more useful:

  class Foo
  {
   public: Foo(Bar&) __deprecated;  // don't use this constructor in new code
   // ...
--
 Michael Cook <mcook@cognex.com>        <http://ftp.cognex.com/~mcook/>
 Telephone: +1 508 650 3251                        Fax: +1 508 650 3336
 Cognex Corporation, One Vision Drive, Natick, Massachusetts 01760-2059
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bret Pehrson wrote:
>
> Since C++ is (and always will be) a growing language, and since that
> growth causes the deprication of various elements, how about some help
> from the language in the form of a deprication notification, something
> of the form of:
>
>   #depricate identifier
>
> which would issue a compiler diagnostic along the lines of:
>
>   warning:  'identifier' is marked as depricated.

Deprecate, not depricate.  I assume the purpose of #deprecate is
to get the compiler to tell the programmer where all the instances
of this keyword are located. This could easily be addressed by going:

  #define identifier !@$%

Your compiler will then flag all the occurring instances as errors.
An easier approach is to use grep.

In reality I don't think many identifiers are deprecated and the
compiler vendors usually issue warnings of this nature anyway.


--
___________________________________________________________________
Marcelo Cantos, Research Assistant          marcelo@mds.rmit.edu.au
Multimedia Database Systems Group    __/_      _ Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
                                     /
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bret Pehrson <bretp@strata3d.com> writes:

>Since C++ is (and always will be) a growing language, and since that
>growth causes the deprication of various elements, how about some help
>from the language in the form of a deprication notification, something
>of the form of:
>
>  #depricate identifier
>
>which would issue a compiler diagnostic along the lines of:
>
>  warning:  'identifier' is marked as depricated.
>
>The evaluation of identifier would happen during the pre-processing
>phase, after all macro substitution(s) have been performed.
>
>Does this sound useful, or is there a currently-supported way or method
>to do this type of thing.

I think it sounds useful.  If you want prior art from another language,
the `pragma obsolete' declaration in the language Mercury is very similar.
Here's an extract from the Mercury language reference manual:

 | Obsolescence
 | ============
 |
 |    A declaration of the form
 |
 |      :- pragma obsolete(NAME/ARITY).
 |
 | declares that the predicate(s) or function(s) with name NAME and arity
 | ARITY are "obsolete": it instructs the compiler to issue a warning
 | whenever the named predicate(s) or function(s) are used.
 |
 |    `pragma obsolete' declarations are intended for use by library
 | developers, to allow gradual (rather than abrupt) evolution of library
 | interfaces.  If a library developer changes the interface of a library
 | predicate, they should leave the old version of that predicate in the
 | library, but mark it as obsolete using a `pragma obsolete' declaration,
 | and document how library users should modify their code to suit the new
 | interface.  The users of the library will then get a warning if they
 | use obsolete features, and can consult the library documentation to
 | determine how to fix their code.  Eventually, when the library
 | developer deems that users have had sufficient warning, they can remove
 | the old version entirely.

However, I'm not sure that the preprocessor is the right place to put
it in C++.  I think you often want a finer level of granularity than
`identifier'.  Often the sorts of changes you want to make are things
like adding a new parameter to a function.  In that case, you would
like to be able to keep the old prototype around for backwards
compatibility but mark it as obsolete or deprecated, but you want the
new prototype to have the same function name.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble <david.tribble@central.beasys.com> wrote in article
<2.2.32.19970221020545.002fcbd0@central.beasys.com>...
>
> The 'Foo_VERS' macro is incremented by 100 whenever a major change is made
> to class Foo that would impact client code.  Incrementing by 1 indicates a
> minor change that does not require recompilation of the client code.
> (This is one use of the preprocessor that you can't replace with straight
> C++.  Sorry, Bjarne.)

Maybe you could implement it using templates.  Some end-of-work
brainstorming has come up with this:

template <int MAJOR, int MINOR>
class Foo {
};

Each version could be implemented as an overloaded template class.
The first version of a class would be implemented as:

class Foo<1,0>
{
public:
 ... // Version 1.0 interface
};


A minor verion change would be implemented by changing the MINOR template
argument but publicly deriving from the previous version to allow
backwards computability:

class Foo<1,1> : public Foo<1,0>
{
public:
 ... // Version 1.1 interface

};

A major version change would be implemented by changing the MAJOR template
argument and not publically deriving from the previous version to cause
errors if Foo<2,0> objects are used where Foo<1,0> objects are required
and vice-versa:

class Foo<2,0>
{
public:
 ... // Version 2.0 interface
};

This is a bit of a silly idea and would perhaps only work if used
for versioning abstract interfaces (ie: classes which only provide
pure virtual member functions. Perhaps the use of the MINOR
template parameter is a bit limiting. However, I am constantly
amazed what one can implement using only C++ classes, even if
only as amusing hacks :-)

Cheers,
 Nat.
--
+-------------------------------------------+---------------------------------+
| Name:   Nat Pryce MEng ACGI            O- | Mail:  Department of Computing, |
| Email:  np2@doc.ic.ac.uk                  |        Imperial College,        |
| Tel:    +44 (0)171 594 8394 (Direct Dial) |        180 Queen's Gate,        |
| Fax:    +44 (0)171 581 8024               |        London SW7 2BZ,          |
| WWW:    http://www-dse.doc.ic.ac.uk/~np2  |        United Kingdom           |
+-------------------------------------------+---------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]