473,320 Members | 1,722 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

virtual inheritance nightmare


In the code below, controller::controller() is never invoked, however,
it appears there is no way to make a compile-time rule that this should
not happen. The code below seems to make compilers complain that
controller::controller() is private, even though it is never used.

What do others do to work-around this ? I suppose I can simply
not implement controller::controller(), that way I get a linking
error if there exists errant code. (ok tried that - gcc seems to
detect errors and all is fine, MSVC seems to need the constructor
even though it should never be invoked.)

Especially when a class has no way of being constructed alone (due to
pure virtual methods), there should be not reason to access default
virtual constructors since they can never be called hence there should
be no violation of the access rule.

class controller
{
controller(); // private don't want anyone to call this
public:
controller( int ); // this should be called instead
};

class Interface
: virtual public controller
{
public:
virtual void DoThing() = 0;
};

class Interface_Impl1
: public Interface
{
public:

virtual void DoThing1() = 0;

virtual void DoThing()
{
DoThing1();
}
};

class Interface_Impl2
: public Interface
{
public:

virtual void DoThing2() = 0;

virtual void DoThing()
{
DoThing2();
}
};

class Interface_Impl3
: public Interface
{
public:

virtual void DoThing()
{
// doing 3
}
};

class Application
: public Interface_Impl1,
public Interface_Impl2
{
Application()
: controller( 3 )
{
}

void DoThing1()
{
// Doing 1 it here !
}

void DoThing2()
{
// Doing 2 it here !
}
};
Jul 22 '05 #1
3 1444
Gianni Mariani wrote:
In the code below, controller::controller() is never invoked, however,
it appears there is no way to make a compile-time rule that this should
not happen. The code below seems to make compilers complain that
controller::controller() is private, even though it is never used.
But it _might_ be used if you derive from Interface and make that class
concrete.
What do others do to work-around this ? I suppose I can simply
not implement controller::controller(), that way I get a linking
error if there exists errant code. (ok tried that - gcc seems to
detect errors and all is fine, MSVC seems to need the constructor
even though it should never be invoked.)
But Impl1 and Impl2 also don't have default c-tors... And those _are_
invoked, no?

Especially when a class has no way of being constructed alone (due to
pure virtual methods), there should be not reason to access default
virtual constructors since they can never be called hence there should
be no violation of the access rule.
That's a QOI issue, I believe.

class controller
{
controller(); // private don't want anyone to call this
public:
controller( int ); // this should be called instead
};

class Interface
: virtual public controller
{
public:
virtual void DoThing() = 0;
};
As is, 'Interface' cannot have a default c-tor because its base class,
'controller' cannot be instantiated. Right?

class Interface_Impl1
: public Interface
{
public:

virtual void DoThing1() = 0;

virtual void DoThing()
{
DoThing1();
}
};
Now, 'Interface_Impl1' cannot have the default c-tor since 'Interface',
which is its base class, cannot have one. Right?

class Interface_Impl2
: public Interface
{
public:

virtual void DoThing2() = 0;

virtual void DoThing()
{
DoThing2();
}
};
Now, 'Interface_Impl2' cannot have the default c-tor as well, due to the
same reason as the 'Interface_Impl1'. Right?

class Interface_Impl3
: public Interface
{
public:

virtual void DoThing()
{
// doing 3
}
};

class Application
: public Interface_Impl1,
public Interface_Impl2
{
Application()
: controller( 3 )
Wait... Here 'Interface_Impl1' and 'Interface_Impl2' _are_ instantiated
using their default c-tor, which cannot be generated because... See above.
{
}

void DoThing1()
{
// Doing 1 it here !
}

void DoThing2()
{
// Doing 2 it here !
}
};


The work-around here (as I see it) is to declare 'Interface*' constructors
to accept a single argument and give it a default value. Since the final
class 'Application' will provide the argument for 'controller', the other
argument (although you will thread it through to the 'controller's c-tor)
will not have any effect. Of course, you will have to initialise the
virtual base 'controller' in each of 'Interface*' constructors too, but
that, again, should have no effect on your code, since 'Application' takes
over.

BTW, your 'Application's constructor is also private.

V
Jul 22 '05 #2
Victor Bazarov wrote:
Gianni Mariani wrote:
In the code below, controller::controller() is never invoked, however,
it appears there is no way to make a compile-time rule that this
should not happen. The code below seems to make compilers complain that
controller::controller() is private, even though it is never used.

But it _might_ be used if you derive from Interface and make that class
concrete.


How could it possibly be used ? Interface is an abstract class which by
definition means it can't be instantiated alone. If it is made complete
by inheritance, then it is the derived class that will need to call the
controller() constructor. Am I wrong ?
What do others do to work-around this ? I suppose I can simply
not implement controller::controller(), that way I get a linking
error if there exists errant code. (ok tried that - gcc seems to
detect errors and all is fine, MSVC seems to need the constructor
even though it should never be invoked.)

But Impl1 and Impl2 also don't have default c-tors... And those _are_
invoked, no?


Same issue applies here, the controller() constructor can't be called in
Impl1 and Impl2 because they are never instantiated alone.

Especially when a class has no way of being constructed alone (due to
pure virtual methods), there should be not reason to access default
virtual constructors since they can never be called hence there should
be no violation of the access rule.

That's a QOI issue, I believe.


"Question of Intelligence" ?

....
Wait... Here 'Interface_Impl1' and 'Interface_Impl2' _are_ instantiated
using their default c-tor, which cannot be generated because... See above.
yeah, but controller() constructor must not be called.

The work-around here (as I see it) is to declare 'Interface*' constructors
to accept a single argument and give it a default value. Since the final
class 'Application' will provide the argument for 'controller', the other
argument (although you will thread it through to the 'controller's c-tor)
will not have any effect. Of course, you will have to initialise the
virtual base 'controller' in each of 'Interface*' constructors too, but
that, again, should have no effect on your code, since 'Application' takes
over.
That makes it far too onerous. Having a to write a whole bunch of dead
code that never gets executed just to satisfy the compiler seems a
nonsensical to me.

BTW, your 'Application's constructor is also private. yeah - just example code.
V


Thanks for the ideas !

I think I'll go with implementing a controller() constructor and putting
a big fat abort() in it. (perhaps on gcc, not implementing it at all !).

G
Jul 22 '05 #3
Gianni Mariani wrote:
Victor Bazarov wrote:
That's a QOI issue, I believe.

"Question of Intelligence" ?


Quality of implementation.

...

Jul 22 '05 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

18
by: nenad | last post by:
Wouldn't it be nice if we could do something like this: class Funky{ public: auto virtual void doStuff(){ // dostuff } };
4
by: JKop | last post by:
I'm starting to think that whenever you derive one class from another, that you should use virtual inheritance *all* the time, unless you have an explicit reason not to. I'm even thinking that...
14
by: Bruno van Dooren | last post by:
Hi all, i am having a problems with inheritance. consider the following: class A { public: A(int i){;} };
3
by: Imre | last post by:
Hi! I've got some questions regarding heavy use of virtual inheritance. First, let's see a theoretical situation, where I might feel tempted to use a lot of virtual inheritance. Let's...
3
by: kikazaru | last post by:
Is it possible to return covariant types for virtual methods inherited from a base class using virtual inheritance? I've constructed an example below, which has the following structure: Shape...
2
by: Heinz Ketchup | last post by:
Hello, I'm looking to bounce ideas off of anyone, since mainly the idea of using Multiple Virtual Inheritance seems rather nutty. I chalk it up to my lack of C++ Experience. Here is my...
23
by: Dave Rahardja | last post by:
Since C++ is missing the "interface" concept present in Java, I've been using the following pattern to simulate its behavior: class Interface0 { public: virtual void fn0() = 0; };
7
by: v4vijayakumar | last post by:
Is it possible to implement member object's virtual functions, in the containing class? If not, is it possible to simulate this behavior? ex: class test { protected: virtual void fun() = 0;...
0
by: =?Utf-8?B?Zmplcm9uaW1v?= | last post by:
Hi all, As I mentioned in a previous thread (see 'Dbghelp, symbols and templates' in microsoft.public.windbg), we created a powerful symbol engine using dbghelp to dump the contents of the stack...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.