a generic factory for boost
I cannot find a generic factory implementation in boost. I have implemented my own, lightweight and header-only factory class: libfactory++ [http://freshmeat.net/projects/libfactory] which I would like to make available to boost. It takes a somewhat curious approach to custom constructors (using the Command pattern), and it still has a TODO list that's non-empty, but I would be happy to submit this work to boost. Question is: is there interest for this? View the tree online: http://xrl.us/f4r5 [0] 0. http://arch.madduck.net/cgi-bin/archzoom.cgi/madduck@arch.madduck.net--2005-... -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net your eyes are weary from staring at the CRT. you feel sleepy. notice how restful it is to watch the cursor blink. close your eyes. the opinions stated above are yours. you cannot imagine why you ever felt otherwise.
Could you compary your library to the version from http://boost-sandbox.sourceforge.net/vault/ (file factory2.zip). There has been at least one attempt to create Boost factory library in the past. /Pavel
[Cc'd libfactory discussion list. Quite possibly, boost::factory may
be the end for libfactory++, so you guys probably care. :)]
also sprach Pavel Vozenilek
Could you compary your library to the version from http://boost-sandbox.sourceforge.net/vault/ (file factory2.zip).
Thanks for the pointer. I compared to factory3.zip, which seems to be an updated version. From a cursory look I can conclude the following: - boost::factory and libfactory++ do 98% of the same stuff. - both factories are header-only. - both libraries provide for custom allocators, custom key types. - boost::factory is nicely documented, libfactory++ is not (yet). - boost::factory's handling of constructors is very nice, although I can't figure it out completely... how are arguments bounds at builder creation time? anyway, being able to bind some arguments at builder creation time and specify remaining ones at instantiation time is spiffy! I use the Command pattern, which essentially allows the same, but now that I saw boost::factory, I am envious. :) Anyway, is the constructor selected based on the arguments available? libfactory++ allows you to choose (and configure) the constructor to use for each call to create(). - libfactory++ relies on static factory objects instantiated in the unnamed namespace (all automatic), whereas boost::factory requires factory objects to be created and configured by the user. - It seems that boost::factory does not allow automatic registration of types (think: load plugins), which was one of the reasons for the creation of libfactory++, so libfactory++ supports it, using the static global factory objects as well as macros for the type registration. I may well be wrong and boost::factory does support this. How? - boost::factory is written for boost, libfactory++ is not. Thus, there is quite some work ahead of libfactory++, should it be the chosen one (I doubt it). - boost::factory seems to be very closely modelled on Alexandrescu's AbstractFactory (which may well not be his concept). libfactory++ comes from my own synapses only and was written long before I got into generic programming as understood by GoF, Alexandrescu, and boost. I am humbled to find out that I was smart enough to do most of it right. However, I also feel as if I will likely not stand a chance because I surely did overlook something.
There has been at least one attempt to create Boost factory library in the past.
I would have been surprised if otherwise.
So all of the above make me want to think that boost::factory is the
way to go. I think I will keep libfactory++ around to allow people
to use a factory without the boost "overhead", but it's not going
into boost.
Instead, I will talk to Federico (that name sounds familiar from
somewhere...) and see whether I can help out developing
boost::factory.
Thanks for the pointer, Pavel.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
#include
"martin f krafft" wrote: be the end for libfactory++, so you guys probably care. :)]
http://boost-sandbox.sourceforge.net/vault/ (file factory2.zip).
Thanks for the pointer. I compared to factory3.zip, which seems to be an updated version.
From a cursory look I can conclude the following:
- boost::factory and libfactory++ do 98% of the same stuff. - both factories are header-only. - both libraries provide for custom allocators, custom key types. - boost::factory is nicely documented, libfactory++ is not (yet). - boost::factory's handling of constructors is very nice, although I can't figure it out completely... how are arguments bounds at builder creation time? anyway, being able to bind some arguments at builder creation time and specify remaining ones at instantiation time is spiffy! I use the Command pattern, which essentially allows the same, but now that I saw boost::factory, I am envious. :) Anyway, is the constructor selected based on the arguments available? libfactory++ allows you to choose (and configure) the constructor to use for each call to create(). - libfactory++ relies on static factory objects instantiated in the unnamed namespace (all automatic), whereas boost::factory requires factory objects to be created and configured by the user. - It seems that boost::factory does not allow automatic registration of types (think: load plugins), which was one of the reasons for the creation of libfactory++, so libfactory++ supports it, using the static global factory objects as well as macros for the type registration. I may well be wrong and boost::factory does support this. How? - boost::factory is written for boost, libfactory++ is not. Thus, there is quite some work ahead of libfactory++, should it be the chosen one (I doubt it). - boost::factory seems to be very closely modelled on Alexandrescu's AbstractFactory (which may well not be his concept). libfactory++ comes from my own synapses only and was written long before I got into generic programming as understood by GoF, Alexandrescu, and boost. I am humbled to find out that I was smart enough to do most of it right. However, I also feel as if I will likely not stand a chance because I surely did overlook something.
There has been at least one attempt to create Boost factory library in the past.
I would have been surprised if otherwise. ------------------ PV: I was involved in one such attempt. So all of the above make me want to think that boost::factory is the way to go. I think I will keep libfactory++ around to allow people to use a factory without the boost "overhead", but it's not going into boost. Instead, I will talk to Federico (that name sounds familiar from somewhere...) and see whether I can help out developing boost::factory. -------------------- PV: This would be very much welcomed. PV: Hopefully this library will make it into review. /Pavel
participants (2)
-
martin f krafft
-
Pavel Vozenilek