Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

invalid covariant type / forward declaration?

1 view
Skip to first unread message

Sybolt de Boer

unread,
Nov 26, 2009, 8:33:54 AM11/26/09
to
Considering the following situation, is there a way to tell class White that
a Black* is actually a valid Base*? In other words can I somehow forward
declare "class Black : public Base;" in White.h and vice versa? Or am I
trying to do something very bad and clearly illegal? :)

TIA, Sybolt

// Base.h
#ifndef BASE_H
#define BASE_H
class Base {
public:
virtual Base *colleague(int i) const = 0;
virtual Base *opponent(int i) const = 0;
....
};

// White.h
#ifndef WHITE_H
#define WHITE_H
#include "Base.h"

class White : public Base {
public:
White *colleague(int i) const { return White::create(i); }
Black *opponent(int i) const { return Black::create(i); }
static White *create(int i);
....
};

// Black.h
#ifndef BLACK_H
#define BLACK_H
#include "Base.h"

class Black : public Base {
public:
Black *colleague(int i) const { return Black::create(i); }
White *opponent(int i) const { return White::create(i); }
static Black *create(int i);
....
};

Robert Hairgrove

unread,
Nov 26, 2009, 8:42:13 AM11/26/09
to

Move the function definitions into a .cpp file for each class. You will
also need to return Base* from both of the member functions in order for
it to work.

Sybolt de Boer

unread,
Nov 26, 2009, 9:07:12 AM11/26/09
to
Robert Hairgrove wrote:

Thanks for your reply. This is a heavily synthesized example. In reality the
definitions are in a seperate source file. What I want is to preserve to
color of the opponent, and not immediately degrade to a Base*. My compiler
will allow me to include White.h in Black.h, or Black.h in White.h, but not
both at the same time. I hope I'm making myself clear here. :)

Alf P. Steinbach

unread,
Nov 26, 2009, 10:00:52 AM11/26/09
to
* Sybolt de Boer:

The covariance support of C++ needs to know that the types are related.

You can get around it essentially as Robert Hairgrove explained else-thread, but
then when you switch to smart pointers the problem comes back with a vengeance,
because from the compiler's point of view those smart pointers are not related.

And one solution is to implement the covariance yourself. It is, after all,
nothing but a convenience notation. It's a bit more to write it yourself:


<code>
#include <memory>
#include <stdio.h>


class Base
{
public:
typedef std::auto_ptr<Base> AutoPtr;
private:
virtual AutoPtr v_colleague( int i ) const = 0;
virtual AutoPtr v_opponent( int i ) const = 0;
public:
virtual ~Base() {}
AutoPtr colleague( int i ) const { return v_colleague( i ); }
AutoPtr opponent( int i ) const { return v_opponent( i ); }
};


// These definitions are subtle due to restrictions of std::auto_ptr.
// Essentially can only be used in pure declarations until classes defined.
class White; typedef std::auto_ptr<White> AutoPtrWhite;
class Black; typedef std::auto_ptr<Black> AutoPtrBlack;


class White
: public Base
{
private:
virtual AutoPtr v_colleague( int i ) const;
virtual AutoPtr v_opponent( int i ) const;
public:
White( int i ) { printf( "Creating White(%d)\n", i ); }
virtual ~White() { printf( "White destroyed.\n" ); }
AutoPtrWhite colleague( int i ) const;
AutoPtrBlack opponent( int i ) const;
};

class Black
: public Base
{
private:
virtual AutoPtr v_colleague( int i ) const;
virtual AutoPtr v_opponent( int i ) const;
public:
Black( int i ) { printf( "Creating Black(%d)\n", i ); }
virtual ~Black() { printf( "Black destroyed.\n" ); }
AutoPtrBlack colleague( int i ) const;
AutoPtrWhite opponent( int i ) const;
};

Base::AutoPtr White::v_colleague( int i ) const
{
return AutoPtr( colleague( i ).release() );
}

Base::AutoPtr White::v_opponent( int i ) const
{
return AutoPtr( opponent( i ).release() );
}

AutoPtrWhite White::colleague( int i ) const
{
return AutoPtrWhite( new White( i ) );
}

AutoPtrBlack White::opponent( int i ) const
{
return AutoPtrBlack( new Black( i ) );
}

Base::AutoPtr Black::v_colleague( int i ) const
{
return AutoPtr( colleague( i ).release() );
}

Base::AutoPtr Black::v_opponent( int i ) const
{
return AutoPtr( opponent( i ).release() );
}

AutoPtrBlack Black::colleague( int i ) const
{
return AutoPtrBlack( new Black( i ) );
}

AutoPtrWhite Black::opponent( int i ) const
{
return AutoPtrWhite( new White( i ) );
}


int main()
{
AutoPtrWhite w( new White( 123 ) );
AutoPtrBlack b( new Black( 567 ) );
}
</code>


Cheers & hth.,

- Alf

Alf P. Steinbach

unread,
Nov 26, 2009, 10:27:51 AM11/26/09
to
* Alf P. Steinbach:

Oh, subtle point: if you're going to create subclasses of White and Black, then
the calls should be made the other way, from non-virtual to virtual, which then
involves casting.

Once had great debate with I think it was Dave Abrahams about this, anyway some
well known figure.

It's just something that one doesn't think of up front, and without thinking of
further derived classes it doesn't seem to make sense.


Cheers & hth & sorry, wasn't thinking of that,

- Alf

Sybolt de Boer

unread,
Nov 26, 2009, 11:55:51 AM11/26/09
to
Alf P. Steinbach wrote:

I've worked around my problem in ways best left unmentioned here, but this
post was very useful to me. Thank you!

Sybolt

Michael Tsang

unread,
Nov 29, 2009, 9:44:58 AM11/29/09
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sybolt de Boer wrote:

I don't think this is possible. Black depends on White and White depends on
Black so you need to use a forward declaration. However, a forward
declaration cannot contain base specifier so covariant return type cannot be
applied.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksSiOsACgkQG6NzcAXitM8qUwCeL9fWiG4JXscydl+F0Nl3+bxs
PjkAnimnhIyGGVC/W71f8FUxZcuVnRuy
=O6DU
-----END PGP SIGNATURE-----

0 new messages