Re: Curious question about the STL ostream
James Kanze wrote:
On Sep 9, 2:14 pm, Rolf Magnus <ramag...@t-online.de> wrote:
Alf P. Steinbach wrote:
I think it's just a design level error resulting from some misguided
principle that having them as members clutters the class interface.
A result is that if you do
(std::ostringstream() << "bah").str()
you'll probably invoke the member <<(void*) function (because a
temporary can't be bound to the reference argument in the free
functions), which produces the address of the "bah" string instead of
the characters.
The above doesn't work anyway, since operator<< returns a reference to
ostream, which doesn't have a member function str().
So you need a cast. Most of the time, you would be doing
something more along the lines of:
//! \pre message must in fact be an std::ostringstream
void f( std::ostream& message ) ;
// ..
f( std::ostringstream() << "bah" ) ;
with a dynamic_cast in f.
I wouldn't. If f expects an ostringstream, I would let it take a reference
to this type and not to ostream.
I agree that the behavior is quite unexpected. However, you'll
have the same problem with your own overloaded operators, and
it seems to me that temporary stream objects are hardly useful
anyway.
Unless you're abusing user defined conversions, you should get
an error with your own types.
Why should I get an error with those, but none with the standard types?
And historically, the work-around
for this error was:
ofstream( "text.txt" ) << "" << myType ;
The standard streams broke that idiom.
Still looks kind of hackish to me.
But logically, they all should be members; you don't want the stream
parameter to be the result of an implicit conversion.
Why not? And wouldn't that be basically the same with a member, expect that
it's not a parameter, but the this-pointer that is the result of an
implicit conversion?
So the classical iostream compromized: the pre-defined operators (those in
<iostream.h>) where members, and user defined operator could be
non-members.
Ok. This looks more consistent that it is now, but I don't think the
user-defined operators should be treated different from the pre-defined
ones.
The standard should have either left it this way, or made the
operator<< a template member function, without a generic
implementation, and with explicit specializations for all
types. (The user can provide an explicit specialization for
such a template member.)
This sounds better, since it would be the same for all types.