alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message news:<3d76d7b1.102449625@news.online.no>...
> Let's deprecate everything in the standard library except the STL.
>
> Cheers,
>
> - Alf

  I would assume that this is troll-fishing the newsgroups to see how
much turbulence can be kicked up, for turbulence's own sake, and to
see for how long the wake extends behind the boat so to speak (i.e.,
how long the thread lives on & on for weeks).

  Regarding the OP's proposed deprecation:
  If one does not like the television program, change the channel.  By
this I mean, if one would strongly prefer something to be absent from
the standard library on purely cosmetic grounds or purely
philosophical grounds, don't look at it.  Its presence does little
damage (unless via poor quality-of-implementation the compiler vendor
implemented the construct via #define).

  Now if something is actually broken, damaging, or horribly
misleading, that is a different matter.  For example, if a standard
library function by design encourages MT-unsafe code to be written,
then that does deserve investigation (and such cases rightfully have
received such attention over the past decade).

  The presumption of the OP is that oldy moldy C-language cruft should
be purged simply because it is presented in a non-OO,
non-generic-programming, non-latest-fashion personality.

  I hold an opinion which is nearly 100% opposite of the OP.  Instead
of deprecating personalities/styles-of-programming which are out
vogue, I would like to see the standard C++ libraries be
multiparadigm, just as the C++ language is multiparadigm.  The C++
community should not have a single paradigm of libraries forced upon
it.  Instead different portions of the C++ community choose to use the
language proper differently, according to that subcommunity's
preferred paradigm/style of programming.  Likewise, that subcommunity
should have standard libraries which embody that paradigm of
programming.
---
[ 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                       ]

Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<3d90859f$0$281$626a54ce@news.free.fr>...
> kanze@gabi-soft.de (James Kanze) writes:

> > In what sense?  Exceptions are not appropriate for "errors" which
> > must be handled immediately.

> Depend on what you mean by immediately.  I'd say instead "at the
> current level" because exceptions force the handling of the error to
> be done immediately.

Agreed.  Immediately is a poor word, since it suggests a temporal
element which wasn't present in my thoughts.

> Non exception IOStream error handling can be delayed far further that
> exception one.  It can even never be done.

Well, you don't have to catch an exception either.  But yes, the
difference is that you notice if you don't catch the exception, but not
if you ignore a return code or a sticky status (the classical iostream
approach).

> > > Working with streams and STL (e.g. using stream iterators) also
> > > proves that EOF is not an error and other streams errors are best
> > > handled using exceptions.

> > What other errors?  About the only other error istream detects is an
> > input format error -- hardly something exceptional, or that you
> > would want to raise an exception.

> I think we all agree that using IOStream formatted input when you want
> to do serious error handling is not a good choice.  So it remains the
> failures reported at the streambuf level.

> Such errors have to be handled also for output.  And here among these
> errors there is the "device full" error which can be quite important.

> For such kind of errors to be handled effectively, this should be done
> under the control of the programmer and at the streambuf level (so
> that continuing from another source to another destination is a
> possibility, or asking user advice on what to do).  If you want such
> handling, the only standard provided way is to write a custom
> streambuf which will forward all IO actions but trap reported errors.

> The code doing the IO is not a good place: it should be independant of
> the kind of IO done, and the error correction action is intrinsicly
> dependant on it.

> So the next level where they can be handled -- but less effectively --
> is the place where the streambuf are created.  And an exception is a
> good way to reach this place.  Ignoring all IO done after the error is
> another way, but it assume more on the rest of the program.

The real problem is that the error handling and reporting is streambuf's
is far from precise enough to do much of anything.  Basically, all a
streambuf can say is whether the request failed or succeeded.  The
iostream's interpret failure on write as "bad" and failure on read as
"eof".  This sort of works for local files, most of the time.  But when
reading from a socket, there is a definite difference between the
opposite side shutting down cleanly, and loosing the connection.

The problems are also different when writing than when reading.  You
mention disk full, for example.  On most systems today (or at least, on
the systems I use), writing to a full disk will NOT cause an error.  At
least not immediately.  There is absolutely no point in checking for the
error until I have finished writing.  This means either after an
explicit close or flush.  Whether the error can be handled immediately
in such cases depends on the application, of course; my experience is
that I've never had a case where propagating further would have been
appropriate for close, but flush is a bit less obvious.  (Most of my use
of flush has been with log files.  In such cases, I don't want the error
to propagate at all -- I can afford to lose the logs, but it certainly
shouldn't have any effect on the rest of the application.  If the logs
are critical, of course, they are being written in several places -- not
only files, but syslog, Tivoli or in the case of critical errors, email
to the administrator.  So I lose the one, but log the loss in the
others.)

The only normal case of "error" when reading (in a streambuf) on a
typical disk file is end of file.

The result is that 1) you never want an exception when reading, and 2)
you probably don't want an exception when writing, since it will come at
the wrong time anyway; either you flush explicitly after the write (and
handle the return code of flush), or (most of the time), you just ignore
errors until the end of processing, in which case, checking the return
status of the close is the ideal solution.

Logically, one would also like to be able to handle problems like
hardware disk errors, broken connections, and what all else.  But these
are NOT handled by the standard streambuf's, and the only thing the
existing reporting mechanism can distinguish is between "fail" and
"bad", and it never generates fail for output, nor bad for input.  (I
could very easily imagine exceptions as the preferred way of reporting a
bad disk sector when reading, but filebuf will report it as an end of
file.)  In this case, you really only have two solutions:
  - Memorize the error in the (custom) streambuf, and check for it
    later, or
  - Raise an exception.
In the first case, depending on the gravity, you may want to also cause
input or output to fail (so that the attached iostream's will do
something sensible).

The choice of which strategy to use largely depends on the role of the
IO in the application.  As I said, with log's, I just log the error on
the other log devices, and continue.  With a server connection, I
normally have to roll back whatever the client has done before.  There
is no one good solution for everybody; in such cases, I like the
solution of a callback, so the user can decide for himself.  If the
application has been designed with roll-back implemented by means of
RAII classes, the exception can be a good solution for the case where
roll-back is wanted.  At any rate, I can well conceive of an application
specific streambuf which throws an exception on specific types of
errors.  (But does anyone really use streambuf's for this sort of work?
A TCP connection is bidirectionally interactive, and in most cases, is
not really used as a stream.  And most application level protocols are
record oriented, which doesn't fit the streambuf model at all.)

Depending on the type of device, it may also be possible to
transparently reconnect; in such cases, you probably want to log the
error, or perhaps treat it later, but you certainly don't want to raise
an exception (which is anything but transparent).

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

"Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
news:<3d8ad532@news.microsoft.com>...
> "Ken Alverson" <Ken@Alverson.net> wrote in message
> news:amd0fq$k6v$1@eeyore.INS.cwru.edu...
>  > "Rob" <nospam@does.not.exist> wrote in message
>  > news:ambio7$p03$1@fang.dsto.defence.gov.au...
>  > > "Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
>  > > news:3d84f7dc@news.microsoft.com...

>  > > > What about just deprecating iostream non-exception error handling?

>  > > I hope you're kidding.
> I'm not. Especially after reading Standard C++ IOStreams and Locales
> by Klaus Kreft & Angelika Langer.

> Working with both exceptions and non-exception error handling is a
> proven nightmare.

In what sense?  Exceptions are not appropriate for "errors" which must
be handled immediately.  Which is the case of most iostream errors.

>  > > Let's say, for sake of discussion, that istream >> operators
>  > > threw an exception if they hit end of file.  That would mean
>  > > something like
>  <snip>
>  > > I think (or hope!) few people would argue that the second
>  > > approach is more maintainable than the first.

>  > End of file is neither an error nor is it exceptional behavior.  In
>  > fact, it is absolutely expected behavior.  Thus, recommending
>  > exception error handling wouldn't apply.  Reading beyond the end of
>  > file would be a candidate for an exception though.

> I Agree. According to C++PL SE 21.3.6 Stourtrup also doesn't consider
> EOF as an error.

If you're reading sequentially, and don't encounter an EOF sooner or
later, I would consider it an error.

On the other hand, the iostream do not distinguish between reaching end
of file, and reading arbitrarily somewhere beyond the end of file.  The
only way to reliably detect end of file is to try and read a value.  And
encountering end of file in this case is neither an error nor an
exceptional condition.

> Working with streams and STL (e.g. using stream iterators) also proves
> that EOF is not an error and other streams errors are best handled
> using exceptions.

What other errors?  About the only other error istream detects is an
input format error -- hardly something exceptional, or that you would
want to raise an exception.

> I think that, for example, ostream_iterator is useless without ostream
> exceptions because working without exceptions with STL is just
> useless.  The following code becomes nonsense when non-exception error
> handling is being used (and again - EOF is not an error):

> #include <iostream>
> #include <algorithm>
> #include <vector>

> using namespace ::std;

> template<typename InputIterator, typename OutputIterator>
> OutputIterator sorted_copy(InputIterator first, InputIterator last,
>                             OutputIterator result)
> {
>      typedef typename iterator_traits<InputIterator>::value_type value_type;
>
>      vector<value_type> v(first, last);
>      sort(v.begin(), v.end());

>      return copy(v.begin(), v.end(), result);
> }

> int main()
> {
>      sorted_copy(istream_iterator<double, char>(cin),
>                  istream_iterator<double, char>(),
>                  ostream_iterator<double, char>(cout, "\n"));
> }

> If non-exception error handling is the only useful error handling then
> how can I reuse sorted_copy for streams?

I'm not sure what point you are trying to make, unless it is that
istream_iterators are pretty useless beasts, because they don't handle
errors correctly.  The above code is wrong, regardless of how istream
reports its errors.  The exception has to be caught, or the stream
state tested.  The easiest solution today (supposing the lack of an
error message acceptable) is to add a line:

    return cin && ! cin.eof() ? EXIT_SUCCESS : EXIT_FAILURE ;

at the end of main.  A more acceptable solution would output an error
message in case of error.

How would having the error reported by an exception be any better?

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

kanze@gabi-soft.de (James Kanze) writes:

> In what sense?  Exceptions are not appropriate for "errors" which must
> be handled immediately.

Depend on what you mean by immediately.  I'd say instead "at the
current level" because exceptions force the handling of the error to
be done immediately.

Non exception IOStream error handling can be delayed far further that
exception one.  It can even never be done.

> > Working with streams and STL (e.g. using stream iterators) also proves
> > that EOF is not an error and other streams errors are best handled
> > using exceptions.
>
> What other errors?  About the only other error istream detects is an
> input format error -- hardly something exceptional, or that you
> would want to raise an exception.

I think we all agree that using IOStream formatted input when you want
to do serious error handling is not a good choice.  So it remains the
failures reported at the streambuf level.

Such errors have to be handled also for output.  And here among these
errors there is the "device full" error which can be quite important.

For such kind of errors to be handled effectively, this should be done
under the control of the programmer and at the streambuf level (so
that continuing from another source to another destination is a
possibility, or asking user advice on what to do).  If you want such
handling, the only standard provided way is to write a custom
streambuf which will forward all IO actions but trap reported errors.

The code doing the IO is not a good place: it should be independant of
the kind of IO done, and the error correction action is intrinsicly
dependant on it.

So the next level where they can be handled -- but less effectively --
is the place where the streambuf are created.  And an exception is a
good way to reach this place.  Ignoring all IO done after the error is
another way, but it assume more on the rest of the program.

Yours,

--
Jean-Marc

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

"Rob" <nospam@does.not.exist> wrote in message
news:ambio7$p03$1@fang.dsto.defence.gov.au...
> "Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
> news:3d84f7dc@news.microsoft.com...
> >  >
> > What about just deprecating iostream non-exception error handling?
> >
>
> I hope you're kidding.
>
> Let's say, for sake of discussion, that istream >> operators threw an
> exception if they hit end of file.   That would mean something like
<snip>
> I think (or hope!) few people would argue that the second approach
> is more maintainable than the first.

End of file is neither an error nor is it exceptional behavior.  In
fact, it is absolutely expected behavior.  Thus, recommending exception
error handling wouldn't apply.  Reading beyond the end of file would be
a candidate for an exception though.

Ken



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

"Ken Alverson" <Ken@Alverson.net> wrote in message
news:amd0fq$k6v$1@eeyore.INS.cwru.edu...
 > "Rob" <nospam@does.not.exist> wrote in message
 > news:ambio7$p03$1@fang.dsto.defence.gov.au...
 > > "Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
 > > news:3d84f7dc@news.microsoft.com...
 > > >  >
 > > > What about just deprecating iostream non-exception error handling?
 > > >
 > >
 > > I hope you're kidding.
I'm not. Especially after reading Standard C++ IOStreams and Locales by
Klaus Kreft & Angelika Langer.

Working with both exceptions and non-exception error handling is a proven
nightmare.

 > >
 > > Let's say, for sake of discussion, that istream >> operators threw an
 > > exception if they hit end of file.   That would mean something like
 > <snip>
 > > I think (or hope!) few people would argue that the second approach
 > > is more maintainable than the first.
 >
 > End of file is neither an error nor is it exceptional behavior.  In
 > fact, it is absolutely expected behavior.  Thus, recommending exception
 > error handling wouldn't apply.  Reading beyond the end of file would be
 > a candidate for an exception though.
 >

I Agree. According to C++PL SE 21.3.6 Stourtrup also doesn't consider EOF as
an error.


Working with streams and STL (e.g. using stream iterators) also proves that
EOF is not an error and other streams errors are best handled using
exceptions.
I think that, for example, ostream_iterator is useless without ostream
exceptions because working without exceptions with STL is just useless.
The following code becomes nonsense when non-exception error handling is
being used (and again - EOF is not an error):

#include <iostream>
#include <algorithm>
#include <vector>

using namespace ::std;

template<typename InputIterator, typename OutputIterator>
OutputIterator sorted_copy(InputIterator first, InputIterator last,
                            OutputIterator result)
{
     typedef typename iterator_traits<InputIterator>::value_type value_type;

     vector<value_type> v(first, last);
     sort(v.begin(), v.end());

     return copy(v.begin(), v.end(), result);
}

int main()
{
     sorted_copy(istream_iterator<double, char>(cin),
                 istream_iterator<double, char>(),
                 ostream_iterator<double, char>(cout, "\n"));
}

If non-exception error handling is the only useful error handling then how
can I reuse sorted_copy for streams?

Rani



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

"Ken Alverson" <Ken@Alverson.net> writes:

> End of file is neither an error nor is it exceptional behavior.  In
> fact, it is absolutely expected behavior.  Thus, recommending exception
> error handling wouldn't apply.  Reading beyond the end of file would be
> a candidate for an exception though.

How do you detect end of file in C++ without trying to read beyond?

Yours,

--
Jean-Marc

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

"Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
news:<3d84f7dc@news.microsoft.com>...
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0209090209.2cc74037@posting.google.com...
>  > [...]
>  > And any attempt to deprecate iostream had best be
>  > preceded by defining some alternative way of doing IO.

> What about just deprecating iostream non-exception error handling?

You mean the only useful error handling in the iostreams?

--
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.research.att.com/~austern/csc/faq.html                ]

"Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
news:3d84f7dc@news.microsoft.com...
>
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0209090209.2cc74037@posting.google.com...
>  > [...]
>  > And any attempt to deprecate iostream had best be
>  > preceded by defining some alternative way of doing IO.
>  >
> What about just deprecating iostream non-exception error handling?
>

I hope you're kidding.

Let's say, for sake of discussion, that istream >> operators threw an
exception if they hit end of file.   That would mean something like

while (infile)    // infile of some type derived from istream
{
        infile >> some_variable;
}

would have to be rewritten as something like

bool completed = false;
while (!completed)
{
     try
     {
            infile >> some_variable;
     }
     catch (exception_thrown_on_EOF)
     {
            completed = true;
      }
}

I think (or hope!) few people would argue that the second approach
is more maintainable than the first.

One of my pet peeves with Java is that its I/O library throws exceptions
in some circumstances rather than simply returning an error code.
---
[ 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                ]

Allan_W@my-dejanews.com (Allan W) wrote in message
news:<23b84d65.0209131546.47c9cd26@posting.google.com>...
> >  > alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
> >  >  > Let's deprecate everything in the standard library except the STL.

>  Allan_W@my-dejanews.com (Allan W) wrote
> >  > Why?

> kanze@gabi-soft.de (James Kanze) wrote
> > I think Alf thought it was April 1st:-).  I'm sure that if he had
> > meant it seriously, he would have explained what he really meant.

> Yes, I thought so... but I wanted to see him say so. (He did, later.)

> >  > Some of that stuff is useful, and doesn't have any STL
> >  > alternatives.  For instance, the data type int.

> > The data type int isn't part of the library, so presumably wouldn't
> > be deprecated.

> You're right. Alf's post was short and direct, but I still managed to
> mis-read it. Deprecating the whole library except for the STL, is a
> much better idea than deprecating the whole language except for the
> STL.  :-)

We could deprecate only the parts of the language that no one really
understands anyway.  That should suffice to give us a really small
language -- no template, no function overloading, and once you get rid
of the library components which use these features, there's not much
left there either:-).  (Even operator new is overloaded.)

> > On the other hand, I doubt that he really wants to deprecate new and
> > delete (which depend on functions in the the standard library that
> > are not part of the STL).

> std::allocate is part of the STL.

But std::allocate is defined to use operator new.  And operator new
isn't part of the STL.

> > And any attempt to deprecate iostream had best be preceded by
> > defining some alternative way of doing IO.

> What if Alf had said,
>     Let's deprecate everything in the standard library except the STL
>     and the C library.
> Would this have made more sense?

Seriously, we have a contract.  What do you think my bank would say if I
suggested deprecating the repayment of my loan?

> Okay, Alf's suggestion was in jest, and nobody would seriously
> consider it. But what parts of the standard library (sections 17-27)
> are absolutely essential, as opposed to useful? Roughly speaking, this
> is sections 23-25, plus section 26.5 and parts of section 20.

Absolutely essential with regards to what?  A program which does no IO
isn't generally very useful, but my last application only used the
standard library for IO for the log streams -- all of the real work was
binary over sockets.  And let's face it, logging isn't a necessity.  So
we can get rid of anything to do with text.

For that matter, I can't remember the last time I used any floating
point in an application.  So that's certainly not essential.  It also
(almost) falls under my first criteron as well: nobody really
understands machine floating point:-).

> We would also need section 18 (the Language Support Library) to
> support some language features (i.e. set_new_handler) and to support
> cross-platform development (i.e. numeric_limits).

> What about section 19 (Diagnostics Library)? If we deprecated most of
> the library, we wouldn't need so many standard exceptions either. And
> in every C++ shop where I've worked, we've had to define our own
> assert-like system... having it as part of the standard library was
> pretty much irrelevant.

> "But I don't consider assert() irrelevant!" you say? There's the rub.
> I'm sure that every serious C++ programmer could pick at least a few
> pages from the standard and call it irrelevant, but every part will be
> championed by someone as well -- even ignoring compatibility issues
> with legacy code and with C. You might think that locales are useless,
> but someone else uses it every day. You may prefer the OS's
> time-of-day calls to the standard ways, but by definition these aren't
> portable. And so on.

> I think that trying to remove a single "useless" feature from the
> language is already tough enough -- because if it was really useless,
> it wouldn't be in the standard in the first place. Saying that whole
> sections should be deprecated, is simply impossible.

It's impossible because we have a contract.  Otherwise...

The standard has, for the most part, been carefully analysed and
discussed by some of the best experts in the field.  With a few
exceptions (like std::string), it is probably locally optimal -- any
large part fits together, and you can't just remove a little bit.  But
without the contract, you could probably remove large, more or less
independant chunks.

Some people have actually tried this experiment.  The result is called
Java, and they are now busy adding many of the chunks back in.  Because
guess what: they turned out to be more useful that some people thought.

--
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.research.att.com/~austern/csc/faq.html                ]

Alf P. Steinbach wrote:

> Let's deprecate everything in the standard library except the STL.


    I'd like to move the length-unsafe functions of the C library
(i.e. "sprintf", , but not "printf", "fread", etc.) to a header
with some name like "deprecated-unsafe-stdio".  Hang a warning
sign on potential buffer overflows.  It's 2002, it's time.

                                John Nagle



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

Allan_W@my-dejanews.com (Allan W) wrote in message
news:<23b84d65.0209061351.29592c42@posting.google.com>...
 > alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
 >  > Let's deprecate everything in the standard library except the STL.

 > Why?

I think Alf thought it was April 1st:-).  I'm sure that if he had meant
it seriously, he would have explained what he really meant.

 > Some of that stuff is useful, and doesn't have any STL alternatives.
 > For instance, the data type int.

The data type int isn't part of the library, so presumably wouldn't be
deprecated.

On the other hand, I doubt that he really wants to deprecate new and
delete (which depend on functions in the the standard library that are
not part of the STL).  And any attempt to deprecate iostream had best be
preceded by defining some alternative way of doing IO.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique oriente objet/
                     Beratung in objektorientierter Datenverarbeitung



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

Carlos Moreno <moreno_at_mochima_dot_com@xx.xxx> wrote in message news:<3D77BE5B.70208@xx.xxx>...

 > Alf P. Steinbach wrote:
 >
 > > Let's deprecate everything in the standard library except the STL.
 >
 > This is nonsense!  Absolutely absurd!
 >
 > This would leave us with an inconsistent language:  for example, you
 > can have a vector<int> but not a vector<string> or vector<complex> ???
 >
 > You'd have to impose a rule that you can only have vectors of built-in
 > types, but then that leaves us without vector< vector<int> >, which
 > is an unacceptable inconsistency...  For true consistency, you'd have
 > to eliminate all possible type parameters in the instantiation of
 > any STL container that is not a built-in type.  But then that would
 > imply eliminating vector as well (since vector is a non-builtin, and
 > could be the type parameter in the instantiation of a vector, or
 > list, etc.)
 >
 > In other words, to be consistent, we'd have to deprecate the STL
 > containers.

I think you misread Alf's proposal. You seem to believe that he wishes
to forbid STL containers from containing anything which is not in the
STL -- that, of course, would be "absolutely absurd," as the STL would
be useless. However, that is not at all what he meant. Rather, he is
suggesting that those things which are part of the Standard Library
but not part of the STL should be deprecated.

For instance, <cstdio>, which is currently part of the Standard
Library but not part of the STL, would be deprecated. This means that,
under this proposal, you shouldn't use anything from this header, such
as FILE *, in C++ code:

   FILE *file;       // deprecated; don't use FILE *
   FILE *files[10];  // deprecated; don't use FILE *
   vector<FILE *> v; // deprecated; don't use FILE *

Alf's proposal says nothing more about a vector of FILE * than it does
about an array of FILE * -- both use FILE *, which would be deprecated
in any context.

(Note that I'm not agreeing with or defending Alf's proposal; I'm just
clarifying it for you, since you seem to have misunderstood it. :) )

- Shane



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

Yes, Alf, I'm with you...  We are soooo misunderstood  ;-)

(in other words, Shane, Alf's post was entirely humorous, and my
follow-up was also intended to be humorous -- so, either my sense
of humor sucks, or it's too sophisticated and thus misunderstood ;-))

Cheers,

Carlos
--

Shane Beasley wrote:

>
> I think you misread Alf's proposal. You seem to believe that he wishes
> to forbid STL containers from containing anything which is not in the
> STL -- that, of course, would be "absolutely absurd," as the STL would
> be useless. However, that is not at all what he meant. Rather, he is
> suggesting that those things which are part of the Standard Library
> but not part of the STL should be deprecated.
>
> For instance, <cstdio>, which is currently part of the Standard
> Library but not part of the STL, would be deprecated. This means that,
> under this proposal, you shouldn't use anything from this header, such
> as FILE *, in C++ code:
>
>    FILE *file;       // deprecated; don't use FILE *
>    FILE *files[10];  // deprecated; don't use FILE *
>    vector<FILE *> v; // deprecated; don't use FILE *
>
> Alf's proposal says nothing more about a vector of FILE * than it does
> about an array of FILE * -- both use FILE *, which would be deprecated
> in any context.
>
> (Note that I'm not agreeing with or defending Alf's proposal; I'm just
> clarifying it for you, since you seem to have misunderstood it. :) )



      [ 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) wrote
>  >  > Let's deprecate everything in the standard library except the STL.

> Allan_W@my-dejanews.com (Allan W) wrote
>  > Why?

kanze@gabi-soft.de (James Kanze) wrote
> I think Alf thought it was April 1st:-).  I'm sure that if he had meant
> it seriously, he would have explained what he really meant.

Yes, I thought so... but I wanted to see him say so. (He did, later.)

>  > Some of that stuff is useful, and doesn't have any STL alternatives.
>  > For instance, the data type int.
>
> The data type int isn't part of the library, so presumably wouldn't be
> deprecated.

You're right. Alf's post was short and direct, but I still managed to
mis-read it. Deprecating the whole library except for the STL, is a
much better idea than deprecating the whole language except for the
STL.  :-)

> On the other hand, I doubt that he really wants to deprecate new and
> delete (which depend on functions in the the standard library that are
> not part of the STL).

std::allocate is part of the STL.

> And any attempt to deprecate iostream had best be
> preceded by defining some alternative way of doing IO.

What if Alf had said,
    Let's deprecate everything in the standard library except the STL
    and the C library.
Would this have made more sense?

Okay, Alf's suggestion was in jest, and nobody would seriously consider
it. But what parts of the standard library (sections 17-27) are absolutely
essential, as opposed to useful? Roughly speaking, this is sections
23-25, plus section 26.5 and parts of section 20.

We would also need section 18 (the Language Support Library) to support
some language features (i.e. set_new_handler) and to support
cross-platform development (i.e. numeric_limits).

What about section 19 (Diagnostics Library)? If we deprecated most of
the library, we wouldn't need so many standard exceptions either. And
in every C++ shop where I've worked, we've had to define our own
assert-like system... having it as part of the standard library was
pretty much irrelevant.

"But I don't consider assert() irrelevant!" you say? There's the rub.
I'm sure that every serious C++ programmer could pick at least a few
pages from the standard and call it irrelevant, but every part will
be championed by someone as well -- even ignoring compatibility
issues with legacy code and with C. You might think that locales are
useless, but someone else uses it every day. You may prefer the OS's
time-of-day calls to the standard ways, but by definition these aren't
portable. And so on.

I think that trying to remove a single "useless" feature from the
language is already tough enough -- because if it was really useless,
it wouldn't be in the standard in the first place. Saying that whole
sections should be deprecated, is simply impossible.



      [ 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" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0209090209.2cc74037@posting.google.com...
 > [...]
 > And any attempt to deprecate iostream had best be
 > preceded by defining some alternative way of doing IO.
 >
What about just deprecating iostream non-exception error handling?

Rani



      [ 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 Sun, 08 Sep 2002 01:14:18 +0300, 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.)

That section indicates that some people interpreted
  D -> R
as implying
  ~D -> ~R
which is just plain bad logic.


Anyway, I think the post was nothing more than an amusing shake up, not
necessarily to be taken 100% at face value. "Troll" or "flamebait" would
be the wrong word for it - "po" in De Bono-speak I think is closest.


Phil



      [ 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 7 Sep 2002 22:14:18 GMT, Herb Sutter <hsutter@gotw.ca> 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.)
>
>2. Enumerate what you think is in the set E' = { everything } - { STL }.
>(For example, do you include basic_string, which is a container? what about
>streams, which can be iterated over?)
>
>3. Assuming E' is nonempty, for each major item in E' justify why you think
>it should be deprecated.
>
>Then we can get started. Thanks,
>
>Herb

Hm, I'd better stop this before it goes any further... ;-)

As everyone who answered now, three in a row, saw, but
possibly not everybody else will, it was tongue-in-cheek,
even though no emoticon.  I'll make up for that: ;-) ;-)

We have a saying from the Danish poet Piet Hein, I think
(these small verses are called "gruk"s):


  Den som kun tar sp   k for sp   k
  og alvor kun alvorlig
  den har faktisk fattet
  begge deler like d   rlig


I think your points are also in that category; jokes, but
also serious jokes.  In particular, your points (1) and (2)
*deserve*, I think, to be discussed seriously on their own,
without aiming for deprecation of anything.  Unfortunately
I don't feel I'm qualified for that discussion.

Cheers,
(and thanks for decent reply even though you thought flame!)


- Alf



      [ 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) wrote
 > Let's deprecate everything in the standard library except the STL.

Why?

Some of that stuff is useful, and doesn't have any STL alternatives.
For instance, the data type int.

Maybe you want to use deprecation as a means of identifying what we
informally call "STL", since that term isn't listed anywhere within
the standard. Then instead of saying "use one of the STL containers"
(which isn't precisely defined because STL isn't defined), we could
say "use one of the non-deprecated containers."

If so -- well, there must be some better way to do this, such as:
   * Defining "STL" somewhere in 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                       ]

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.)

2. Enumerate what you think is in the set E' = { everything } - { STL }.
(For example, do you include basic_string, which is a container? what about
streams, which can be iterated over?)

3. Assuming E' is nonempty, for each major item in E' justify why you think
it should be deprecated.

Then we can get started. Thanks,

Herb

---
Herb Sutter (www.gotw.ca)

Convenor, ISO WG21; Secretary, ANSI J16              (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal             (www.gotw.ca/cuj)
C++ community program manager, Microsoft       (www.gotw.ca/microsoft)

Check out "THE C++ Seminar" - Oct 28-30, 2002  (www.thecppseminar.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 wrote:

> Let's deprecate everything in the standard library except the STL.


This is nonsense!  Absolutely absurd!

This would leave us with an inconsistent language:  for example, you
can have a vector<int> but not a vector<string> or vector<complex> ???

You'd have to impose a rule that you can only have vectors of built-in
types, but then that leaves us without vector< vector<int> >, which
is an unacceptable inconsistency...  For true consistency, you'd have
to eliminate all possible type parameters in the instantiation of
any STL container that is not a built-in type.  But then that would
imply eliminating vector as well (since vector is a non-builtin, and
could be the type parameter in the instantiation of a vector, or
list, etc.)

In other words, to be consistent, we'd have to deprecate the STL
containers.

But then that leaves us with the algorithms and function objects
only.  I'll leave as an exercise for the reader to provide a proof
that this also represents a major inconsistency, and that the only
way to have consistency would be deprecating the entire STL.
Hint: Algorithms (and some adaptors) work with functions or function
objects;  but STL algorithms are indeed functions (templates, but
functions after all)


;-)

Carlos
--



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

Let's deprecate everything in the standard library except the STL.

Cheers,

- Alf

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