shared_ptr / auto_ptr
We've recently been evaluating a move from boost 1.38 to 1.42 [MSVC71], and we had some code that breaks down to the following: [1] struct T {}; [2] std::auto_ptr<T> ap; [3] boost::shared_ptr<T> sp = ap; Line [3] stopped compiling because of the 'explicit' introduced (in shared_ptr.hpp) at line [L] (below).
From smart_ptr/shared_ptr.hpp:
[A] template<class Y> [B] explicit shared_ptr(std::auto_ptr<Y> & r): px(r.get()), pn() [C] { [D] Y * tmp = r.get(); [E] pn = boost::detail::shared_count(r); [F] boost::detail::sp_enable_shared_from_this( this, tmp, tmp ); [G] } [H] [I]#if !defined( BOOST_NO_SFINAE ) && !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) [J] [K] template<class Ap> [L] explicit shared_ptr( Ap r, typename boost::detail::sp_enable_if_auto_ptr<Ap, int>::type = 0 ): px( r.get() ), pn() [M] { [N] typename Ap::element_type * tmp = r.get(); [O] pn = boost::detail::shared_count( r ); [P] boost::detail::sp_enable_shared_from_this( this, tmp, tmp ); [Q] } The fix is trivial, but what I am curious about is: - the 'explicit' appears to have been removed at version 1.35 (i.e. it was there at 1.34) and then re-introduced at 1.39. Is there some history to this? and - it looks like our code was falling into the second overload with 1.38 (the first overload was always explicit); with a fix it will now select the first overload, so for what case does the second overload now exist? --
Chard wrote:
We've recently been evaluating a move from boost 1.38 to 1.42 [MSVC71], and we had some code that breaks down to the following:
[1] struct T {}; [2] std::auto_ptr<T> ap; [3] boost::shared_ptr<T> sp = ap;
Line [3] stopped compiling because of the 'explicit' introduced (in shared_ptr.hpp) at line [L] (below).
...
- the 'explicit' appears to have been removed at version 1.35 (i.e. it was there at 1.34) and then re-introduced at 1.39. Is there some history to this?
"svn blame" says that the explicit has reappeared in revision 52454: https://svn.boost.org/trac/boost/changeset/52454 It references ticket #2951: https://svn.boost.org/trac/boost/ticket/2951 This is the test that was supposed to be failing but passed without "explicit": https://svn.boost.org/trac/boost/browser/trunk/libs/smart_ptr/test/auto_ptr_...
2010/2/23 Chard <boost@hazlewoods.eu>
[...]
From smart_ptr/shared_ptr.hpp:
[A] template<class Y> [B] explicit shared_ptr(std::auto_ptr<Y> & r): px(r.get()), pn()
By the way, shouldn't this constructor take std::auto_ptr by value instead of by reference. I remember being forced to introduce a local variable with the example below (was with sunstudio 12, default STL if I remember correctly). I think this was caused because you can not bind a temporary object to a non const reference. struct T {}; std::auto_ptr<T> factory(); void failedCompile() { boost::shared_ptr<T> p( factory() ); } // Needed to be modified as: void compile() { std::auto_ptr<T> temp = factory(); boost::shared_ptr<T> p( temp ); } Baptiste.
On 23 February 2010 14:55, Baptiste Lepilleur <baptiste.lepilleur@gmail.com>wrote:
[A] template<class Y>
[B] explicit shared_ptr(std::auto_ptr<Y> & r): px(r.get()), pn()
By the way, shouldn't this constructor take std::auto_ptr by value instead of by reference. I remember being forced to introduce a local variable with the example below (was with sunstudio 12, default STL if I remember correctly). I think this was caused because you can not bind a temporary object to a non const reference.
Passing the auto_ptr by value would only get us the basic exception safety guarantee, as the shared_ptr will have taken ownership, even though it might still throw before it is done constructing itself. Passing it in by reference allows us to have the strong exception safety guarantee. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
participants (4)
-
Baptiste Lepilleur -
Chard -
Nevin Liber -
Peter Dimov