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]

"kevin" <li********@graffiti.netwrote in message
news:2007090823452416807-lichking20@graffitinet...

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

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

Cheers, & hth.,

- Alf

[john]

kevin wrote:

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

std::ofstream("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::ofstream("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]

Dave Townsend wrote:

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]

On Sep 9, 2:14 pm, Rolf Magnus <[e-mail]:

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.

However,

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Rolf Magnus]

James Kanze wrote:

On Sep 9, 2:14 pm, Rolf Magnus <[e-mail]:

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

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