Re: <strstream> support in C++2x

[Joel Sherrill <joel@rtems.org>]

On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill <joel@rtems.org> wrote:
> >
> > Hi
> >
> > <strstream> being deprecated for nearly 20 years of C++ standards has
> > always been a bit baffling to me. I'm used to thingis being deprecated
> and
> > then removed a bit faster than that.
> >
> > It is still deprecated in C++17 but does not appear in C++2x as of
> > draft N4860. GCC 10 still behaves the same and you get a deprecated
> warning
> > when you use --std=c++2x.
> >
> > Am I reading the draft N4860 correctly and it is finally being removed?
>
> No, it's still there in the same place, Annex D. See D.12
> [depr.strstreambuf].
>

Apparently the PDF file is huge and was taking forever to load and that's
why my search for "strstr" didn't turn up anything.

I'm asking because this came up in a discussion of whether the FACE
Technical Standard for avionics should consider forbidding its use
as deprecated. It sounds like we are years away from it disappearing
and avionics applications do not use the latest C++ versions anyway.

In your opinion, would using this be a risk for use in a long-lived
application?


> > The warning is generic for using it and it seems as though more direct
> > guidance could be given if it has been removed.
>
> It hasn't been. It won't be removed until a suitable replacement is
> added to the library, and even then implementations won't be required
> to remove it. We still make std::auto_ptr available despite it being
> removed in C++17 (after deprecation in C++11).
>

It is a hard edge to walk when you have to obsolete something.

Over at RTEMS, we have had a great port of FreeBSD services
including IPV4, IPV6, Wifi, USB, SDMMC, etc. for at least five years.
But getting rid of the 20+ year old IPV4 only FreeBSD stack is going
to be a pain for users who will have to port drivers to the new stack.

Killing old features isn't easy. We all want to minimize impact on users.


> >
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2:
> > warning: #warning This file includes at least one deprecated or
> antiquated
> > header which may be removed without further notice at a future date.
> Please
> > use a non-deprecated interface with equivalent functionality instead.
> For a
> > listing of replacement headers and interfaces, consult the file
> > backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
> >
> > I'm far from complaining about it being removed. I just want to make
> sure I
> > am interpreting the draft C++ standard correctly and see if there is a
> > desired to slightly improve GCC's warning to give more specific advice.
>
> The libstdc++ list would be a better place to discuss that kind of thing.
>

If it hasn't been removed, then this is more than acceptable.

If it is ever is removed, then a more precise message may be useful.

Thank you for the quick response.

--joel