C++ inheritance and overloading, calling a base method once overloaded

Question

Currently I have a class which contains another and provides a wrapper for some of its methods and provides others intact:

class bar {
public:

    int calculate1(int a, int b) {
        return f.calculate1(a, b);
    }

    int calculate2(int a, int b) {
        a ++;
        b ++;
        return f.calculate2(a, b);
    }

private:
    foo f
}

Where foo is a class containing 2 methods calculate1 and calculate2, both taking 2 ints and returning an int.

Is there a better way to achieve this with inheritance? It would be nice to be able to get rid of this:

    int calculate1(int a, int b) {
        return f.calculate1(a, b);
    }

But this would need to call the very function it is overloading, and I'm not sure how to do that:

    int calculate2(int a, int b) {
        a ++;
        b ++;
        return f.calculate2(a, b);
    }

Is it even possible or advisable? Is there another method to be used in this situation?

apologies if some of my code is a bit dodgy, as you can tell I'm a bit new to C++, but I hope I got the message across.

I'm asking how a similar effect would be achived using inheritance — jayjay, Aug 13 '14 at 09:15

score 3 · Answer 1 · answered Aug 13 '14 at 09:16

3

To call a base class method, use qualification:

return foo::calculate1(a, b);

Remember to ensure that your base class methods are virtual if you want them to be called polymorphically.

answered Aug 13 '14 at 09:16

ecatmur

152,476
27
293
366

thanks, do you think this is preferable to composition? – jayjay Aug 13 '14 at 09:18
@jayjay in this case, it may be; if you're unsure about the decision, I'd recommend reading http://programmers.stackexchange.com/questions/134097/why-should-i-prefer-composition-over-inheritance – ecatmur Aug 13 '14 at 09:23

score 2 · Answer 2 · answered Aug 13 '14 at 09:17

2

It possible via this way:

class bar : public foo {
public:

    int calculate2(int a, int b) {        
        return foo::calculate2(a+1, b+1);
    }
};

answered Aug 13 '14 at 09:17

SKi

8,007
2
26
57

score 0 · Accepted Answer · edited May 23 '17 at 12:05

1.Is there a better way to achieve this with inheritance?`

Of course!

//sg
#include<iostream>
class foo {
public:
    int calculate1(int a, int b) {
        return a * b;
    }

    int calculate2(int a, int b) {
        a ++;
        b ++;
        return a + b;
    }

};
class bar: public foo {
public:

    int calculate1(int a, int b) {
        return foo::calculate1(a, b);
    }

    int calculate2(int a, int b) {
        a++;
        b++;
        return foo::calculate2(a, b);
    }
};
using namespace std;
int main() {
    bar b;
    cout << b.calculate2(1,2) << endl;
    cout << b.calculate1(1,2) << endl;

    return 0;
}

To inherit or compose? (is inheritance really better here?)

2. Is it even possible or advisable?

We have seen that it is possible. As to whether it is advisable or not, semantics of foo and bar ^*will decide that. As they stand, I think inheritance looks much better, foo contains the basic calculators, bar needs to use them besides doing something extra. Of course, this is what I think happens and how you intend things to be, may/not be correct. ?In which case composition may win.

As a thumb rule, you can try saying the following two lines out loud :

a) bar is a foo (as in Car is a Vehicle)

b) bar has a foo (as in Car has an Engine)

If a makes more sense, inherit, otherwise compose. If none of them makes any sense, then you should probably give your design another cup of coffee.

Find more reasons here

*

Think of foo as a class widget and bar as a specialized widget, say textbox. Let calculate be a renderer (a function that draws textbox on screen), you do special things to arguments in bar and then call the standard renderer in foo. In this case, it makes sense to say that bar is a foo. On the other hand, let bar be a constraint solver which takes the arguments, does some calculation and passes them on to a standard la engine foo to do final calculations, then I'd say that bar has a linear algebra engine, foo.

Could you explain why you think inheritance looks better? I would argue that composition looks much better here. Also, your *is-a* *has-a* thing is confusing, because you are using inheritance to implement a *has-a* relationship. — juanchopanza, Aug 13 '14 at 09:31
You changed the inheritance to `public`. That makes the answer self-consistent, but there is nothing in OP's code to suggest that inheritance is better than composition here. You are basing your judgement on imagined classes. — juanchopanza, Aug 13 '14 at 09:42
@juanchopanza Yes. It was unintentional in the first place. Ran out of words there. I did mention that semantics of `foo` and `bar` should decide inheritance vs composition. — axiom, Aug 13 '14 at 09:44

C++ inheritance and overloading, calling a base method once overloaded

3 Answers3