boost shared_ptr - thread safe and non thread safe editions
Hi. Is there any easy way to get a thread safe edition of the shared_ptr (BOOST_HAS_THREADS) and a "non" thread safe edition (BOOST_DISABLE_THREADS) inside the same project? The thread safe edition of the shared_ptr is a bit slower and I would like to able to use the non thread safe shared_ptr, when I known it only be used on the same thread. As a solution I thought I could do something like this, so I would not have to edit/copy any boost .hpp file : // // MyApp.cpp // #define BOOST_HAS_THREADS #include "boost/smart_ptr.hpp" namespace boost_nothread { #define BOOST_DISABLE_THREADS #include "boost/smart_ptr.hpp" } void f() { boost::shared_ptr <int> spIntTS; // thread safe smart pointer boost_nothread::shared_ptr <int> spInt; // non thread safe smart pointer } //////// The above sample does not work - what should I do instead? Regards, René
From: "René Dalby Carlsen"
Is there any easy way to get a thread safe edition of the shared_ptr (BOOST_HAS_THREADS) and a "non" thread safe edition
(BOOST_DISABLE_THREADS)
inside the same project?
No, sorry.
Is there any easy way to get a thread safe edition of the shared_ptr (BOOST_HAS_THREADS) and a "non" thread safe edition (BOOST_DISABLE_THREADS) inside the same project?
No, sorry.
Any plans for making it possible in future releases or are there some design reasons for not making it possible? Regards, René
From: "René Dalby Carlsen"
Is there any easy way to get a thread safe edition of the shared_ptr (BOOST_HAS_THREADS) and a "non" thread safe edition (BOOST_DISABLE_THREADS) inside the same project?
No, sorry.
Any plans for making it possible in future releases or are there some design reasons for not making it possible?
One of shared_ptr's design goals is to provide a common interface for library designers to use. This typically means that there must be one single shared_ptr; if there were two, library A could choose shared_ptr_1 for its interfaces, library B could choose shared_ptr_2, and they wouldn't talk to each other. Of course, a single smart pointer cannot do everything well. It was (is) expected that a policy-based smart pointer design (framework) - considered "imminent" at one time - could fill the gaps that shared_ptr cannot.
participants (2)
-
Peter Dimov
-
Ren� Dalby Carlsen