From: "David B. Held" <[EMAIL PROTECTED]> > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message > 001901c2c6ea$e2576360$1d00a8c0@pdimov2">news:001901c2c6ea$e2576360$1d00a8c0@pdimov2... > > [...] > > You can use this argument for any feature. But you can't include all > > features. > > Watch me try. Did you want that sink in any particular color? ;)
Nope, but I want my sink strongly exception safe; the pointer should be deleted when a policy constructor throws. While you're at it, make the sink support deep const (for deep copies, for example.) More support for almost_default_storage_but_with_this_deleter would be nice to have, too. Apologies if the above issues have been addressed two years ago. I'm not familiar with the latest & greatest SmartPtr. ;-) > > If, on the other hand, you want to create the Design That Solves > > Common User Needs, auto_ptr<> emulation isn't high on the list. > > If I need auto_ptr I know where to find it, and nobody I know has > > ever written an auto_ptr (amusement aside.) :-) > > The point is, auto_ptr<> has fixed semantics. We don't want to > touch the base semantics, which involve move, of course. We simply > want to allow the user to do a few extra things with auto_ptr<> that > she cannot do with std::auto_ptr<> without having to roll her own > version, no matter how much fun that might be. ;) Yes, I understand that, but do you know of a user that needs an almost_auto_ptr? ;-) > > > Beyond that, it seems that there are resources that would > > > benefit from or outright require move semantics to work properly, > > > and why wouldn't you want to let SmartPtr<> manage those? > > > > Interesting question. Do you have an example? > > You would call me on that, wouldn't you? Ok, I can't think of a > resource that would *require* move semantics (which is why I didn't > mention one in the first place, but I hoped maybe someone more > imaginative than I would pipe up with an example ;). However, it still > seems that move semantics would be useful in a std::vector<>. You > might know that the vector holds the only pointers to the resources, > and resizing the vector does not incur the overhead of modifying a > bunch of counts. 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. Your memory is failing you, by the way. ;-) http://lists.boost.org/MailArchives/boost/msg29886.php http://lists.boost.org/MailArchives/boost/msg29925.php A "move lock" is a good example of a resource that requires move semantics. But the main problem with the current move solution is that a move-enabled member doesn't make the enclosing class moveable, and the amount of work required to make the wrapper moveable is pretty much constant regardless of whether the members are move-enabled. 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost