Re: Curious question about the STL ostream
On Sep 10, 6:18 am, Rolf Magnus <ramag...@t-online.de> wrote:
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.
And force the dynamic_cast on the user? Conceptually, you're
100% right, of course, but pragmatically?
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?
Because if you don't abuse user defined conversions, the set of
callable member functions will be empty. And since the
non-member functions would all require binding the temporary to
a const reference, it will be empty as well. The unexpected
resolution we see in Alf's example is due to the fact that the
desired overload is a non-member, but the type being passed can
be converted to match a member. And since there is a member
function which can be called, overload resolution picks it,
rather than resulting in an error.
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.
It is. It just happened to be a widespread hack that everyone
knew and used.
But logically, they all should be members; you don't want
the stream parameter to be the result of an implicit
conversion.
Why not?
Because streams are types with identity, not value types. An
implicit conversion implies a copy somewhere, and streams the
semantic of streams does not support copy.
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?
The rules concerning acceptable conversions for calling a member
function are different than those for initializing a reference.
Traditionally, the usual rule for operators has been that
operators which modify the left hand side are members; operators
that don't are global functions. Since operator<< (on a stream)
modifies the left hand side, one "expects" it to be a member.
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.
I agree. On the other hand, when iostream was designed, member
templates didn't exist. In fact, templates didn't exist. Jerry
Schwarz had to make do with what he had. Globally, although
it's certainly not perfect (particularly with regards to some of
the names, and error handling in general), I think he did a
pretty good job. Starting from scratch today, with today's
language, and the performance of today's machines and compilers,
he'd doubtlessly do a few things differently, or at least I
would. I think, for example, that I would make operator<< and
operator>> a member template, so that it would always be a
member. (Although to be frank, I'd have to experiment a little
with this first. I rather fear that it could have troublesome
consequences on overload resolution, since many conversions
would no longer be considered. Given rvalue references, I'm not
sure that using global functions taking an rvalue reference
would be a better solution. But I lack enough concrete
experience with rvalue references to really judge.)
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.
I like it better, too, but I tend to avoid implicit conversions
like the plague. I'm not sure about its consequences in cases
where the user is counting on an implicit conversion for output
to work, however.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34