"Peter Dimov" <[EMAIL PROTECTED]> wrote in message 004501c2c6f8$970c7400$1d00a8c0@pdimov2">news:004501c2c6f8$970c7400$1d00a8c0@pdimov2... > From: "David B. Held" <[EMAIL PROTECTED]> > [...] > Nope, but I want my sink strongly exception safe; the pointer should > be deleted when a policy constructor throws.
Hmm...that's not a bad point. A function try block should make this possible, no? > While you're at it, make the sink support deep const (for deep copies, > for example.) Don't tempt me! > More support for almost_default_storage_but_with_this_deleter > would be nice to have, too. This is a little harder...too many template c'tors. :( > Apologies if the above issues have been addressed two years ago. I'm > not familiar with the latest & greatest SmartPtr. ;-) Touche. ;) > [...] > Yes, I understand that, but do you know of a user that needs an > almost_auto_ptr? ;-) Given how often people write auto_ptr<> without writing auto_ptr<>, I'd say yes. ;> > [...] > Move semantics in general could be useful, true, but > vector<auto_ptr> isn't supported, and it seems that this is a deliberate > design decision. So was auto_ptr<> to begin with, and now we have Greg Colvin calling it an "ugly hack that needn't be replicated." Apparently, not all deliberate decisions are the best ones. ;) > Your memory is failing you, by the way. ;-) > > http://lists.boost.org/MailArchives/boost/msg29886.php > http://lists.boost.org/MailArchives/boost/msg29925.php I have shamed the family. <:( > [...] > So move-enabling SmartPtr would only help me if I use it directly. In > cases like the above, though, I'll probably want to wrap it in a dedicated > move_lock class, since a lock is a very specific kind of SmartPtr, and it > might be desirable to prevent users from passing it to functions where a > SmartPtr is expected. I dunno. A lock is also a very simple kind of SmartPtr, and it seems to me a simple typedef will have the same effect. typedef SmartPtr<my_mutex, LockPolicy, MovePolicy> SmartLock; The only way you could pass this to a SmartPtr function is if there were a conversion c'tor from LockPolicy to [SomePointerOwnershipPolicy]. If you're writing ownership policies for pointers that can be c'ted from a LockPolicy, you *ought* to be the victim of your own folly. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
