"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:4028DF54.2020303@student.umu.se...
[Me...] template <typename U, policies...> smart_ptr(smart_ptr<U, policies> const&p);
template <typename U, policies...> smart_ptr(smart_ptr<U, policies>&p);
These two c'tors are still in the code. Do you think that will interfere with the move semantics when doing a move-convert? i.e.:
No it should work as expected. This specialization forbids construction from lvalues, conversions too.
template<class U, BOOST_CONVERSION_PARAMETERS> struct cant_move_from_const< const smart_ptr<U, BOOST_CONVERSION_POLICIES>
;
I don't see how. This only gets "activated" during a call to: template <typename P> smart_ptr(P&, cant_move...<>); But, in this case: smart_ptr<Base, destructive_copy> p( smart_ptr<Derived, destructive_copy>(new Derived) ); The better match is not smart_ptr(P&) but rather smart_ptr(smart_ptr<U>&), because the latter is more specialized. This seems to totally circumvent your system. Does the conversion c'tor also need to use the cant_move device? I.e.: template <typename U, policies...> smart_ptr(smart_ptr<U, policies>&p, cant_move..); Also, I can't use these changes at all anyway right now, because even gcc 3.3.2 doesn't like it. It likes it fine if you only have move pointers. But for some reason, it instantiates the move policies during tests with non-move configurations, which I'm pretty sure is a bug in gcc that I don't have time to isolate and report right now. And if the latest gcc doesn't like it, I have little hope for other compilers. If you are interested in trying to diagnose the problem yourself, I will try to update the sandbox with my working version. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004