• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

friend function

Muting

Muting

Joined
12/23/06
Messages
187
Points
28
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
 
friend function cannt be inheritated. i think a virtual friend function may work well.
 
Vic_Siqiao said:
friend function cannt be inheritated. i think a virtual friend function may work well.
Click to expand...

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?
 
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.
 
SteveTownsend said:
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.
Click to expand...

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
 
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.
 
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.
 
Back
Top