0

this may be easier than I see, but I'm a legacy system (old), so my mind is going Dave -- I can feel it....

I have some C++ libraries I'm trying to build. They happen to be for a CPU simulator that happens to have virtual memory. But to keep things simple, assume I have some library class Foo. This is the implementation class. Something like:

class Foo() {
    Foo *newFoo() ....
    void doFoo() .....
    Foo(Bar *b) ... // Constructor for FOo
}

Now, of course, any code that #includes "Foo.h" can use it, but if Bar needs to have Foo as well in its constructor, we have the circular reference problem. I could create a FooInterface class such as:

#include "Bar.h"
#include "Foo.h"

 class FooInterface (
    virtual Foo *newFoo() = 0;
    virtual void doFoo() = 0;
    virtual FooInterface(Bar *b) = 0;
 }

One would think, in the main code, I could then just do a

FooInterface fi;
auto newFoo = fi.newFoo(newBar)
newFoo.doFoo()

But FooInterface has to somehow know to get a real Foo instantiated, and it has to do it, without letting main know about it. If I were in C, I'd be evil and do something like:

extern void *makeNewFoo();

And deeper in a separately compiled library, makeNewFoo would actually create a Foo, cast it's pointer to a void *, and return it. I'd have external functions for the methods, and, when called, the separately compiled methods would convert the void * back to the real *Foo.

I suspect I'm doing this not only the wrong way (!!) but the hard way as well... How should I do this? What are best practices?

user500123
  • 617
  • 6
  • 14

0 Answers0