However shouldn''t i always use a printon() method instead , C/C++ Programming

Q: however shouldn't I always use a printOn() method instead of a friend function?

A: No.

The usual cause people wish to always use a printOn() method instead of  a friend function is since they wrongly believe that friends violate encapsulation and/or that friends are wicked. These beliefs are wrong and naive: while used properly, friends can in fact enhance encapsulation.

It is not to say that the printOn() method approach is never useful. For instance, it is useful while providing printing for whole hierarchy of classes. However if you employ a printOn() method, normally it should be protected, not public.

For wholeness, here is "the printOn() method approach." The proposal is to contain a member function, frequently called printOn(), that does the definite printing, then have operator<< call that printOn() method. While it is done wrongly, the printOn() method is public so operator<< doesn't ought to be a friend it can be a simple top-level function which is neither a friend nor a member of the class. some sample code following:

#include class Fred {


void printOn(std::ostream& o) const;




// operator<< can be declared as a non-friend [NOT recommended!]

std::ostream& operator<< (std::ostream& o, const Fred& fred);

// The real printing is done inside printOn() method [NOT recommended!]

void Fred::printOn(std::ostream& o) const




// operator<< calls printOn() [NOT recommended!]

std::ostream& operator<< (std::ostream& o, const Fred& fred)

{ fred.printOn(o); return o;


People assume wrongly that this decrease maintenance cost "since it ignore having a friend function." It is a incorrect supposition because the following:

The member-called-by-top-level-function approach contains zero benefit in terms of maintenance cost. Let's say this takes N lines of code to do the real printing. In the case of a friend function, those N lines of code will contain direct access to the class's private/protected parts which means whenever someone modify the class's private/protected parts, those N lines of code will have to be scanned & possibly modified, which enhance the maintenance cost. Though using the printOn() method doesn't modify this at all: we still contain N lines of code which have direct access to the class's private/protected parts. Therefore moving the code from a friend function in a member function does not decrease the maintenance cost at all. Zero reduction. No advantage in maintenance cost. (If anything it's a bit worse along with the printOn() method as now you have more lines of code to maintain as you have an extra function that you didn't contain before.)

The member-called-by-top-level-function approach makes the class difficult to use, specifically by programmers who are not also class designers. The approach exposes public method that programmers are not imagined calling. While a programmer reads the public methods of the class, they'll notice two ways to do the similar thing. The documentation would have to say something like, "precisely it does the similar as that though don't use this; instead use that." & the average programmer will say, "Why make the method public if I'm not likely to use it?" In reality just one cause the printOn() method is public is to ignore granting friendship status to operator<<, and that is a notion i.e. somewhere among subtle and incomprehensible to a programmer who simply wished to use the class.

Net: the member-called-by-top-level-function approach has a cost however no benefit. Thus it is, in general, a bad idea.

Note: if the printOn() method is private or protected, the second objection doesn't apply. There are cases while that approach is reasonable, such as while providing printing for an whole hierarchy of classes. Note down also that while the printOn() method is non-public, operator<< needs to be a friend.


Posted Date: 3/20/2013 8:15:03 AM | Location : United States

Related Discussions:- However shouldn''t i always use a printon() method instead , Assignment Help, Ask Question on However shouldn''t i always use a printon() method instead , Get Answer, Expert's Help, However shouldn''t i always use a printon() method instead Discussions

Write discussion on However shouldn''t i always use a printon() method instead
Your posts are moderated
Related Questions
Project Description: We want to generate premium numbers for one of our application. What we need is: A program that generate 2, 3, 4, 5, 6, 7, 8 digits premium numbers

#include stdio.h> #include conio.h> #include string.h>   void del(char[],char *); main() {           char str[30],ch,*pp;           clrscr();           p

Prepare an iPad application Clash of Clans like game I would like to prepare a free city building app with the in app purchase possibility. An example game could be Clash of Cla

I have a program for school and I am not understanding why one of the variables gets skipped or the arithmetic operators aren''t having any effect as I have tryed defining it sever

A palindrome is a string that reads the same from both the ends. Given a string S convert it to a palindrome by doing character replacement. Your task is to convert S to palindrome

Objective: Construct a C program that controls the UART, and is capable of displaying strings. Echo characters received on the UART to the LCD screen Outcome: A mess

Write a program to find the area under the curve y = f(x) between x = a and x = b, integrate y = f(x) between the limits of a and b. The area under a curve between two points can b

A: Use operator overloading to present a friend left-shift operator, operator #include class Fred { public: friend std::ostream& operator ... private: int i_; // onl

Write a function that computes f(x) for a quadratic polynomial in x, such as the one in assignment 3. Use the function to plot f(x) from -10 to +10.