Re: Decoupling classes
Victor Bazarov wrote:
Alan Woodland wrote:
W *v = new W();
Did you mean
V *v = new W();
? You would probably need a virtual destructor in 'V', of course.
It doesn't really matter, though. What you're trying to do _is_
It's as I feared then :( I was just trying to keep the example shorter.
t = &b;
No matter how you slice it, the type of 't' is A*. There is no way
for the program to learn where 't' came from.
Yes, I was hoping there was a gem of wisom that could make it appear
like to not be.
If 'A' or 'B' _were_
polymorphic types, one could try using 'dynamic_cast', yet it might
still fail (say, if 't' is part of another class deriving from 'A').
Yes, thats not too much of a problem though, I can handle that.
Double dispatch would help, if you allow that 'B' could know about 'W'.
I thought double dispatch required A knowing about W too? It's fine for
B to know about W I think - they'll both be being compiled into the same
shared object. (See below)
What problem are you trying to solve? Perhaps it's possible to do
I've got a group of Data structures that extend one base class. I've
written all the code so far to be very modular, and load a series of
plugins using shared objects (which works beautifuly). The problem now
though is that I want there to be output plugins that can do various
different types of output (e.g, rendering to OpenGL, saving to XML file
etc.) without ending up tying the Data structures to the output type.
The problem is though that the data structures themselves get extended
by some plugins, so adding a 'virtual void render(DataStructure& ds) =
0' pure virtual method in the base class for the OutputPlugin will only
result in the output plugin being aware of the basic information, not
the fact that it may (or may not) have been subclassed. So to sumarise
the code doesn't really feel like it belongs in a 'virtual void
render()' method in the DataStructure class, and putting it in the
OutputPlugin misses the sub classing.