ostringstream / ostrstream problem

[Mathieu Malaterre]

Hello,

I am trying to write this simple code:

std::ostringstream s;
s << 1024;
std::cout << s.str() << std::endl;
s.str(""); // <- problem
s << 512;
std::cout << s.str() << std::endl;

The problem is that behind the scene I have a limited implementation of
ostringstream on system that does not support it:

class ostringstream : public ostrstream {
public:
string str() {
char *cstr = ostrstream::str();
freeze(0);
if (cstr == 0) return string();
return string(cstr,pcount());
}
};
I have two options:

- Enhance the limited implementation, which I am not very keen on
- Find a smarter way to do str("") that works for both ostringstream and
my limited ostringstream
Any advices ?
Thanks,
Mathieu
Ps: I tried s.seekp(0) instead of str("") but that leave garbage at the
end...

[Dietmar Kuehl]

Mathieu Malaterre wrote:

The problem is that behind the scene I have a limited implementation of ostringstream on system that does not support it:

class ostringstream : public ostrstream {
public:
string str() {
char *cstr = ostrstream::str();
freeze(0);
if (cstr == 0) return string();
return string(cstr,pcount());
}
};
Yuk! This code is not guaranteed to work: with the call to 'freeze(0)'
you state that you are done with the returned pointer and your are
not going to access it any further.You actually break this contract.
In addition, 'pcount()' is only supposed to return the number of
characters inserted by the last unformatted output operation (if I
remember correctly). If you insist in using 'std::ostrstream'
underneath, you should terminate the string properly (e.g. using the
manipulator 'std::ends') and then use an appropriate constructor of
'std::string'.
I have two options:

- Enhance the limited implementation, which I am not very keen on
- Find a smarter way to do str("") that works for both ostringstream and my limited ostringstream
I see at last two more options which should be considered:
- Ditch your current compiler and/or standard library and upgrade to a
reasonable one!
- Write your own stream class which just does the right thing: it just
takes a dozen of lines or so.

If all you need is a simple 'std::ostringstream' replacement which may
be
restricted to fixed size buffer but supports 'str(std::string const&)',
this just takes a few lines of code, roughly something like this:

struct stringbuf:
std::streambuf
{
enum { s_size = 1024 };
stringbuf() { setp(m_buf, m_buf + s_size); }
std::string str() const { return std::string(pbase(), pptr()); }
void str(std::string const& s) {
std::copy(s.begin(), s.end(), m_buf);
}
private:
char m_buf[s_size];
};

struct ostringstream:
private virtual stringbuf,
std::ostream
{
ostringstream(): std::ostream(static_cast<std::streambuf*>(this))
{}
};

Well, in a real implementation I would use a more solid approach than
just deriving from the stream buffer but I'm too lazy to show it once
again (I have posted many examples of this in the past).
Any advices ?

My preference would be:
- Use a reasonable standard library.
- Use a appropriate stream buffer like the one above (although you
probably would add error checking and possibly lift the size
restriction).
- I would *not* use either of your options.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Mathieu Malaterre]

Dietmar Kuehl wrote:

Mathieu Malaterre wrote:

The problem is that behind the scene I have a limited implementation

of

ostringstream on system that does not support it:

class ostringstream : public ostrstream {
public:
string str() {
char *cstr = ostrstream::str();
freeze(0);
if (cstr == 0) return string();
return string(cstr,pcount());
}
};

Yuk! This code is not guaranteed to work: with the call to 'freeze(0)'
you state that you are done with the returned pointer and your are
not going to access it any further.You actually break this contract.
In addition, 'pcount()' is only supposed to return the number of
characters inserted by the last unformatted output operation (if I
remember correctly). If you insist in using 'std::ostrstream'
underneath, you should terminate the string properly (e.g. using the
manipulator 'std::ends') and then use an appropriate constructor of
'std::string'.

I have two options:

- Enhance the limited implementation, which I am not very keen on
- Find a smarter way to do str("") that works for both ostringstream

and

my limited ostringstream

I see at last two more options which should be considered:
- Ditch your current compiler and/or standard library and upgrade to a
reasonable one!
- Write your own stream class which just does the right thing: it just
takes a dozen of lines or so.

If all you need is a simple 'std::ostringstream' replacement which may
be
restricted to fixed size buffer but supports 'str(std::string const&)',
this just takes a few lines of code, roughly something like this:

struct stringbuf:
std::streambuf
{
enum { s_size = 1024 };
stringbuf() { setp(m_buf, m_buf + s_size); }
std::string str() const { return std::string(pbase(), pptr()); }
void str(std::string const& s) {
std::copy(s.begin(), s.end(), m_buf);
}
private:
char m_buf[s_size];
};

struct ostringstream:
private virtual stringbuf,
std::ostream
{
ostringstream(): std::ostream(static_cast<std::streambuf*>(this))
{}
};

Well, in a real implementation I would use a more solid approach than
just deriving from the stream buffer but I'm too lazy to show it once
again (I have posted many examples of this in the past).

Any advices ?

My preference would be:
- Use a reasonable standard library.
- Use a appropriate stream buffer like the one above (although you
probably would add error checking and possibly lift the size
restriction).
- I would *not* use either of your options.
--

Dietmar,

Here is the patch I am using now:

http://public.kitware.com/cgi-bin/vi...&r2=1.6&r1=1.5

I'll see tomorow if this works on the broken plateforms ITK is building on.

Thanks for your help
Mathieu

[Dietmar Kuehl]

Mathieu Malaterre wrote:

Here is the patch I am using now:

http://public.kitware.com/cgi-bin/vi...&r2=1.6&r1=1.5

This stuff uses some rather fishy techiques! I recommend
that you use the approach I have proposed: unless I have
made some blatant and obvious programming errors (I didn't
test the code prior to posting), it is the way stream
buffers are intended to be used. I don't have the standard
C++ library implementation I have done with me but I'm
pretty sure that the basics are the same. Of course, it is
your choice to ignore my advice on IOStreams but you might
want to briefly investigate my background before doing so
(e.g. have a look who translated/extended the IOStream
chapter of Nico's "The C++ Standard Library").
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting