Re: Object Factory and pre-main registering of classes
On May 10, 8:42 pm, John <gh14...@yahoo.com> wrote:
I am trying to create an object factory, AFactory, that allows
new object types (of base class A) to be added without
changing the factory. The factory is designed so that each
class registers itself with the factory by passing an object
name and a pointer to a function that creates that particular
object type. I am trying to get the classes to register
themselves before the main program executes. The behavior I
am getting is the following (confirmed with both g++ and MS
Visual Studio).
1. If I compile and link all files simultaneously
g++ *.cpp
the code works correctly (no reverse dependency)
2. If I compile all files separately and link all object files
g++ -c *.cpp
g++ *.o
the code works correctly (no reverse dependency).
In other words, the code works. (Which doesn't surprise me;
it's an idiom I use a lot.)
3. If I compile files separately, link the factory and related
classes into a library and then link the main routine with the
library
g++ -c A*.cpp
ar rvs liba.a A*.o
g++ main.cpp -L. -la
the classes do not register themselves before the main function.
That's because they aren't part of the program. You told the
linker to include only object files which resolve an unresolved
extern.
A workaround I found was to put the following in
AFactory::GetInstance() function
// FIXME: This forces the maps to register. There should be some way
// to force the registration without creating this reverse dependency.
if (m_factory.m_callback.empty())
{
CreateCallBack fnc;
fnc = AType1::CreateA;
// Add all : fnc = ATypeX::CreateA;
}
I don't want to do this because it creates a reverse dependency that
requires modification of the factory to add a new class.
Is there any way to get this to work and still use libraries?
I need the factory code to be in a library for the project I
am working on.
What your question comes down to is if there is any way to force
the inclusion of an object file that doesn't resolve an
unresolved external, even if it is in a library. The answer is
very system dependent; basically what you're saying is that you
are required to use a library, but that it can't behave like a
library. Some link editors, I'm sure, have options to support
this, but you'll typically have to modify the client link
command. If you're required to use a library, then this may not
be acceptable either. Even without the command, it's trivial
in a make file to extract the library into a temporary
directory, then link all the object files in that directory; if
you can impose requirements on how your library is linked in,
this might be the simplest solution.
Or the development environment might provide a way of merging
several object files into a single object file, so you just
deliver that. While it's not a library, it's only a single
file, so your clients might accept it. I'm not sure off hand,
but I think some linkers will accept a simple concatenation of
object files.
Another alternative which may or may not be acceptable, is to
link the factory and all of the instances into a dynamic object,
rather than a library. Since dynamic objects (.dll under
Windows, .so under Unix) aren't libraries, but object files,
linking them is an all or nothing proposition---when you link a
dynamic object, you get everything in the object (just like when
you statically link an object file).
Failing that (i.e. you have a requirement that your client use
the library like he would any other library), one possibility is
to artificially construct the dependencies in the makefile which
builds the library. Roughly speaking: make the static variables
whose initializer does the registration globally accessible, and
give them a name which can be regularly derived from the
filename. Then, in the makefile that builds the library, create
a source file which constructs a table refering to these
variables, compile it, and refer to it in your factory (called
by the client).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34