<strstream> support in C++2x

<strstream> support in C++2x

[Joel Sherrill]

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?

The warning is generic for using it and it seems as though more direct
guidance could be given if it has been removed.

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

Thanks.

--joel
RTEMS

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

[Jonathan Wakely]

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

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

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

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

[Joel Sherrill]

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

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

[Jonathan Wakely]

On Fri, 9 Oct 2020 at 15:13, Joel Sherrill <joel@rtems.org> wrote:
>
>
>
> 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?

std::ostrstream should never be used anyway IMHO. It's too hard to use
correctly.

std::istrstream is safe, but might finally be on its way out if
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0448r2.pdf
makes progress for C++23.

Or maybe istrstream should be undeprecated (maybe after removing ostrstream).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2139r0.html#3.12
touches on what should happen to them.