inheriting friend

class A
{    public :
      //
        friend    [ReturnType]       fn(..) {...}
...
}

class B : public A
{
  //
}

now the question-

will  fn(...)  be a friend of class B ?


i know " friendship is not inherited or transitive "
(i.e)   u may be my friend but i will not trust ur friends or kids.

here the question is  "can i trust my father's friends ?"
abyAsked:
Who is Participating?
 
nietodCommented:
I'm answering for the moment.  But Yonat was here first and could have provided all the information I did (and then some)  I was just filling in her absence so you didn't have to wait.  You might want to consider giving her the points (the choice is yours), by rejecting my answer and waiting for her to submit one.
0
 
yonatCommented:
> will  fn(...)  be a friend of class B ?

No.

> here the question is  "can i trust my father's friends ?"

This is a different question ("*should* fn() be a friend of B)?") and depends on your specific context.
0
 
abyAuthor Commented:
thanx for the response

ref : answer from yonat

>here the question is  "can i trust my father's friends ?"    
>
>This is a different question ("*should* fn() be a friend of B)?") and depends on your
>specific context.

  can u explain  on this more? (of course u understand by' trusting father's friend ' i meant 'the friend function of parent being a friend of the subclass also' )

>'depends on the context' -
   more info please on the context part

whatz the case when doing Virtual Friend function idiom .please refer

http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/friends.html#[14.3]



0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
nietodCommented:
In the above example, fn is a friend of class A so it can access the private members of an A object.  Ussually this would be to access the private members of an A object that is passed in the parameters.  Since class B is derived from class A, fn() can also access the private members of the A part of an object of class B.  Thus fn(), in a sense, is also a friend of class B.  Now  it can't access private members of class B that are not part of class A.  

However, that doesn't usually matter.  Ussually a function is written with a particular class in mind and can handle classes derived from that particular class, but doesn't need to know anythign about the derived class.  Thus if additional private members were added to B it doesn't care, because it really only works with A's.
0
 
abyAuthor Commented:
that cleared my doubts wonderfully.thanx.

i would greatly appreciate if anybody can comment on this.
 does it make any difference if
 a friend function is defined in public:/private?

also (ref :response from nietod)
>private members of the A part of an object of class B
does a B object do always contain all of A's members (be it private also) but only they cannot be accessed by the member functions of B.
and...does it differ in cases where B is derived private/protected/ B has a A

and please comment on the case of  Virtual Friend Function Idiom.please  ref.
http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/friends.html#[14.3]

0
 
nietodCommented:
>> does it make any difference if a friend function is defined in public:/private?
Nope.

>>does a B object do always contain all of A's members (be it private also)
>>but only they cannot be accessed by the member functions of B. and...
>>does it differ in cases where B is derived private/protected/ B has a A

With data members (not member functions) A dirived class will always contain all of its base class's data members, whethor or not the members are public or private, and whethor or not the derivation was public or private.  A derived class IS the base class plus additional members (maybe-- there don't have to be additional ones but the base ones must be there.)

The way this is usually (always, really) implimented is that in memory an object of the the derived class begins with the exact same members as the base class, then it is followed in memory by any additianal members declared by the derived class.  Thus the derived class object has the same format in memory as the base class object, except it is followed by additional data.
0
 
abyAuthor Commented:
thanx nietod.that was great.

will appreciate if i can know where can i get the info on the like given on how an object is stored.

and can u coment on how it works in this. (Virtual Friend Function Idiom)

class Base {
    public:
      friend void f(Base& b);
      // ...
    protected:
      virtual void do_f();
      // ...
    };
   
    inline void f(Base& b)
    {
      b.do_f();
    }
   
    class Derived : public Base {
    public:
      // ...
    protected:
      virtual void do_f();  // "Override" the behavior of f(Base& b)
      // ...
    };
   
    void userCode(Base& b)
    {
      f(b);
    }

where i got this (url above)it's said like this.

The statement f(b) in userCode(Base&) will invoke b.do_f(), which is virtual. This means that Derived::do_f() will get control if b is actually a object of class Derived. Note that derived overrides the behavior of the protected: virtual member function do_f(); it does not have its own variation of the friend function, f(Base&).

OK now if the Derived: do_f() accesses the privete members of B (or is that the thing intended)and  why is "virtual" used in Derived? ( is it to allow it's children also to go in the same fashion)

0
 
abyAuthor Commented:
Adjusted points to 50
0
 
nietodCommented:
>> will appreciate if i can know where can i get the info on the like given on how an object is stored

Three sources that deal with it from time-to-time (not the focus) are BjarneSroustrup's "The C++ Programming Language"  and Scott Meyer's "Effective C++" and "More Effective C++" books.  These three books are manditory reading!  No programmer should be without them.  (They are not introductory level, they assume some knowledge of C++, but you are porabalby at or close to that point.)

I'm not 100% sure what your other question is asking about.  To avoid a lengthy explanation on topics you understand,

Do you know what a virtual function is?
Are you only asking why is the "virtual" keyword mentioned in the derived class's do_f()?
0
 
abyAuthor Commented:

>     Do you know what a virtual function is?
sure
>     Are you only asking why is the "virtual" keyword mentioned in the derived class's
     do_f()?

exactly.(as i understand "virtual" need be used in base class only)



0
 
nietodCommented:
Right.  It only NEEDS to be.  But there is no harm in specifying it in a derived class (it makes no difference at all).  It is a good habit to do so, though, that way if someone looks at the definition of the derivided class they can know the function is virtual without having to look back at the base class.  

Note thatt once a function is virtual, it will always be virtual in all derived classes.  You can't "turn it off".
0
 
abyAuthor Commented:
thanx .that was great.the points are yours.
0
 
abyAuthor Commented:
sorry .had been out for quite some time
points are yours nietod.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.