Hello,
I have come up with the following framework:
interface
DECLSPEC_NOVTABLE IEngine abstract {virtual int silly(void) const { return 0; }
virtual void smart() = 0;
virtual ~IEngine() {};
};
template
<int P_I> interface DECLSPEC_NOVTABLE ISillyEngine: virtual public IEngine {int silly(void) const override { return P_I; }
};
class
SmartEngine: virtual public IEngine {void smart() override {}
};
class
Engine: public SmartEngine, public ISillyEngine<01> {};Is it safe/reasonable from the point of view of efficiency/security/maintainability/whatever to use virtual inheritance to glue implementations together as in the example above Are there any restrictions/warnings to be considered
I considered avoiding virtual inheritance by means of making class SmartEngine inherit from interface ISillyEngine but that would make class SmartEngine a template class which in turn would make SmartEngine::smart() a template method. I do not like it because it is a complex method and it does not depend on the parameter P_I in any way.
virtual inheritance and glue implementations
ummroffice
Iout weightst does seem rather complex and prone to problems (RE C4250). I see all the component classes being tightly coupled to the containing class (or vice versa), making them not very cohesive.
If the design works and you're comfortable with the maintenance fragility, then it works. It's really your only option if you don't want to force cohesive classes. I don't really see the need for ISillyEngine given its implementation. If a particular class needs to return 01 for int silly(void) then simply override that method, or provide the value needed via a constructor. Yes, a template (like ISillyEngine) could be written to consolidate code; but, the lack of clarity and increased complexity that it introduces out weights the benefits; especially if ISillyEngine is only used a handful of times.
feroz111
I am trying to compose the coclass (imagine a car radio) of block components. Each of the components I am trying to put together implements some part of the functionality. The components are of two kinds: silly sealed flavour providers (imagine a colour LED, where the colour would be a template parameter) and hard workers (imagine a wave tuner). I do not want the hard workers to be template classes so I cannot make them inherit from flavour providers.
In short, I wanted the following scheme: if you want to inherit the functionality of component X, inherit it. All functionalities are part of a common front panel which is the base interface. Is this design reasonable/feasible
I surely can have the components as members but I would have to define the method implementations in every coclass to call the corresponding methods of the components. I am trying to avoid this and use inheritance instead hoping that the correct methods will be injected by inheritance. But this design uses virtual inheritance that I know can sometimes bloat data structures and generates warnings C4250 I cannot get rid of so I feel uneasy about that.
Corinne C
The real purpose for ISillyEngine is to use a dynamic cast in a switch. C++ does not support the syntax
dynamic_switch(pEngine) { case CEngine1 *: … case CEngine2 *: … }
Therefore I need a switchable tag attached to each instantiation. The tag is characteristic to the coclass and not to the instance so I did not consider it appropriate to put it into the instance as a data member.
And regarding cohesiveness: I had to look this term up first. The following definition is taken from Let Your Users Sort it Out (Smart Access 2005):
A cohesive code routine or object performs just one function (or as few functions as possible)–just enough to make the routine useful. It's the degree to which your code is single-minded.
My position is that an object that returns E_NOTIMPL for all its declared functionality except one is cohesive. It cannot be used as a coclass but it can be used as a component to inherit from. Warning C4250 deprecates this construction and I am not sure why. No other compiler I know complains about it.
sven123
What are you trying to do
Do you want to decouple the interface from the implementation; i.e. do you want to have code that can uses methods of an object from a class that may not exist yet
Or, are you trying to provide common method implementations to more concrete classes