Base class notation.

[TomChapman]

Lets say I have a base class called "MyBaseClass". I derive a class from
that base class called "MyDerivedClass".

In a function of the derived class I sometime write a function call
formatted like this:

MyBaseClass::SomeFunction(a parameter list goes here);

I specifically include the base class name, MyBaseClass, so that the
base class's version of the function is called instead of a similarly
named derived class function.

QUESTION: Is there a different notation (or maybe a "best practice")
that I can use where I don't need to specify the actual base class name.
Some notation that says "use the base class version of this function
from whatever class happens to be the base class"?

[ralph]

On Sat, 31 Dec 2011 12:08:51 -0600, TomChapman

Post by TomChapman
Lets say I have a base class called "MyBaseClass". I derive a class from
that base class called "MyDerivedClass".
In a function of the derived class I sometime write a function call
MyBaseClass::SomeFunction(a parameter list goes here);
I specifically include the base class name, MyBaseClass, so that the
base class's version of the function is called instead of a similarly
named derived class function.
QUESTION: Is there a different notation (or maybe a "best practice")
that I can use where I don't need to specify the actual base class name.
Some notation that says "use the base class version of this function
from whatever class happens to be the base class"?

I must be missing something.
Just make the base method Protected in the Base Class.

During development both classes may look like very separate code
Interfaces, but after compiling the two are merge into one object.
Drop back and take the time to reread the differences betwee Private,
Propected, Virtual, Friend.... and how methods with these 'seen'
attributes are 'seen' outside the finished object.

-ralph

[TomChapman]

Here's the situation:

DerivedClass::DoStuff()
{
// do some unique stuff here

// call base class
BaseClass::DoStuff()

// do some other unique stuff here
}

Notice both the base class and the derived class have functions with the
same name and parameter list. In the above code you need to use the
notation BaseClass::DoStuff to insure you are calling the BaseClass
version and not the "this" class version.

What I don't like is that the actual name of the base class, in this
case "BaseClass", has to be included in the code as shown above.

What if I change the base class to some other class with a different
name. I am forced to make a bunch of edits all over the derived class.

I was wondering if there was some notation or some coding method to
avoid this situation. It would be nice if I could have written the
function above like this:

DerivedClass::DoStuff()
{
// do some unique stuff here

// call base class
(some notation) DoStuff()

// do some other unique stuff here
}

I'm asking if there is some notation that I could use so that I don't
have to sprinkle the base class's name all over my derived class code.
It would be some notation that means... Use the base class and not the
"this" class.

Post by ralph
On Sat, 31 Dec 2011 12:08:51 -0600, TomChapman

Post by TomChapman
Lets say I have a base class called "MyBaseClass". I derive a class from
that base class called "MyDerivedClass".
In a function of the derived class I sometime write a function call
MyBaseClass::SomeFunction(a parameter list goes here);
I specifically include the base class name, MyBaseClass, so that the
base class's version of the function is called instead of a similarly
named derived class function.
QUESTION: Is there a different notation (or maybe a "best practice")
that I can use where I don't need to specify the actual base class name.
Some notation that says "use the base class version of this function
from whatever class happens to be the base class"?

I must be missing something.
Just make the base method Protected in the Base Class.
During development both classes may look like very separate code
Interfaces, but after compiling the two are merge into one object.
Drop back and take the time to reread the differences betwee Private,
Propected, Virtual, Friend.... and how methods with these 'seen'
attributes are 'seen' outside the finished object.
-ralph

[ralph]

On Sun, 01 Jan 2012 10:06:11 -0600, TomChapman

Post by TomChapman
DerivedClass::DoStuff()
{
// do some unique stuff here
// call base class
BaseClass::DoStuff()
// do some other unique stuff here
}
Notice both the base class and the derived class have functions with the
same name and parameter list. In the above code you need to use the
notation BaseClass::DoStuff to insure you are calling the BaseClass
version and not the "this" class version.
What I don't like is that the actual name of the base class, in this
case "BaseClass", has to be included in the code as shown above.
What if I change the base class to some other class with a different
name. I am forced to make a bunch of edits all over the derived class.
I was wondering if there was some notation or some coding method to
avoid this situation. It would be nice if I could have written the
DerivedClass::DoStuff()
{
// do some unique stuff here
// call base class
(some notation) DoStuff()
// do some other unique stuff here
}
I'm asking if there is some notation that I could use so that I don't
have to sprinkle the base class's name all over my derived class code.
It would be some notation that means... Use the base class and not the
"this" class.

There may be. But over-all I don't think there is an easy-way out.

You have introduced an ambiguity. I think you have already
investigated your serious options. The scope resolution operator will
help at the risk of course of tightly linking the two classes, but
will have less impact and is easily understood as to why it is there
and what it is doing. (Always important 6 months form now. <g>)

I would probabably go back and fix it. Even if it takes a couple of
days.

There is another idea, though equally untasty in terms of time to
repair. Often when you have this scenario, where a specialized object
(created through inheritance) needs to treat its generalized class as
a separate provider/s of some service, that it may be you do NOT in
fact have a clean hiearchy. You migh consider re-writing the 'derived'
specialized object as "using" the base class and not as an "is a".

-ralph

[ScottMcP [MVP]]

The notation you are looking for is...

__super::DoStuff();

See http://msdn.microsoft.com/en-us/library/94dw1w7x(v=VS.100).aspx

[TomChapman]

Cool! Thank you.

Post by ScottMcP [MVP]
The notation you are looking for is...
__super::DoStuff();
See http://msdn.microsoft.com/en-us/library/94dw1w7x(v=VS.100).aspx