Paul Pluzhnikov wrote: > "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. >
OK, I may agree with you on this. > > This seems a normal issue which turns out to be a nightmare > > to solve. :-/ > > Firstly, your nightmare is entirely of your own doing. > Why is it of my doing? Because I'm trying a design pattern which is not so common after all? > 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 > // etc. > > > - into your main.o add this: > > #ifdef PULL_LIBBF > extern proxy p_libbf; > proxy &p_libbf_ref = p_libbf; > #endif > // etc. > > - 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. > This seems a nice solution. I'll only be able to try this later. Thanks a lot for you help, comments and suggestions. I do appreciate them. :-) Cheers, Paulo Matos > Cheers, > -- > In order to understand recursion you must first understand recursion. > Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
