From: "David B. Held" <[EMAIL PROTECTED]> > "Peter Dimov" <[EMAIL PROTECTED]> wrote in message > 009f01c2c6d7$91024ab0$1d00a8c0@pdimov2">news:009f01c2c6d7$91024ab0$1d00a8c0@pdimov2... > > [...] > > The first question, of course, is: do you really need SmartPtr<...> to > > support move semantics (in current C++)? > > Why wouldn't you want that?
:-) You can use this argument for any feature. But you can't include all features. > At the very least, it seems like a glaring > omission to create a smart pointer framework that can't even emulate > auto_ptr<>. It depends on what your design goals are. If you want to create the One True Smart Pointer Design, then yes, auto_ptr<> emulation is a must. 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.) :-) > 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? Also note that I said "in current C++" (that's rather move semantics unfriendly.) Given language support for move (N1377 for example), it would make perfect sense to extend SmartPtr with move semantics, of course. http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
