Why we make a function friend in c plus plus?

Answer 1

A "normal" function is just a function. Even a friend function is just a normal function. However, when a class declares an external function or an external class method to be a friend of the class, the friend function gains access to the private members of the class.

class foo {

friend void bar(foo&);

int m_data;

};

void bar(foo& f)

{

f.m_data=42;

}

In the example above, the foo class declares the bar function to be a friend function. As such, the bar function has unrestricted access to the private members of foo. In this case, foo::m_data is private (by default) and would therefore be inaccessible to bar were it not declared a friend of foo. Other than that, the bar function is no different to any other function.

Note that you cannot declare friendship from outside of a class. The class itself must declare its own friends. However, the same function can be declared friends in more than one class, which can be a useful feature when two or more classes work closely together, as the friend function can be used to provide the "glue" that binds them together.

Answer 2

Declare and define the function as normal. Then declare the function prototype as a friend in the class declaration. Friends can be declared anywhere in the class declaration (private, protected or public sections), as access specifiers are irrelevant to friends -- they automatically have privileged access to all the private and protected members.

// friend function declaration

void foo(bar & object);

// class declaration

class bar

{

private:

int m_int;

friend void foo(bar & object);

};

// friend function definition

void foo(bar & object)

{

// friend functions have privileged access to private members.

object.m_int=10;

}

Answer 3

You declare an external operator function whenever the lvalue (the value to the left of the operator) is anything but a reference to the actual instance of the class. However, there is never a good reason to declare external operator functions as being friends of the class.

The following is a fairly common example of declaring an external friend function for no good reason:

class MyObject

{

// ... other declarations omitted for brevity.

public:

friend std::ostream& operator<< ( std::ostream &os, const MyObject &obj );

int GetID() const { return( m_ID ); }

private:

int m_ID;

};

// External function:

std::ostream& operator<< ( std::ostream &os, const MyObject &obj)

{

os << obj.m_ID;

return( os );

}

The only reason this external function is declared a friend at all is because it requires private access to the class. But there's a perfectly good public accessor that it can use instead:

// External function:

std::ostream& operator<< ( std::ostream &os, const MyObject &obj)

{

os << obj.GetID();

return( os );

}

The function no longer needs private access and therefore no longer needs to be declared a friend of the class.

Any external operator function that requires private access to a class is a clear indication that there is something fundamentally wrong with the design of that class.

Purists will argue that friends undermine encapsulation, however this is errant nonsense. Friends simply extend the interface of a class, nothing more. All instances of a class are automatically friends of each other and are therefore granted unrestricted access to each other's private members. The only difference is that external functions must be specifically granted that privilege and there must be a valid reason for doing so. But in the case of operator functions, there is never a valid reason. If the public interface is insufficient to meet the needs of the operator, then there is clearly something wrong with the interface, or there is no need for the operator in the first place.

Answer 4

Member functions have a this pointer, are scoped to the class and have private access to the class representation. Static member functions have the last two properties only. Friend functions have the last property only. In other words, we use a friend function if (and only if) a non-member function explicitly requires private access to the class representation.

A non-member function does not require private access if it can make use of the public interface but in some cases private access may allow the non-member function to be implemented more efficiently.

Note that although friend functions are non-member functions, they are still considered part of the class interface and must ensure the class invariant holds upon returning from the function, just as any member function must.

It is often claimed that friend functions undermine encapsulation, however this is errant nonsense. If friend functions were not permitted, then we'd have to provide a public interface specifically for those functions, but we'd have no way to prevent other non-member functions from accessing that same interface. And that has far greater potential for undermining encapsulation than explicitly limiting private access to a specific non-member function.

Answer 5

A friend function in C++ is a function that has privileged access to the members of a class that would normally not be granted by virtue of them being private or protected.