"Paulo Matos" <[email protected]> writes:
> Isn't this a normal
> problem: an interface with some libraries using the interface. The core
> creates and destroys the object of the libraries through the interface.
No, I don't believe this is a widely-used design pattern,
at least not with static linking.
> This seems a normal issue which turns out to be a nightmare
> to solve. :-/
Firstly, your nightmare is entirely of your own doing.
Secondly, it has trivial solutions.
One I already mentioned: listing objects explicitly.
Here is another:
- rename your "registration" objects such that their names are
unique, e.g. instead of "proxy p;" say
proxy p_libbf; // in libbf.a
proxy p_libot; // in libot.a
- into your main.o add this:
extern proxy p_libbf;
proxy &p_libbf_ref = p_libbf;
- now you can control what is pulled into the static link:
g++ -DPULL_LIBBF main.cc -c
- link just the way you do now, and the object(s) that you need
from libbf.a will be pulled in into the main exe, because p_libbf
is now on the "needed" list.
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.