---- Original Message ---- From: f.stella@flashnet.it To: boost@lists.boost.org Subject: RE: [boost] Factory library new version Date: Wed, 4 May 2005 02:57:19 +0200

I've uploaded a new version for factory library [1] whit these changes: o Added some tutorial on library use. o Ported 3 example from Rob Geiman's object factory. o More documentation. o Fixed some bugs. o Now uses boost directory structure. o Big architectural changes. o Boost.Singleton is now optional.

I've checked the object factory from Rob Geiman and I think the main differences between implementations are that mine could use an allocator

I actually re-worked my object factory class to allow STL allocators to be used for the allocation policy, but I haven't finished it/posted it to the vault because the initial response I got when I introduced my object factory was very limited.

and call any constructors without limiting to just one.

Variable number of constructor parameters is quite nice! However, there is another difference between our two implementations. Mine is specifically made to register classes dynamically during runtime by calling the register() function of the factory object, while yours appears (and please correct me if I'm wrong) to be done via compile time. In other words, to add a derived3 class you must actually edit the boost::factory typedef to specifiy derived3 in the mpl::vector.

Rob's library has an allocation policy but it embed even "creation" policy so changing the policy requires writing the some same code. Rob am I right?

Yep, current implementation does use the creation policy while my unreleased personal version can use STL allocators.

Up to now it lacks: o test cases. o some optimizations. o the documentation is still doxygen generated, but I plan to test "doxygen autodoc".

Ideas? Comments? Bugs?

Overall I like it! Quite an interesting approach to a problem I spent a lot of time working on. Two things tho: I'm not certain I like the fact that you must create a builder class instance for every class you register. Any way to get rid of this or hide it in the factory class implementation itself? Would it be possible to allow for derived classes to be added dynamically without the need to edit the declaration of the factory object itself? I know many boost users perfer compile-time solutions to run-time solutions, and certainly each of their own uses, but I've always like the ability to allow end-users to modify/extend programs simply by registering their classes with my factory object (IE, the user shouldn't need to recompile my code to do this). Rob

Fede.

[1] http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadf ile&filename=factory2.zip&directory=&

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo. cgi/boost