Printing a class

[Marcus Kwok]

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std:stream& operator<<(std:stream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std:stream& o);
};

std:stream& operator<<(std:stream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

 

[j0rd4n]

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std:stream& operator<<(std:stream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std:stream& o);
};

std:stream& operator<<(std:stream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

For the sake of convention, friend functions are tyically discouraged
as they break true encapsulation. In my opinion friend functions have
always felt like a hack. That is not to say there are appropriate
ways to use friend functions (and necessary times like overriding <<),
but it is always best to use OOP paradigms when possible. Using
print() as a class method maintains class encapsulation.

j0rd4n

 

[Gavin Deane]

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std:stream& operator<<(std:stream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std:stream& o);
};

std:stream& operator<<(std:stream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

I can't see any great benefit in the print function. It adds another
layer of indirection for no gain, avoiding the friend just for the
sake of it. Just doing it to avoid having to use a friend makes no
sense to me. friend is a code smell. That means that whenever you find
yourself using it, you should consider whether your design is correct.
But that is a completely different thing to saying "every time I want
to use a friend, I will mindlessly restructure the code until the
friend has gone away". In general, consider whether the friend really
*is* the best design and be prepared to accept that the amswer might
be "yes".

In this case I think the answer is yes. It's a fairly well known
idiom, necessary because operator<< can't be a member and the
alternative isn't superior in any way.

If you do decide to go with a print member function then it should
probably be a const member function.

Gavin Deane

 

[Kai-Uwe Bux]

For the sake of convention, friend functions are tyically discouraged

Maybe they are discouraged according to the local style/coding styles in
your shop/community. However, that is hardly a general recommendation.

as they break true encapsulation.

And this rational is misleading at best: C++ takes the approach that a class
defines its interface by specifying the meaning of expressions that objects
are part of (e.g., this best explains operator overloading). In particular,
non-member functions that take objects as parameters are part of the class
interface. Friend declarations do for non-members what access specifiers
(public, private, protected) do for members.

In my opinion friend functions have
always felt like a hack. That is not to say there are appropriate
ways to use friend functions (and necessary times like overriding <<),
but it is always best to use OOP paradigms when possible.

Putting OO programming above other programming styles is, again, a decision
that may make sense for your shop/community. It does, however, not really
generalize from there. Which programming style one should opt for very much
depends on the problem at hand and, maybe even more, on the local culture;
programs are meant to communicate intent to other programmers, so the
reading habits of your peers and their expectations heavily influence what
would be good practice for you. That can mean that most of your code ends
up being OO, but it can also mean that allmost all your code ends up being
heavily templated employing generic programming or policy based design.

Using print() as a class method maintains class encapsulation.

Not any better than a friend operator<<. This is what Stroustrup has to say
about friends and encapsulation:

http://www.research.att.com/~bs/bs_faq2.html#friend



Best

Kai-Uwe Bux

 

[Marcus Kwok]

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

Argh, sorry for the noise. This is answered in the FAQ, 15.8 and 15.9:
http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.9

However, Guru Sutter gives the opposite advice, based on James Kanze's
recommendation (but this article is rather old, 1997-03-07):
http://www.gotw.ca/gotw/004.htm
(number 6 in the Solution)

 

[Marcus Kwok]

For the sake of convention, friend functions are tyically discouraged
as they break true encapsulation. In my opinion friend functions have
always felt like a hack. That is not to say there are appropriate
ways to use friend functions (and necessary times like overriding <<),
but it is always best to use OOP paradigms when possible. Using
print() as a class method maintains class encapsulation.

After I posted, I found this in the FAQ:
http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.9

Regarding your statement about how friend functions break encapsulation,
the FAQ disagrees, and actually goes so far as to say that friends, when
used properly, actually *enhance* encapsulation:
http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2

 

[Marcus Kwok]

I can't see any great benefit in the print function. It adds another
layer of indirection for no gain, avoiding the friend just for the
sake of it. [snip]
In general, consider whether the friend really
*is* the best design and be prepared to accept that the amswer might
be "yes".

In this case I think the answer is yes. It's a fairly well known
idiom, necessary because operator<< can't be a member and the
alternative isn't superior in any way.

Thanks, after doing more research I found it in the FAQ, which agrees
with you. In fact, since I had been doing it this way, I must have
learned it from the FAQ, but forgot it was in there

If you do decide to go with a print member function then it should
probably be a const member function.

True, I just forgot when quickly typing up the post.

 

[Gavin Deane]

Thanks, after doing more research I found it in the FAQ, which agrees
with you. In fact, since I had been doing it this way, I must have
learned it from the FAQ, but forgot it was in there

I forgot it was in the FAQ too, otherwise I could have just pointed
you at it

Gavin Deane

 

[Jerry Coffin]

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g.,

class Foo {
int i;
public:
Foo() : i(0) { }
friend std:stream& operator<<(std:stream& o, const Foo& f);
};

However, I have seen people providing a separate public print() method,
then just calling that from operator<<:

class Foo {
int i;
public:
Foo() : i(0) { }
void print(std:stream& o);
};

std:stream& operator<<(std:stream& o, const Foo& f)
{
f.print(o);
return o;
}

Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

IMO, you should generally use a mixture of the two: a protected (and
perhaps virtual) member function, and a friend operator<< that uses the
member function.

This is particularly important if you're using inheritance. In that case
the member function is virtual. The friend function can't be virtual,
but it can invoke a virtual member function.

Though at one time I agreed with James Kanze's (old) advice about making
the print function public, I've changed my mind about that part --
having two different (visible) names that do exactly the same thing
isn't usually a good idea IMO. Redundancy is a minor evil, to be avoided
except when it provides real utility to justify itself.

 

[s5n]

If I have some class Foo, my standard way for printing it is to overload
operator<< as a friend, e.g., ....
Is there any technical reason why this method should be preferred over
the friend operator<<, assuming that I have complete control over Foo?

Shameless plug:

Another alternative is using libs11n, which allows you to non-
intrusively serialize your objects in a number of file formats without
requiring i/ostream operators for every type. Sometimes this is even
useful as a debugging tool, like:

std::map<int,std::list<double> > m;
... populate m ...
s11nlite::save( m, std::cout );

See: http://s11n.net

(Disclaimer: i wrote that software)

 

[Marcus Kwok]

IMO, you should generally use a mixture of the two: a protected (and
perhaps virtual) member function, and a friend operator<< that uses the
member function.

This is particularly important if you're using inheritance. In that case
the member function is virtual. The friend function can't be virtual,
but it can invoke a virtual member function.

Hmm, that does seem like a good compromise. In my work I usually don't
have to use inheritance very often, but for when I do, I will keep this
technique in mind.

Though at one time I agreed with James Kanze's (old) advice about making
the print function public, I've changed my mind about that part --
having two different (visible) names that do exactly the same thing
isn't usually a good idea IMO.

True, the FAQ makes the same argument.

 

[Marcus Kwok]

Hmm, that does seem like a good compromise. In my work I usually don't
have to use inheritance very often, but for when I do, I will keep this
technique in mind.

I also should have noticed that this technique is a little further down
the page on the FAQ as well

 

[liam_herron]

One thing I like to do is to create an "std::string asString() const"
method
that fills a string with the display of your class.

Regards
Liam Herron

 

[Jerry Coffin]

One thing I like to do is to create an "std::string asString() const"
method that fills a string with the display of your class.

I'd do that with operator<< and a stringstream.

 

[j0rd4n]

After I posted, I found this in the FAQ:http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.9

Regarding your statement about how friend functions break encapsulation,
the FAQ disagrees, and actually goes so far as to say that friends, when
used properly, actually *enhance* encapsulation:http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2

Kai-Uwe and Marcus,

I stand corrected. Thanks for the clarification.