I don't know how usefull this, but I would like to know some valid
reasons to avoid this.
Sorry, I don't see (couldn't understand ?!) any coupling issues.
If the containing class held the implementation of a function declared
elsewhere than surely there would be coupling issues.
Let me try to list down some more info. (May be, I am wrong)
1. while creating member object for an abstract class, the containing
class can be looked for valid implementation for the virtual
functions.
There is no 'objects' in a class. A class/struct is a blueprint.
An instance of a class is an object,
and an abstract class can never be instantiated to be an object or a
member of an object.
Thats what 'abstract' means: the class is not allowed to be used to
instantiate a concrete object.
The term 'abstract' means you must derive and implement whatever is
pure-virtual before instantiating a derived object. It implies an
inheritence tree.
You should consider reading about abstract types, they are a powerful
concept (considerably more powerfull than you think them to be). Good
examples of these is std:
stream where the abstract type can be used
as a reference to a derived object safely.
2. If there is no valid implementations then the member object
creation can be disallowed (results in a compile time error),
otherwise, member object construction can be allowed.
Thats exactly what the example with the templated class does.
3. Any calls to member object's virtual function can be directed to
the implementation provided by the containing class.
no, since the containing class is not in the inheritance hierarchy.
Think of it this way: what you are trying to do is in fact doable. You
could conceivably use a function pointer and the appropriate
arguements/references to redirect a member function to call a sequence
of events held in the container object. However thats bad design, bug-
ridden and very expensive to maintain. Its ugly, hard to read, hard to
debug, difficult to explain, a bad concept, etc...
4. I think, there is no need to maintain vtable for this containment
hierarchy.
casting usually is more expensive than polymorphic mechanisms.
And most of the time, casting is much, much slower as well as
inherently unsafe.
Keep it simple and structured or pay the price.
5. old code calling new code ?!
what?