带有指针的C ++无效协变返回类型

Question

I already searched a lot to find a solution for my problem, but I can't find a way to get the following code to work.

Background

I wrote a class structure that represents any kind of Archive (in my real case, this would be a FileRepository which also might be an Archive). Therefore I defined a pure virtual class structure representing an archive.

An archive is actually a directory, a directory is actually an entity (Base in this case). A file within this archive also would be an entity (Base). These classes are used as interface for real implementations.

In the code you'll see the My... implementations of these classes.

Problem

The MyDirectory implementation overwrites the Base's getParent method which expects a Directory to be returned. Actually, the MyDirectory implementation only can have a MyDirectory as parent, therefor the new implementation returns a MyDirectory, not a Directory. That's where C++ throws the error message!

The compiler doesn't know, that MyDirectory actually is a Directory, because I overwrite the getParent method in the MyBase class, before declaring the MyDirectory class.

And as MyDirectory also wants to call specific MyDirectory methods (as getAbsolutePath), I really need the return type to be MyDirectory, not Directory. (and static_cast did not work, either :()

I would be happy about any hint, how to solve my problem :)

Edit: Details

The problem actually is the complicated inheritance graph. The problem is that MyDirectory inherits MyBase, but MyBase's method returns MyDirectory - but the Base class requires to return a Directory, but at declaration, c++ does not know that MyDirectory actually is a Directory. I'm trying to solve, that MyDirectory can return a MyDirectory instance and does not require to return a Directory instance.

// Just an example code - actually is separated in .h and .cpp and cleaner and and and... :)

class Directory;
class MyDirectory;

class Base {
public:
    /// Returns the parent directory
    virtual Directory *getParent()=0;
};

class Directory : virtual public Base {
public:
};

class Archive : virtual public Directory {
public:
};

// ---------------------------------

class MyBase : virtual public Base {
public:
    /// Constructor
    MyBase(int i, int j, int k) {}

    /// Returns the parent directory
    MyDirectory *getParent() { return NULL; }

    /// Returns the parent directory
    virtual const char *getAbsolutePath() const { return "my full path"; }
};

class MyDirectory : virtual public Directory, public MyBase {
public:
    /// Constructor
    MyDirectory(int i, int j) : MyBase(i, j, i+j) {}

    /// Returns the parent directory (not really, I know! Just an example)
    virtual const char *getAbsolutePath() const { return getParent()->getAbsolutePath(); }
};

class MyArchive : virtual public Archive, public MyDirectory {
public:
    /// Constructor
    MyArchive(int i) : MyDirectory(i, i) {}
};

Answer 1

Covariant return types are just convienience.

Write GetMyParent() that returns MyDirectory . Defer the implementation of GetParent and GeyMyParent until MyDirectory is visible, then have GetParent call GetMyParent .

In MyDirectory you could make GetParent fully covarient if you want to, but I wouldn't bother. Never override GetParent after MyBase , if that is needed override GetMyParent instead.

Maybe make GetParent private so you do not accidentally call it. If you have a MyBase , call GeyMyParent instead.

If this makes code annoying to maintain, write a free function calped GetParent that uses overrides to pick which one to call. If you hate free functions, add a non virtual method that picks which one to call (well two, one in Base and one in MyBase ).

The only problem with the free function/non-virtual method is that your multi-path tree can confuse it, resulting in ambiguity. I would just go with calling GetMyParent() when you know have a MyBase and need a MyDirectory* . The requirements for a ridiculous number of overrides of the method/free function, or the template hackery required to have ti happen automatically, isn't worth it.