On 17 Sep 1998 20:40:57 GMT, sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
wrote:

>On Thu, 17 Sep 1998 20:35:49 GMT, David Harmon <source@netcom.com> wrote=
:
>
>> string first, middle, last;
>> stringstream(name) >> first >> middle >> last;
...
>which results in an error, "temp 'stringstream(name)' used in call to
>op>>(...)".

Well, er, uhm, I HATE THAT RULE!  Caught by it again.

As far as I am concerned, the example I posted is entirely reasonable
and legitimate.  The mouldy old compiler I presently use accepts it
(except I am using strstream) without a problem.  The C++ committee made
a change which breaks my existing code, for no good reason that I am
aware of.  I will restrain myself from disparaging remarks about the
morals and ancestry of whoever thought of that rule, but I really wish
they had left well enough alone.

All it takes to fix it is to break it up into two statements and name
the stream:
 {  // limit scope of temporary stringstream
        stringstream i_really_dont_need_this(name);
        i_really_dont_need_this >> first >> middle >> last;
    }
, which is semantically identical, but avoids the conflict with the
silly rule.  It remains a mystery to me, why it is supposed to be a
better idea than the simpler form.  Stroustrup hints (=A710.4.10, =A75.5)
that there is some problem due to modifying the temporary that is soon
to disappear, but it _cannot_ disappear before I am done with it, by the
"end of full expression in which it appears" rule.  If it should not be
modified or should not be bound to a non-const reference, it would have
been const.  That is what const is for.  So, what is the problem?



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 18 Sep 1998 19:51:17 GMT, David Harmon <source@netcom.com> wrote:
>On 17 Sep 1998 20:40:57 GMT, sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)

>>> string first, middle, last;
>>> stringstream(name) >> first >> middle >> last;

>>which results in an error, "temp 'stringstream(name)' used in call to
>>op>>(...)".


>Well, er, uhm, I HATE THAT RULE!  Caught by it again.

In general, it is a good rule.  Passing non-const temps to functions
is usually indicative of a design flaw -- you're modifying a
temporary, but the temporary is going to be promptly destroyed.  So
the changes made to it were pointless.  Of course, we could declare
all the variables in the object mutable and pass the object by const
reference, but this is just plain evil.  So as I see it, the rule is
there just to help us from making mistakes.

The use of the temp stringstream above is probably legitimate because
we don't care about any changes to the stringstream.  The iostate of
the stringstream might change, but who cares?  We're only using the
stringstream for the side effects it performs.  But the compiler
can't assume this.  It must assume that we truly care about the
iostate inside the stringstream, or whatever.  That's why it gives a
warning or error.


>All it takes to fix it is to break it up into two statements and name
>the stream:
> {  // limit scope of temporary stringstream
>        stringstream i_really_dont_need_this(name);
>        i_really_dont_need_this >> first >> middle >> last;
>    }

Another solution:

struct temp_ostringstream
{
     private:
          mutable std::ostringstream strm;

     public:
          temp_ostringstream(std::string s=std::string()) : strm(s) { }
          std::string str() const { return strm.str(); }

          template <class T>
          temp_ostringstream& operator<<(const T& obj) const
          {
               strm << obj;
               return *this;
          }
};


We put the most important funcs in the interface of temp_ostringstream.
Some things don't work, but that's ok.

temp_ostringstream k;

k.setf(ios_base::left); // error
   // we should use "k<<std::left" anyway, which turns ios_base::right off

k.imbue(...); // error
   // if we need to set the locale, we should do this in the ctor of
   // temp_ostringstream

k.write(...); // error
   // we shouldn't be using this func anyway


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn705evq.gv.sbnaran@fermi.ceg.uiuc.edu>,
Siemel Naran <sbnaran@KILL.uiuc.edu> wrote:
>The use of the temp stringstream above is probably legitimate because
>we don't care about any changes to the stringstream.  The iostate of
>the stringstream might change, but who cares?  We're only using the
>stringstream for the side effects it performs.  But the compiler
>can't assume this.  It must assume that we truly care about the
>iostate inside the stringstream, or whatever.  That's why it gives a
>warning or error.

If this idiom appears frequently enough, it suggests that the
second-guessing by the language is inappropriate.  A common programming
need, such as "don't care" output variables, should not be defined to be an
error by the language specification.  Warnings are OK if they can be
disabled with compiler options, although it's not really the standard's
place to specify this.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]