friend function

[Muting]

Hi,

I have a question when learning the inheritance property in C++.

I have a base class, say Parent, and a derived class, say Child. I declared a function to be the friend function of Parent, and I also want to keep the function's name and just change its content in Child. Should I need to declare the function as friend function in Child again?

Thanks

Muting

 

[Vic_Siqiao]

friend function cannt be inheritated. i think a virtual friend function may work well.

 

[Muting]

friend function cannt be inheritated. i think a virtual friend function may work well.

I seems not, because if we define virtual, we need to define the two functions in different namespaces. But if we define a function as friend, how do you differentiate them in different classes?

 

[SteveTownsend]

The friend of Parent is by necessity globally-scoped (or you could not make it a friend) and so defining any other potential friend of Child with the exact same name will cause a "double definition of <name of friend>" error at link time.

I am curious about the problem you are trying to solve by defining this friend of Parent. Typically, friend is a warning sign that your design might be sum-optimal, since it breaks encapsulation - effectively you are making stuff visible to Parent that the designer of the friend function intended to be invisible.

 

[Muting]

The friend of Parent is by necessity globally-scoped (or you could not make it a friend) and so defining any other potential friend of Child with the exact same name will cause a "double definition of <name of friend>" error at link time.

I am curious about the problem you are trying to solve by defining this friend of Parent. Typically, friend is a warning sign that your design might be sum-optimal, since it breaks encapsulation - effectively you are making stuff visible to Parent that the designer of the friend function intended to be invisible.

Steve:

I didnt realize that using "friend" is an inferior way to do programming(actually, I use friend function to overload the binary operator when setting up the matrix class ). I also talked to Alain this evening about the problem of using friend.

In fact, I want to set up two kinds of bonds. One is the continuous compounded bond, the other is the discrete compounded bonds. Continuously compounded bond is the base class, and discretely compounded bond is the derived class.(I know, this setting in logic is not appropriate. I should use the virtual base class but I still havent learnt it) And I want to set up a nonlinear solver like do_newton as a friend function to the both classes.

Muting

 

[SteveTownsend]

You're right, this approach really is a bit counter-intuitive. Inheritance is typically used to model an "is-a" relationship.

You could consider defining a single bond object that "has-a" compounding type. Then a given bond could be parameterized using either continuous or discrete compounding, allowing you to price the same bond object for different compounding types.

I would not say that friend is inherently inferior. Every language feature has its place. This is just one you don't want to proliferate just to make the code work. Always think about whether this really means your design needs to change, because design changes are much easier to make upfront than down the line after writing a lot more code, when you realise it's really busted.

 

[DominiConnor]

Inheritance is for 2 sorts of a "is a" relationship.

The first is when you are specialising or generalising.
As in:
A Bond is an Instrument, and a European is an option
But an option on an equity is not an equity.
So an equity object might be a member of an option class, but not a base.

Then there is the other way up.
A probability is a real, but only a subset of them.
A bond default has a probability, but is not a kind of probability.

There is also "implemented in terms of". This might best be thought of as a wrapper class.
If you are using someone else's libary, you may well have horrible data structures that you want to isolate from the rest of your code.
An example might be a class which has an old-style C array as a member with no array bound checking. You could derive from it and add bound checking without breaking much code.

Friends often come up in operator overloading where to make the functions members can get painful.
Also again they are useful in interfacing.
Many libraries require that you give them a function for the library to call when it has some data to give you, or some event has occurred. This is common in data feeds for instance.
The functions to start threads require that you give them a function to "call" to start the thread in.

These types function must have exactly the types of parameters that they require, esle they crash horribly.
However member functions get passed a this pointer, even though it does not appear in the parameter list. That means 4 (or 8) bytes are put on the stack, meaning that member functions cannot be used for this. So if you want them to work closely with a class, then a friend is the way forward.
It is also useful occasionally when you have to do dark magic in getting Excel talking to C++ in unusual ways.