Question about the "friend" keyword

[globos]

Hi C++ guys,

I tried to use the friend keyword, and I found out a limitation in using it that is not really justified :

Look at the classes below :

class A //foo class
{
private:
A_routine ();
friend class B;
}

class B; //another foo class

class B1 : public B
{
private:
A a;
public:
B1_routine ()
{
a.A_routine ();//this leads to a compilation error
}
};

class B2 : public B;
...
class Bn : public B;


In this basic example, although B1, B2, ... inherit from B, B1, B2, ... are not considered as friends of class A.
I do not understand why the designers of C++ make this choice, if every heirs of B need to be friends of class A, it forces the programmer to declare all of them as friends of class A. It then makes class A aware of all the class hierarchy of B, which breaks the rule that a class should not have knowledge of all the heirs of another class.
The compiler I used is the one of VC++ 6.0, but I think the problem is the same for the other.

Does someone know the reason behind that?

--
Globos

 

[chipperMDW]

// your code

class Secure
{
    friend class SecurityHole;

  private:
    // some stuff that MUST be manipulated
    // through the public interface, or the
    // program will have undefined behavior
};

class SecurityHole
{
};




// programmer using your code

class SecurityBreach : public SecurityHole
{
    // mess with a Secure object's private data
};

So no, that would be an undesirable feature. Probably not the only reason for excluding it, either.

private is an access control mechanism, not a security mechanism; the names were just to make the intent clearer. This kind of situation would probably come about by accident rather than through "malicious" programming.


Also, note that friendship is a property of functions, not of classes. Declaring a class to be a friend is shorthand for declaring all its member functions to be friends. Since it's not a property of the class, how would it make sense to inherit it?

 

[palbano]

Globos, I have never read any explanation for this specific subject but it seems illogical to me.

Also the design of your example is poor since class B does not encapsulate it’s use of A. What follows makes much more sense from a design perspective and it works.

class B;
class A{
private:
	friend B;
	void foome(){
		cout << &quot;foo::foome&quot; << endl;
	};
};
class B{
private:
	A _myA;
protected:

	void dofoome(){
		_myA.foome();
	}
};

class B1 : public B{
public:
	void B1_foo(){
		dofoome();
	}
};

-pete

 

[globos]

Concerning what explained chipperMDW, I totally agree if we consider how friendship is designed in C++. As he said friendship is related to routines, certainly because there is need to satisfy some behaviour with C style code.
This is really too bad, I see the C++ friendship as a way to approach the export mecanism as provided by Eiffel, but not in a selective manner(all the private features are exported in C++).
What described palbano allows to solve the problem of my origin message. And thanks to the wrapping of the interesting features, it can also emulate partially the selective export mecanism of Eiffel, but only to the heirs of class B. class B has still full access to all the private features of class A.

--
Globos