Curious question about the STL ostream

[kevin]

Hello!

So I was reading O'Reilly's C++ in a Nutshell when I came accross
something interesting:

The class definition for basic_ostream contains numerous overloaded
operator<< functions:

template <class charT, class traits = char_traits<charT> >
class basic_ostream : virtual public basic_ios<charT,traits>
{
public:
....
basic_ostream<charT,traits>& operator<< (bool n);
basic_ostream<charT,traits>& operator<< (short n);
basic_ostream<charT,traits>& operator<< (int n);
....
etc.
}

which makes sense since these are used for statements like

cout << 45 << 34 << endl;

But the functions to output strings and characters are implemented as
function templates elsewhere and *not* as member function of
basic_ostream :

template<class charT, class traits>
basic_ostream<charT,traits>& operator<< (basic_ostream<charT,traits>&
out, char c);


template<class traits>
basic_ostream<char,traits>& operator<< (basic_ostream<char,traits>&
out, char c);

Could anyone shed some light on why the STL would implement these
functions as function templates and not as memebr functions of the
basic_ostream class? (I am probably missing something bigger here,
since I'm only a fairly intermediate C++ programmer and I don't know
the STL in depth).

thanks
-kevin

 

[Dave Townsend]

Hello!

So I was reading O'Reilly's C++ in a Nutshell when I came accross
something interesting:

The class definition for basic_ostream contains numerous overloaded
operator<< functions:

template <class charT, class traits = char_traits<charT> >
class basic_ostream : virtual public basic_ios<charT,traits>
{
public:
...
basic_ostream<charT,traits>& operator<< (bool n);
basic_ostream<charT,traits>& operator<< (short n);
basic_ostream<charT,traits>& operator<< (int n);
...
etc.
}

which makes sense since these are used for statements like

cout << 45 << 34 << endl;

But the functions to output strings and characters are implemented as
function templates elsewhere and *not* as member function of basic_ostream
:

template<class charT, class traits>
basic_ostream<charT,traits>& operator<< (basic_ostream<charT,traits>& out,
char c);


template<class traits>
basic_ostream<char,traits>& operator<< (basic_ostream<char,traits>& out,
char c);

Could anyone shed some light on why the STL would implement these
functions as function templates and not as memebr functions of the
basic_ostream class? (I am probably missing something bigger here, since
I'm only a fairly intermediate C++ programmer and I don't know the STL in
depth).

thanks
-kevin

I think the reason for using function templates is that you can extend the
functionality of the class
to user defined classes this way. That is, anybody can write a templated
function which will read/write their
special classes in/out of the stream . One cannot do this if the
implementation was done by member functions without modifying
the class. Very elegant design.

dave.

 

[Alf P. Steinbach]

* kevin:

Hello!

So I was reading O'Reilly's C++ in a Nutshell when I came accross
something interesting:

The class definition for basic_ostream contains numerous overloaded
operator<< functions:

template <class charT, class traits = char_traits<charT> >
class basic_ostream : virtual public basic_ios<charT,traits>
{
public:
...
basic_ostream<charT,traits>& operator<< (bool n);
basic_ostream<charT,traits>& operator<< (short n);
basic_ostream<charT,traits>& operator<< (int n);
...
etc.
}

which makes sense since these are used for statements like

cout << 45 << 34 << endl;

But the functions to output strings and characters are implemented as
function templates elsewhere and *not* as member function of
basic_ostream :

template<class charT, class traits>
basic_ostream<charT,traits>& operator<< (basic_ostream<charT,traits>&
out, char c);


template<class traits>
basic_ostream<char,traits>& operator<< (basic_ostream<char,traits>& out,
char c);

Could anyone shed some light on why the STL would implement these
functions as function templates and not as memebr functions of the
basic_ostream class? (I am probably missing something bigger here, since
I'm only a fairly intermediate C++ programmer and I don't know the STL
in depth).

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:stringstream() << "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.

Not sure, but I think this was corrected in C++0x; check the draft.

Cheers, & hth.,

- Alf

 

[john]

Hello!

So I was reading O'Reilly's C++ in a Nutshell when I came accross
something interesting:

The class definition for basic_ostream contains numerous overloaded
operator<< functions:

template <class charT, class traits = char_traits<charT> >
class basic_ostream : virtual public basic_ios<charT,traits>
{
public:
...
basic_ostream<charT,traits>& operator<< (bool n);
basic_ostream<charT,traits>& operator<< (short n);
basic_ostream<charT,traits>& operator<< (int n);
...
etc.
}

which makes sense since these are used for statements like

cout << 45 << 34 << endl;

But the functions to output strings and characters are implemented as
function templates elsewhere and *not* as member function of
basic_ostream :

template<class charT, class traits>
basic_ostream<charT,traits>& operator<< (basic_ostream<charT,traits>&
out, char c);


template<class traits>
basic_ostream<char,traits>& operator<< (basic_ostream<char,traits>& out,
char c);

Could anyone shed some light on why the STL would implement these
functions as function templates and not as memebr functions of the
basic_ostream class? (I am probably missing something bigger here, since
I'm only a fairly intermediate C++ programmer and I don't know the STL
in depth).

The I/O facilities of strings are presented in <string>. For the char
case you are mentioning TC++PL3 says:

"Surprisingly, there is no member >> for reading a character. The reason
is simply that >> for characters can be implemented using the get()
character input operations (21.3.4), so it doesn't need to be a member.
From a stream, we can read a character into the stream's character
type. If that character type is char, we can also read into a signed
char and unsigned char:


template<class Ch, class Tr>
basic_istream<Ch, Tr>& operator>> (basic_istream<Ch, Tr>&, Ch&);

template<class Tr>
basic_istream<char, Tr>& operator>> (basic_istream<char, Tr>&, unsigned
char&);

template<class Tr>
basic_istream<char, Tr>& operator>> (basic_istream<char, Tr>&, signed
char&);


From a user's point of view, it does not matter whether a >> is a member".

 

[Rolf Magnus]

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:stringstream() << "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(). However,

std:fstream("test.txt") << "bah";

writes the result you're describing into a file. It writes the address
instead of the string itself. There was a trick around that:

std:fstream("test.txt").flush() << "bah";

flush() can be called on a temporary, and it returns a reference, so this
will now write the string to the file. This is a nice quiz question for C++
programmers ;-)

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.

 

[Rolf Magnus]

I think the reason for using function templates is that you can extend the
functionality of the class to user defined classes this way.

You can still do that, even if the ones defined by the standard library are
all members.

That is, anybody can write a templated function which will read/write
their special classes in/out of the stream . One cannot do this if the
implementation was done by member functions without modifying
the class.

Why not? And why does the standard library implement a few ones as members
and the rest as non-members?

 

[James Kanze]

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:stringstream
void f( std:stream& message ) ;
// ..

f( std:stringstream() << "bah" ) ;

with a dynamic_cast in f.

However,

std:fstream("test.txt") << "bah";

writes the result you're describing into a file. It writes the
address instead of the string itself.

Note that this changed with the standard iostream. In the
classical iostream, the operator<< for a char const* was a
member.

There was a trick around that:

std:fstream("test.txt").flush() << "bah";

flush() can be called on a temporary, and it returns a
reference, so this will now write the string to the file. This
is a nice quiz question for C++ programmers ;-)

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. And historically, the work-around
for this error was:

ofstream( "text.txt" ) << "" << myType ;

The standard streams broke that idiom.

Like Alf, I think that there is a design level error. The
classical iostream couldn't make everything a member, since the
user defined conversions couldn't be members. (There were no
member templates at the time.) But logically, they all should
be members; you don't want the stream parameter to be 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.
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.)

 

[Rolf Magnus]

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:stringstream
void f( std:stream& message ) ;
// ..

f( std:stringstream() << "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.

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.

 

[D. Susman]

The answer to why these methods have not been implemented as member
functions is because the more a class has member functions, the less
encapsulated it is (Scott Meyers has an article on this ). The public
interface of a class is determined as its member functions + non-
member functions operating on that class.

One may not always have access to the source code of a big,
operational class. As requirements change and new functionalities
become necessary, one may code the new requirement as a non-member
function which is still a part of the interface of the class. Doing so
extends the functionality of the class without accessing the class
file. You write a function whose first parameter is that operational
class and simply get along the way.

This approach may sound freakish to the orthodox of Object Oriented
design, but it introduces a certain amount of flexibility and class
with designs fewer member functions.

 

[James Kanze]

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?

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.

Still looks kind of hackish to me.

It is. It just happened to be a widespread hack that everyone
knew and used.

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.

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.)

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]

The answer to why these methods have not been implemented as member
functions is because the more a class has member functions, the less
encapsulated it is (Scott Meyers has an article on this ). The public
interface of a class is determined as its member functions + non-
member functions operating on that class.

Yes and no. Part of the encapsulation of ostream is that <<
will work for any type which chooses to support it; i.e. the
class is intentionally open in this respect. In this case, the
choice of member or non member has been done very arbitrarily;
ideally, we'd like for all of the << operators to be members,
because this would result in the access rules we want. Ideally,
we don't want user defined operator << to be members, because
this would give them access to the internals of the class, but
in practice, given that it's an abstract base class, and that
all of the "documented" internals are available anyway, I don't
think that it's a real issue.

Of course, the standard could also have taken the point of view
that all of the << operators should be non-members. None of
them ever need access to the internals of the class. In this
sense, they really are an example of what Scott was talking
about. On the other hand, the conditions under which the
non-members can be called is less than ideal. (This would still
have been preferable to the current mix.)

One may not always have access to the source code of a big,
operational class. As requirements change and new functionalities
become necessary, one may code the new requirement as a non-member
function which is still a part of the interface of the class.

Declaring the functions as template members makes user defined
specializations possible.

Doing so extends the functionality of the class without
accessing the class file. You write a function whose first
parameter is that operational class and simply get along the
way.

This approach may sound freakish to the orthodox of Object
Oriented design, but it introduces a certain amount of
flexibility and class with designs fewer member functions.

It was, IMHO, a compromize based on many things, a lot of which
have since changed. The standard committee, by maintaining the
dicotomy, but changing the category of one of the types (char
const*), made a gratious change, for no good reason. Had they
made everything a member, using a template member function to
allow user defined specializations, or everything a non-member,
one could argue that the change at least improved coherence. As
it is, it was just an arbitrary means of breaking some existing
programs.