Pete Becker wrote in message <3C25251D.66B36600@acm.org>...

>The first rule of library redesign: you cannot remove or modify the
>behavior of existing interfaces.

Just checking that the thoughts for C++0x include something to mimic the
Java @deprecated keyword to warn
users of the presence of new, hopefully better, interfaces.

Roger Orr
--
MVP in C++ at www.brainbench.com


---
[ 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                ]

Hi,
Roger Orr wrote:

> Just checking that the thoughts for C++0x include something to mimic the
> Java @deprecated keyword to warn
> users of the presence of new, hopefully better, interfaces.


Since ages I'm arguing for a feature to create warning and error
messages while compiling code. Currently, I'm using unused objects to
warn about deprecated features, eg. something like

   struct this__feature__is__deprecated {} use__that__feature__instead;

I would prefer to have a nicer way to provide the same information. Of
course, using a post processor for the compiler output could format the
above warning into a neat warning message for the user :-)
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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                ]

"Roger Orr" <rogero@howzatt.demon.co.uk> wrote in message news:1009577061.27025.0.nnrp-14.9e98aa01@news.demon.co.uk...

> Pete Becker wrote in message <3C25251D.66B36600@acm.org>...
>
> >The first rule of library redesign: you cannot remove or modify the
> >behavior of existing interfaces.
>
> Just checking that the thoughts for C++0x include something to mimic the
> Java @deprecated keyword to warn
> users of the presence of new, hopefully better, interfaces.

Various people have sketched various ways to depart from backward
compatibility. And ``deprecation'' is a term of art in programming
language standards. But none of that alters the fact that backward
compatibility is tremendously important in the real world. A single-
vendor language like Java can sometimes ride roughshod over the needs
of developers, at a cost (to the language) that is not always apparent.
If an ISO standard does not pay adequate attention to backward
compatibility, however, it risks simply being ignored.

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



---
[ 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                ]

Roger Orr wrote:
>
> Pete Becker wrote in message <3C25251D.66B36600@acm.org>...
>
> >The first rule of library redesign: you cannot remove or modify the
> >behavior of existing interfaces.
>
> Just checking that the thoughts for C++0x include something to mimic the
> Java @deprecated keyword to warn
> users of the presence of new, hopefully better, interfaces.
>

@deprecated doesn't tell you that there's something better, just that
what you relied on shouldn't be used any more (e.g.
java.lang.Thread.suspend, because it's "inherently unsafe"). And Java
also needs @undeprecated to cover things like the constructors for
java.io.PrintStream, which were deprecated in jdk 1.1.5 and undeprecated
in 2.0.

Even better, though, is to not take things away. That way you don't need
magic keywords for the benefit of people who don't read documentation.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                ]

Being made aware of this newsgroup, and its purpose, I thought I put out
this post with some thoughts on the currently-debated C++0x standard. I hope
that it does create some discussion and that it might help in adding
something positive.

On the issue of what to do (add/subtract/modify) in the std:: library -
since it is difficult to make modifications without trampling on lots of
toes, maybe the new library should be in the std01 name space. What is good
in std:: can be taken into std01 (with modifications if that is desired).
Even for newbies it would be pretty clear that std01 may not be entirely
compatible with std

One particularly frustrating thing with algorithms is the fact that I find
myself often writing predicate functions or predicate function classes. They
are usually a few lines of code, but they have two disadvantages: 1. They
clutter the namespace, and 2. They must be declared outside of the function
in which they are used (thus braking the train of thought during coding).
These issues could be overcome by allowing nested functions, and by allowing
class definitions within functions. The scope of those would be only within
the brackets in which they are defined. I realize the potential for mis-use
of such a feature, but then again - what can't be mis-used?

On the notion of inheritance, I think it would sometimes be very helpful to
allow "incremental" subclassing during construction. The thought goes along
the following lines: Suppose I have a class B, which is a sub-class of A.
Currently A must be constructable (and therefore completely known to B) when
B is constructed. This prevents different implementations of A and a choice
at time of construction as to which A to subclass from. In theory I think
that there should be nothing that makes this impossible. In practice it may
have more ramifications than I see. However, apart from interrogating A for
the amount of storage it requires (and A could ask its subclasses the same,
returning the accumulated amount), so that the right amount for the
composite class can be allocated, pretty much everything else would stay as
it is now. This feature would make distribution of different implementation
of binaries with the same header possible. Currently it is not.


---
[ 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                ]

"Walter J. Mack" wrote:
>
> Being made aware of this newsgroup, and its purpose, I thought I put out
> this post with some thoughts on the currently-debated C++0x standard. I hope
> that it does create some discussion and that it might help in adding
> something positive.
>
> On the issue of what to do (add/subtract/modify) in the std:: library -

The first rule of library redesign: you cannot remove or modify the
behavior of existing interfaces.

> since it is difficult to make modifications without trampling on lots of
> toes, maybe the new library should be in the std01 name space. What is good
> in std:: can be taken into std01 (with modifications if that is desired).
> Even for newbies it would be pretty clear that std01 may not be entirely
> compatible with std

Yup. Just like it's clear to everyone that iostream.h is different from
iostream, which is why there are so many questions on the C++ newsgroups
asking why iostream.h doesn't do what the standard says. But usability
issues aside, that would effectively double the size of the standard
library and the cost of testing a library implementation, mostly for no
gain. What compelling changes do you see that would require imposing
this burden on implementors and on users? As it stands now, this is a
proposal for a solution to a problem that hasn't arisen. Let's not solve
it until it comes up. There's a very good chance that it won't.

> On the notion of inheritance, I think it would sometimes be very helpful to
> allow "incremental" subclassing during construction. The thought goes along
> the following lines: Suppose I have a class B, which is a sub-class of A.
> Currently A must be constructable (and therefore completely known to B) when
> B is constructed. This prevents different implementations of A and a choice
> at time of construction as to which A to subclass from. In theory I think
> that there should be nothing that makes this impossible. In practice it may
> have more ramifications than I see. However, apart from interrogating A for
> the amount of storage it requires (and A could ask its subclasses the same,
> returning the accumulated amount), so that the right amount for the
> composite class can be allocated, pretty much everything else would stay as
> it is now. This feature would make distribution of different implementation
> of binaries with the same header possible. Currently it is not.
>

With a combination of class factories, delegation, and abstract classes
you can do that today. No langauge changes needed, so no added
complications for compilers, and no semantic limitations for users -- if
you don't like the way you did it, just rewrite it.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                ]

"Walter J. Mack" <wmack@componentsw.com> wrote in message news:<8S8V7.81120$Wd.23772090@news1.rdc1.az.home.com>...
> Being made aware of this newsgroup, and its purpose, I thought I put out
> this post with some thoughts on the currently-debated C++0x standard.

I have seen much discussion about C++0x but have not seen any official
documents. Does anyone have a URL for the C++0x standard please ?

-Andrew M.

---
[ 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                ]

In article <d1a33011.0112240031.2096b84e@posting.google.com>, apm
<apm35@student.open.ac.uk> writes
>I have seen much discussion about C++0x but have not seen any official
>documents. Does anyone have a URL for the C++0x standard please ?


Please supply me with details of your time machine. We haven't got any
further than thinking about what we might do.


--
Francis Glassborow
The Seasons best wishes to you and yours. May 2002 be better for all of us than
2001 was for some.

---
[ 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                ]