[review] Fast track review of Boost.Utility/Singleton - rejected for now
Hi all, We've gotten a lot of feedback on the Boost.Utility/Singleton. It's clear that such an addition would be beneficial to Boost, but I've chosen to reject the library at this time. Summary: - 4 positive reviews - 4 negative reviews Phil Endecott - yes Nat Goodspeed - yes Dherring[@]ll[]mit[]edu - yes Ingolf Steinbach - yes Anthony Williams - no Gennady - no Pierre-Jules Tremblay - no Michael Marcin - no The main concern was that the library is not flexible enough, and that it imposes too many things on the users (like, if BOOST_HAS_THREADS is defined, the singleton is automatically thread-safe). I would like to see this into Boost, so I hope Tobias will update the library, given all this feedback, and I would suggest another review in 2-3 months. I'd like to be the review manager then as well, if Tobias will still want me. Suggestions: * Should use policies to specify creation/destruction, access to singleton, resurection For creation/destruction, one should be able to have singleton<single_thread<T> >, singleton< synchronized<T> >, singleton< thread_specific<T> > * example for DLL support * more detailed docs As for the next review of the library, I will talk to Tobias, and let the review wizard know. Thanks to Tobias, for the lib, and to all that participated to the review! Best, John - Review Manager - -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
These are very sad news. I started to use it in my current project and am highly satisfied with it for my current needs. I hope that the interface (accessing the singleton) would remain the same. With Kind Regards, Ovanes On Jan 29, 2008 1:03 PM, John Torjo <john.groups@torjo.com> wrote:
Hi all,
We've gotten a lot of feedback on the Boost.Utility/Singleton. It's clear that such an addition would be beneficial to Boost, but I've chosen to reject the library at this time.
Summary: - 4 positive reviews - 4 negative reviews
Phil Endecott - yes Nat Goodspeed - yes Dherring[@]ll[]mit[]edu - yes Ingolf Steinbach - yes Anthony Williams - no Gennady - no Pierre-Jules Tremblay - no Michael Marcin - no
The main concern was that the library is not flexible enough, and that it imposes too many things on the users (like, if BOOST_HAS_THREADS is defined, the singleton is automatically thread-safe).
I would like to see this into Boost, so I hope Tobias will update the library, given all this feedback, and I would suggest another review in 2-3 months. I'd like to be the review manager then as well, if Tobias will still want me.
Suggestions: * Should use policies to specify creation/destruction, access to singleton, resurection For creation/destruction, one should be able to have singleton<single_thread<T> >, singleton< synchronized<T> >, singleton< thread_specific<T> > * example for DLL support * more detailed docs
As for the next review of the library, I will talk to Tobias, and let the review wizard know. Thanks to Tobias, for the lib, and to all that participated to the review!
Best, John - Review Manager -
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ovanes Markarian wrote:
These are very sad news. I started to use it in my current project and am highly satisfied with it for my current needs. I hope that the interface (accessing the singleton) would remain the same.
Do you mean just the function name, or more? Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
I mean the idea of defining the singleton type struct my_singleton : boost::singleton<my_singleton> { ... void DoSmth()const; ... }; And the more important now, the possibility to access it: my_singleton::instance->DoSmth(); I found it extremely useful to be able to overload the operator -> for accessing the singleton members and may be doing smth. meaningful before and after accessing the member, e.g. monitoring. I was going to write a review, but somehow missed it... IMO I would like to have this lib in Boost (would give my YES vote). Controlling the multi-threaded creation handling via BOOST_HAS_THREADS can be nice by default, but should also be possible to finetune it without redefining macros or including singleton headers before this macro was defined. So I would prefer smth. like this: #ifdef BOOST_HAS_TREADS # define BOOST_SINGLETON_DEFAULT_LOCKING_POLICY boost::singleton_default_locking #else # define BOOST_SINGLETON_DEFAULT_LOCKING_POLICY boost::singleton_no_locking #endif namespace boost { template<class Derived, class LockingPolicy=BOOST_SINGLETON_DEFAULT_LOCKING_POLICY> struct singleton { ... }; } After all I can write: struct my_singleton : boost::singleton<my_singleton> {}; Or if I really want to control locking policy: struct my_singleton : boost::singleton<my_singleton, no_locking> {}; I would not like using "macro interface" to control the locking policy of the singleton. As well as it is not always so that if my app has threads I need lockable singleton. I agree that might be needed for shared_ptr to make safe locks, since it might be used in some "local" thread somewhere in the app, but if I for sure know that my singlegon will be instantiated in main() before any threads will start running and that it will be a read-only singleton, I don't need locking. Many thanks, Ovanes On Jan 29, 2008 3:14 PM, John Torjo <john.groups@torjo.com> wrote:
Ovanes Markarian wrote:
These are very sad news. I started to use it in my current project and am highly satisfied with it for my current needs. I hope that the interface (accessing the singleton) would remain the same.
Do you mean just the function name, or more?
Best, John
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
John Torjo -
Ovanes Markarian