In article <IvSdnfthrdbNtjDfRVn-rw@speakeasy.net>,
 hattons@globalsymmetry.com ("Steven T. Hatton") wrote:

> I suspect there is little hope of changing the situation.  Nonetheless, I am
> curious to know of a common use of stringstream constructed by the
> constructor taking a string argument and not passing ios_base:ate as a
> second argument. I've provided an example of using stringstream in a
> program where having the write pointer placed after the initializing
> content is clearly useful.  I don't see much use for the behavior that
> actually resulted from the program when I omitted the step of moving the
> write pointer beyond the initial content.

It is used as an optimization to preallocate the buffer in the
ostringstream (like reserve).

-Howard

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

Howard Hinnant wrote:

> In article <IvSdnfthrdbNtjDfRVn-rw@speakeasy.net>,
>  hattons@globalsymmetry.com ("Steven T. Hatton") wrote:
>
>> I suspect there is little hope of changing the situation.  Nonetheless, I
>> am curious to know of a common use of stringstream constructed by the
>> constructor taking a string argument and not passing ios_base:ate as a
>> second argument. I've provided an example of using stringstream in a
>> program where having the write pointer placed after the initializing
>> content is clearly useful.  I don't see much use for the behavior that
>> actually resulted from the program when I omitted the step of moving the
>> write pointer beyond the initial content.
>
> It is used as an optimization to preallocate the buffer in the
> ostringstream (like reserve).
>
> -Howard

That doesn't sound like a valid analogy.  reserve preallocates, but does not
initialize the reserved memory beyond the end of the content data. If
people really are passing non-zero length strings to stringstream as a
means of preallocation, I would say this demonstrates a problem with the
current standard.  There may be subtelties that I am not aware of, but it
would seem to make more sense to call reserve on a zero length string
before it is passed (as a reference?) to the stringstream constructor.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

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

I've recently come to understand that std::stringstream behaves
counterintuitively when constructed with default content.  I'm not
completely certain as to what the sequence of specification is that
concludes in defining the behavior.  To some extent I'm taking another
person's word for this.

As I understand the behavior of std::stringstream, it has its pptr set to
the beginning of its content data when constructed with the constructor
that takes an initial content argument.  The result is that, in the case of
an ostringstream, the initial content is targeted for replacement unless,
and until, the pptr is set to one past the end of the initial content using
seekp(0, std::ios_base::end).  The specified initial condition makes sense
for an istringstream, but not (to me) for an ostringstream.

Is there a reason std::stringstream is specified in this way?
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

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

Steven T. Hatton wrote:

> Is there a reason std::stringstream is specified in this way?

Consistency? If you open an ofstream with its mode parameter set to
ios::out, you also end up with the writing pointer positioned at the
_beginning_ of the character sequence controlled by it.

Of course, ofstream supports ios::ate (place write position at the end
of the sequence after opening) and ios::app (every write goes to the end
of the sequence), which the standard ostringstream does not.

This support (at least ios::ate) seems to get added by issue #432:

    http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432

A quick test among freely available implementations revealed all of them
supporting the ios::ate mode for stringstreams.

~Marc

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

Marc Schoolderman wrote:

> Steven T. Hatton wrote:
>
>> Is there a reason std::stringstream is specified in this way?
>
> Consistency? If you open an ofstream with its mode parameter set to
> ios::out, you also end up with the writing pointer positioned at the
> _beginning_ of the character sequence controlled by it.
>
> Of course, ofstream supports ios::ate (place write position at the end
> of the sequence after opening) and ios::app (every write goes to the end
> of the sequence), which the standard ostringstream does not.
>
> This support (at least ios::ate) seems to get added by issue #432:
>
>     http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432
>
> A quick test among freely available implementations revealed all of them
> supporting the ios::ate mode for stringstreams.
>
> ~Marc

If the behavior I encountered is that which is specified in the Standard, I
have to say, it seems contrary to reasonable expectations. This demonstrates
the problem I encountered using gcc (GCC) 3.3.4 (pre 3.3.5 20040809):

#include <iostream>
#include <string>
#include <sstream>

std::string str1() {
  std::stringstream s;
  s <<""
    "Whoever limiting his worldly ambitions finds satisfaction in the speculative\n"
    "life has in the approval of an enlightened and competent judge a powerful\n"
    "incentive to labours, the benefits of which are great but remote, and\n"
    "therefore such as the vulgar altogether fail to recognise.\n"
    "To such a judge and to his gracious attention I now dedicate this work, and\n"
    "to his"
     << std::endl;
  return s.str();
}

std::string str2() {
  std::stringstream s;
  s <<"What is mind? No Matter. What is matter? Never mind."<< std::endl;
  return s.str();
}


int main() {
  std::stringstream s(str1());
  s << str2();
  std::cout << s.str() << std::endl;
}

output:

What is mind? No Matter. What is matter? Never mind.
tion in the speculative
life has in the approval of an enlightened and competent judge a powerful
incentive to labours, the benefits of which are great but remote, and
therefore such as the vulgar altogether fail to recognise.
To such a judge and to his gracious attention I now dedicate this work, and
to his

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

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

Steven T. Hatton wrote:

> If the behavior I encountered is that which is specified in the Standard, I
> have to say, it seems contrary to reasonable expectations. This demonstrates
> the problem I encountered using gcc (GCC) 3.3.4 (pre 3.3.5 20040809):

<snip>

The output you get might be surprising, but it is consistent. You would
have had the same result if you had been dealing with fstreams.

Issue #45 touched directly on this:

     http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#45

See also this comp.lang.c++.moderated thread:

http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thread/c480e368f4b8598c

~Marc.

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

Marc Schoolderman wrote:

> Steven T. Hatton wrote:
>
>> If the behavior I encountered is that which is specified in the Standard,
>> I have to say, it seems contrary to reasonable expectations. This
>> demonstrates the problem I encountered using gcc (GCC) 3.3.4 (pre 3.3.5
>> 20040809):
>
> <snip>
>
> The output you get might be surprising, but it is consistent. You would
> have had the same result if you had been dealing with fstreams.

I suspect there is little hope of changing the situation.  Nonetheless, I am
curious to know of a common use of stringstream constructed by the
constructor taking a string argument and not passing ios_base:ate as a
second argument. I've provided an example of using stringstream in a
program where having the write pointer placed after the initializing
content is clearly useful.  I don't see much use for the behavior that
actually resulted from the program when I omitted the step of moving the
write pointer beyond the initial content.

> Issue #45 touched directly on this:
>
>      http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#45
>
> See also this comp.lang.c++.moderated thread:
>
>
http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thread/c480e368f4b8598c

I can't say that I agree with Dr. Stroustrup on all matters, but his
opinions are certainly worth consideration.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

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