In article <COATES.95Jul11174927@kelvin.physics.uq.oz.au>,
Tony Coates <coates@kelvin.physics.uq.oz.au> wrote:
>While reading Bertrand Mayer's book on writing reusable software, I
>noted that his `Eiffel' language allows functions to be marked as
>`obsolete',

 In theory, you can "simulate" some of this functionality
using namespaces:

 namespace MAXTAL_VERSION_1_00 {
  void f(); void g();  void oldHat();
 }

 namespace MAXTAL_VERSION_1_02 {
  void f(); void g();
 }

 using namespace MAXTAL_VERSION_1_02;

 void user() {
  MAXTAL_VERSION_1_00::oldHat();
   // call obsolete function
  f();  // call new version!
  MAXTAL_VERSION_1_00::g();
   // depend on quirk of old version
 }

Using this style it is clear you are using the latest version
of everything except where boldly noted. :-)

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3tvb8u$g0o@usenet.pa.dec.com> diamond@jrd.dec.com (Norman Diamond) writes:
 >
 > In article <COATES.95Jul11174927@kelvin.physics.uq.oz.au> coates@kelvin.physics.uq.oz.au (Tony Coates) writes:
 >  >I noted that his `Eiffel' language allows functions to be marked as
 >  >`obsolete', so that during a transitional period as the names of
 >  >library functions are changed, users are able to use the old function
 >  >names but will be warned by the compiler.
 >
 >  It's not a good idea to announce this kind of pedigree for an idea if
 >  you want to persuade C lovers to adopt it.  You might try arguing that
 >  the spirit of C used to allow the language to change with warnings being
 >  issued about obsolete syntax, and this is just an extension of that idea.

Even better, you can refer to an existing implementation.
In NetBSD's C library you find code like this:

__warn_references(gets, "warning: this program uses gets(), which is unsafe.");

char *
gets(buf)
        char *buf;
{
[...]

__warn_references is a macro.
On platforms with appropriate support in compiler/assembler/linker
__warn_references ensures that any program that references gets()
will get a link-time warning.  Otherwise it's just empty.

Since you can use this method yourself, I don't think a new keyword
is really neccessary.  As a user you could even use 'obsolete'.
Therefore, I don't know if I would support it for the Ansi C standard.

 - Arne H. J.

While reading Bertrand Mayer's book on writing reusable software, I
noted that his `Eiffel' language allows functions to be marked as
`obsolete', so that during a transitional period as the names of
library functions are changed, users are able to use the old function
names but will be warned by the compiler.  It seems to me that this is
entirely reasonable, and might be considered a normal part of the
evolution of a software library.  I would like to be able to generate
a similar warning using C/C++, but I can't see that this is possible
without the addition of either an `obsolete' modifier (similar to
`auto' or `volatile') for functions/classes/variables/etc., or the
addition of a `#pragma obsolete'.  The modifier version is probably to
be preferred for users, since it would be directly placed at the point
of definition of the function; a pragma would have to be able to be
placed anywhere, presumably, and would require the function name (and
parameters for C++) to be repeated in the pragma body.
 Neither option would change the compiled code, so changes to
compilers to support this idea would be minimal and no significant
overheads would be involved.  However, I do feel that library
maintenance would be enhanced by being able to generate warnings about
obsolete functions.
 Does this idea strike anyone else as worthwhile, or is there
some way I can use what is already available to achieve the same end?
It seems to me reasonably minimal in what it requires.
 Any comments/criticisms would be gratefully welcomed.
      Cheers,
        Tony.
--
_____________________________________________________________________________
A.B.Coates, Dept. of Physics,
The University of Queensland  QLD  4072  Australia.
Email: coates@physics.uq.oz.au
Phone: (07/+617) 365-3424  Fax: (07/+617) 365-1242
Disclaimer: The University is ignorant of my
            opinions, let alone guilty ...
_____________________________________________________________________________

In article <COATES.95Jul11174927@kelvin.physics.uq.oz.au> coates@kelvin.physics.uq.oz.au (Tony Coates) writes:
>I noted that his `Eiffel' language allows functions to be marked as
>`obsolete', so that during a transitional period as the names of
>library functions are changed, users are able to use the old function
>names but will be warned by the compiler.

It's not a good idea to announce this kind of pedigree for an idea if
you want to persuade C lovers to adopt it.  You might try arguing that
the spirit of C used to allow the language to change with warnings being
issued about obsolete syntax, and this is just an extension of that idea.

>I would like to be able to generate a similar warning using C/C++, but
>I can't see that this is possible without the addition of either an
>`obsolete' modifier (similar to `auto' or `volatile') for functions/
>classes/variables/etc., or the addition of a `#pragma obsolete'.

Functions can already be declared with storage class extern or static
though of course not auto or register, so "obsolete" would not be similar
to auto.  It would be roughly similar to volatile though of course volatile
and const (in C) only apply to objects.  The problem now is that adding
another keyword to the language is a very weighty step, and most users
would object unless the new feature is exceptionally important and cannot
be implemented any other way, such as bool [sarcasm in those last 3 words].

"#pragma obsolete" is surely the way to go for this one.

Furthermore, the standard already permits implementations to recognize
any kind of #pragma they like and respond however they like.  (They even
legitimized gcc's invocation of rogue after gcc quit doing that.)  And
furthermore, even a conservative implementor who would not let #pragma
change the meaning of any strictly conforming program is still free to
issue spurious warnings for any purpose whatsoever, including on command
from a #pragma.  So, you should be happy to add this to your implementation.

>Does this idea strike anyone else as worthwhile,

Yes, I'm sure some of Mr. Meyer's customers use it, and there were
occasions at a previous employer using another language where I would have
used it if it were available and if the employer permitted.

>is there some way I can use what is already available to achieve the same end?

Yes, your written documentation can tell programmers not to use it, and
your obsolete functions can output messages to stderr before invoking new
functions that do the work.

The last two questions are not standards issues, by the way.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer