"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? ;) > > 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. I think this is a good goal. ;> > 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. ;) > > 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. > 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. I agree that native move facilities would be nice. But auto_ptr<> like move semantics have established a large historical precedent, and people find it useful enough until we get real move support, that I think it ought to be supported. Dave _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
