C++ and base methods.

[Pix]

Let's say I have a heirarchy of classes,

CGramps, CDad, CSon.

CSon has a few methods. CDad has those methods as well, as well as some additional ones, and the same situation applies to CGramps. In other words, your standard inheritence model. We're also describing a heirarchy of COM interfaces, but that may not be relevant.

For purposes of reuse, I'd like to be able to write a CGramps class (actually CUnknown) that has three methods. One of them is a "do you support this function" method which takes a function identifier (could be an int, but is actually a GUID.) I'd like CGramps' implementation of that function to return true if it gets a particular identifier, false otherwise.

Here's where it potentially gets interesting. I'd like CDad to override the same function. It's *effect* is to return true if it's passed either of two function ids, false otherwise. One of the ids will be the same one that CGramps handles. I don't want to write any code to check for that function ID: I only want to handle the new one, and I'd prefer to call CGramps's method to handle the other one. CSon will add a third function ID it supports, and I want it to work the same way: it will return true if it's passed ie #3; otherwise it calls CDad.

How, if at all, do I do this?

The goal, as some of you probably can figure out, is to reuse QueryInterface functionality.

[RonHiler]

Maybe I misunderstand the question, but if I follow you, wouldn't you just write:

class CGramps
{
virutal bool FunctionSupported(GUID ID);
};

class CDad : public CGramps
{
virtual bool FunctionSupported(GUID ID);
};

class CSon : public CDad
{
bool FunctionSupported(GUID ID);
};

and your functions would be:

CSon::FunctionSupported(GUID ID)
{
if (ID == SON_ID)
return true;

return CDad::FunctionSupported(ID);
}

CDad::FunctionSupported(GUID ID)
{
if (ID == DAD_ID)
return true;

return CGramps::FunctionSupported(ID);
}

CGramps::FunctionSupported(GUID ID)
{
if (ID == GRAMPS_ID)
return true;

return false;
}

Would that not do what you are asking?

[Pix]

That would probaly work. I'm lazy, tho, I don't want to have to put in all those return __::FunctionSupported() calls, lest I forget one.

Also,

if a base class defines a virtual function, is it me or do I have to redeclare the function in a derived class if I want to have a new version? That's annoying.

[RonHiler]

That would probaly work. I'm lazy, tho, I don't want to have to put in all those return __::FunctionSupported() calls, lest I forget one.

There is no other way, that I know of, to force a base class function call from an overloaded derived class function except by explicitly calling it like that (ie the inheritence system won't call it automatically, if that is what you are after). If you come up with something, let me know

While you are at it, come up with a way to call a default constructor from a non-default construtor automatically. That's another one that bugs me, I wish the C++ language did that so you wouldn't have to duplicate code across multiple overloaded constructors.

Also,

if a base class defines a virtual function, is it me or do I have to redeclare the function in a derived class if I want to have a new version? That's annoying.

Yes, I believe you do have to redeclare it. Not sure why. You can try without the declaration, but I suspect what will happen is either you will get a compiler error, or if it compiles you will end up calling the base class function (the compiler will ignore the overloaded function since you didn't declare it).

But you can certainly try, it's an interesting question. I'd do it myself, but I'm out of the office right now for a couple of days, no compiler

[Pix]

Gr.

Regarding ctors, I believe the C++ way--which I'm sure you already know, if I'm right--is to pull common code into a (presumably private) helper function and call that from the ctor.

Regarding the declaration issue, the compiler simply errors (at least when the base class declares the functions as abstract, which is the case for COM interfaces.)

I'm playing around with writing an MMC snap-in. It's interesting because ideally you want to do some of your testing from outside MMC...which means you need to mock up part of it.

[RonHiler]

Gr.

Regarding ctors, I believe the C++ way--which I'm sure you already know, if I'm right--is to pull common code into a (presumably private) helper function and call that from the ctor.

Aye, that's one way to handle it. Unfortunately, that precludes the use of an initializer list, so you still, at the very least, need to duplicate that across all your constructors. PITA.

It would have been nice if you could call a ctor from another ctor (so that you could call the default ctor, from a non-default one and save yourself having to call a helper function + duplicate the initilizer list), but alas, you cannot. I'm sure there are very good reasons for that, probably having to do with the this pointer and perhaps the vtable pointer. But whatever, it still would have been nice if you could have done it

Regarding the declaration issue, the compiler simply errors (at least when the base class declares the functions as abstract, which is the case for COM interfaces.)

Yeah, I figured as much.

If you think about the purpose of an h file (which is to allow the client an easy way to look at the functionality of a class without having to dig through a bunch of code), that kind of makes sense. Without declaring the function in the derived class, the client would have to go digging through the base class header to find the function declaration you were defining in a totally different cpp file. To some extent, that's something they have to do anyway (for non-overridden functions), which has always been one of my big pet peeves with regards to "is a" inheritence. But at least for overridden functions, they only have to look at the derived class header.