Re: Covariant return types and interdependent classes
On Aug 31, 2:47 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
On 31/08/2011 13:52, Javier wrote:
I'm having a problem trying to get two classes that refer to each
other take a covariant return type. While this is occurring in the
Visual C++ 2010 compiler (and I'm posting a modified version here of
my original post in the C++ forums at MS), I have a more general
question, namely if there is a way for a compiler to pass what would
be, in my opinion, valid code for covariant return types, or if I'm at
the mercy of the compiler vendor :-)
Instead of outlining a wildly complicated piece of code could you please explain what problem you are trying to solve because IME complex solutions are usually unnecessary and doubly so if they will not compile.
The other issue in that where two classes are so intimately related it makes sense to declare and define them in the same header file. Neither of your base classes can be defined in ignorance of the other so placing them in separate header files makes no sense.
{ quoted banner removed -mod }
Francis,
The code is for a telephony framework based on JTAPI.
In UML terms, it is a bidirectional relationship between two abstract
classes or interfaces, allowing navigation to both sides, and then
specializing the relationship on concrete classes (in this case I'm
showing the relationship with a qualifier--the name--on the Terminal
side).
Obvious implementations for interdependent classes is to return by
pointer or reference, with forward declarations on each header file.
Other implementations could use shared_ptr<T>, but it would not be
possible to have covariant return types using shared_ptr<Base> and
then returning shared_ptr<Derived>.
In any event, the code is similar to this:
In Provider.h:
class Terminal;
class Provider // abstract
{
public:
virtual ~Provider() {} // polymorphic deletions
virtual Terminal* getTerminal(std::string const& name) const = 0;
};
- - -
In Terminal.h:
class Provider;
class Terminal // abstract
{
public:
virtual ~Terminal() {} // polymorphic deletions
virtual Provider* getProvider() const = 0;
};
- - -
A "basic" implementation without covariant return types works (no
surprises here), BUT I want to specialize the relationship to return
the concrete derived types. This forces me to expose the is-a
relationship between Terminal and BasicTerminal to BasicProvider; and
the is-a relationship between Provider and BasicProvider to
BasicTerminal, which can be done only by including the "BasicXxx.h"
files:
In BasicProvider.h:
#include "Provider.h"
#include "BasicTerminal.h" // for compiler to see is-a relationship
class BasicProvider : public Provider // concrete derived class
{
public:
~BasicProvider() {}
BasicTerminal* getTerminal(std::string const& name) const = 0;
};
- - -
In BasicTerminal.h:
#include "Terminal.h"
#include "BasicProvider.h" // for compiler to see is-a relationship
class BasicTerminal : public Terminal // concrete derived class
{
public:
~BasicTerminal() {}
BasicProvider* getProvider() const = 0;
};
- - -
In BasicProvider.cpp and BasicTerminal.cpp, which include their
corresponding header file as the first line of code, the compilation
breaks in the VC2010 compiler (have not tried another compiler mostly
because I think that this is a "it should work" situation :-),
therefore the question if it is valid C++ (and Daniel responded it is
not) or whether a compiler could "defer" emitting an error until it
determines whether BasicTerminal and BasicProvider are derived from
the corresponding types, and whether such compiler exists.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]