I would like to know what is the rational behind the fact that protected members
are accessible to a friend class but not to the derived classes of the friend
class. I know the argument for private members but I cannot find any satisfying
answer for protected members.

The following example should convince you that such a prohibition is useless.


class Toto{
friend class Base;

protected:

 int member;

};

class Base{

public:

 int f( Toto* t ){ return t->member;}

};


class Derived:public Base{

public:

 int g( Toto* t ){ return t->member; } //illegal Derived not a friend of
      //Toto
};



Now, just add this:

class DerivedToto: public Toto{

friend class Derived;

};

and change Derived to this:

class Derived: public Base{

public:

 int g( DerivedToto* t ){ return t->member;} //now legal
};


What does this exemple show?

  It shows that without having access to the interface of class
Toto, you can access its protected member. So what is the use to make it
inaccessible for derived classes from its friends. Notice that I could have done
the same thing without deriving Derived from Base. But in that case, I think it
is reasonable to have to make some efforts ( by deriving from class Toto ) to
access it.

Any comment are welcome via e-mail.

 Thanks.

bouaziz@asterix.enpc.fr (Laurent BOUAZIZ) writes:

>I would like to know what is the rational behind the fact that protected members
>are accessible to a friend class but not to the derived classes of the friend
>class. I know the argument for private members but I cannot find any satisfying
>answer for protected members.

>The following example should convince you that such a prohibition is useless.

The general rule is that (as in life) friendship may only be granted.
It is not inherited (your father's friends might not like you), nor
can it be taken by force (love me or I'll break your arm).

Without commenting on the specific example, let us note that many
language rules can be worked around.  This does not change the
reason for the general rule, nor does it mean that the work-around
is a good programming practice.
--

Steve Clamage, TauMetric Corp, steve@taumet.com