strstream depreciation

[Aaron Gray]

Hi,

I have an application that uses 'strstream' in just under half its .cc
files, about 10 files.

What is the replacement for 'strstream' ?
What are my options for replacing it ?

Many thanks in advance,

Aaron

[Howard Hinnant]

In article <42***********************@ptn-nntp-reader03.plus.net>,
"Aaron Gray" <aa********@gmail.com> wrote:

Hi,

I have an application that uses 'strstream' in just under half its .cc
files, about 10 files.

What is the replacement for 'strstream' ?
What are my options for replacing it ?

Many thanks in advance,

Aaron

Try one of:

ostringstream
istringstream
stringstream

which are all in the header <sstream>.

The chances aren't bad that a simple find/replace will get you going
without a hitch. The main difference is that the stringstream family
doesn't expose its internal buffer and is thus less susceptible to
memory leaks.

strstream is deprecated because it is memory leak prone. That is not to
say that correct usage of it might result in a memory leak, just that it
is so easy to misuse it, resulting in a memory leak.

That being said, strstream fulfills a role that has not yet been
replaced in the std::lib: The ability to specify the buffer which the
read/write interacts with. If you need to specify the buffer (say for
performance reasons or whatever), the stringstream family will not do it
for you. There is no alternative in the std::lib for this application.

Although strstream has been deprecated for nearly a decade, I don't
anticipate removing it from C++0X because of the lack of covering the
above mentioned functionality. I have no doubt that a better facility
could be designed for this functionality, but no one to date has
proposed anything.

-Howard

[Aaron Gray]

> Try one of:

ostringstream
istringstream
stringstream

which are all in the header <sstream>.

That being said, strstream fulfills a role that has not yet been
replaced in the std::lib: The ability to specify the buffer which the
read/write interacts with. If you need to specify the buffer (say for
performance reasons or whatever), the stringstream family will not do it
for you. There is no alternative in the std::lib for this application.
Right this is its main usage.
Although strstream has been deprecated for nearly a decade, I don't
anticipate removing it from C++0X because of the lack of covering the
above mentioned functionality. I have no doubt that a better facility
could be designed for this functionality, but no one to date has
proposed anything.

Maybe I will come up with some replacement code for ths app then.
Ether that or keep strstream and like it and lump it.

I can just ignore it for now and use a '-Wno-deprecated' switch.

Thanks for your explanation.

Aaron

[Larry I Smith]

Aaron Gray wrote:

Try one of:

ostringstream
istringstream
stringstream

which are all in the header <sstream>.

That being said, strstream fulfills a role that has not yet been
replaced in the std::lib: The ability to specify the buffer which the
read/write interacts with. If you need to specify the buffer (say for
performance reasons or whatever), the stringstream family will not do it
for you. There is no alternative in the std::lib for this application.

Right this is its main usage.

Although strstream has been deprecated for nearly a decade, I don't
anticipate removing it from C++0X because of the lack of covering the
above mentioned functionality. I have no doubt that a better facility
could be designed for this functionality, but no one to date has
proposed anything.

Maybe I will come up with some replacement code for ths app then.
Ether that or keep strstream and like it and lump it.

I can just ignore it for now and use a '-Wno-deprecated' switch.

Thanks for your explanation.

Aaron

stringstream does allow you to specify a buffer, e.g.

std::string str;
char * pCh;

// put stuff into 'str'...
// make 'pCh' point to some char array...

// make a stringstream from a COPY of 'str'
std::stringstream s1(str);
// make a stringstream from a COPY of '*pCh'
std::stringstream s2(pCh);
// make a stringstream from a COPY of "hello there"
std::stringstream s3("hello there");

s1, s2, and s3 make a std::stringstream using a COPY
of the data specified by their constructor arg.

One can not create a stringstream that access a fixed
address as its string buffer (e.g. some specific memory
address) because stringstream always makes a COPY of
any string arg passed to its constructor.

[Jeff Flinn]

"Aaron Gray" <aa********@gmail.com> wrote in message
news:42***********************@ptn-nntp-reader03.plus.net...

Try one of:

ostringstream
istringstream
stringstream

which are all in the header <sstream>.

That being said, strstream fulfills a role that has not yet been
replaced in the std::lib: The ability to specify the buffer which the
read/write interacts with. If you need to specify the buffer (say for
performance reasons or whatever), the stringstream family will not do it
for you. There is no alternative in the std::lib for this application.

Right this is its main usage.

Although strstream has been deprecated for nearly a decade, I don't
anticipate removing it from C++0X because of the lack of covering the
above mentioned functionality. I have no doubt that a better facility
could be designed for this functionality, but no one to date has
proposed anything.

Maybe I will come up with some replacement code for ths app then.
Ether that or keep strstream and like it and lump it.

You might want to take a look at the boost IOStreams library at:
http://www.boost.org/libs/iostreams/doc/index.html.

In particular see array_source, array_sink, and array devices for input,
output and io streams respectively.
....

#include <boost/iostreams/device/array.hpp>

....

using namespace boost::iostreams;

char* dataptrx = new char[datasize];

stream<array> io( dataptr, datasize );

io << 123;

int an_int = 0;

io>> an_int;

....
Jeff Flinn

[Pete Becker]

Aaron Gray wrote:

Maybe I will come up with some replacement code for ths app then.
Ether that or keep strstream and like it and lump it.

If your application works, don't change it just because of some vague
fear that this class might go away in the future. Wait and see. It might
never need changing.
I can just ignore it for now and use a '-Wno-deprecated' switch.

Massively rewriting correct, working code to avoid a warning is a waste
of time.

--

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

[Aaron Gray]

> stringstream does allow you to specify a buffer, e.g.

The app writes to the buffer using streams then reads the written buffer :(

Aaron

[Aaron Gray]

>> Maybe I will come up with some replacement code for ths app then.

Ether that or keep strstream and like it and lump it.

If your application works, don't change it just because of some vague fear
that this class might go away in the future. Wait and see. It might never
need changing.

okay, thanks.

I can just ignore it for now and use a '-Wno-deprecated' switch.

Massively rewriting correct, working code to avoid a warning is a waste of
time.

Thanks,

Aaron

[Aaron Gray]

> You might want to take a look at the boost IOStreams library at:

http://www.boost.org/libs/iostreams/doc/index.html.

In particular see array_source, array_sink, and array devices for input,
output and io streams respectively.
...

#include <boost/iostreams/device/array.hpp>

...

using namespace boost::iostreams;

char* dataptrx = new char[datasize];

stream<array> io( dataptr, datasize );

io << 123;

int an_int = 0;

io>> an_int;

...

Okay thanks, I will look into that.

Aaron

[Larry I Smith]

Aaron Gray wrote:

stringstream does allow you to specify a buffer, e.g.

The app writes to the buffer using streams then reads the written buffer :(

Aaron

That's fine. That's what stringstream is for.
We do that all of the time:

1) create a stringstream (often as a member of an object)
2) write to the stringstream
3) read from the stringstream.

Larry

[Aaron Gray]

> That's fine. That's what stringstream is for.

We do that all of the time:

1) create a stringstream (often as a member of an object)
2) write to the stringstream
3) read from the stringstream.

Ah :)

Thats a bit obvious now :)

Thanks.

Aaron