Re: [boost] auto_ptr/move issue
From: Howard Hinnant [EMAIL PROTECTED] Imho, standardized move syntax/semantics is very close to the top of important issues for C++. I guess that's why I'm pushing for current smart pointers to get the right syntax for move semantics. But can they get the right syntax without ? With , it's trivial. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] auto_ptr/move issue
On Friday, January 31, 2003, at 07:26 AM, Peter Dimov wrote: From: Howard Hinnant [EMAIL PROTECTED] Imho, standardized move syntax/semantics is very close to the top of important issues for C++. I guess that's why I'm pushing for current smart pointers to get the right syntax for move semantics. But can they get the right syntax without ? Close. With , it's trivial. Agreed. The right syntax for move, imho, is anything but copy syntax if the source is an lvalue. If the source is an rvalue, then copy syntax for move is not only ok, it is actually desirable. move_ptrint source(); ... move_ptrint i(source()); // move with copy syntax from rvalue, ok. move_ptrint j(i); // error, move with copy syntax from lvalue, bad! move_ptrint k(move(i)); // move with move syntax from lvalue, ok. This much can be achieved in C++98. It is not trivial, indeed it is a pita compared to how easy it should be. All you have to do is follow the auto_ptr design. Doing so does not get you all of the nice things that a language driven move would get you (like movable objects in general, containers that can hold non-copyable but movable objects, etc.). But you *can* get away from moving with copy syntax from lvalues! I presented code under the thread SmartPtr (Loki) - auto_ptr/move c'tor issue on Jan. 28 which does this. For easy reference, here is the code again, slightly improved: http://home.twcny.rr.com/hinnant/Utilities/move_ptr This move_ptr example also provides array support, but names it move_ptrT[] instead of move_ptr_array. This is a separate issue and has nothing to do with getting the right syntax for a move ptr. So you can just ignore that part if your platform doesn't support pts. -Howard PS: There are no copyrights on this code sample, that is intentional. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] auto_ptr/move issue
At 06:24 PM 1/30/2003, Howard Hinnant wrote:
On Tuesday, January 28, 2003, at 11:19 PM, Greg Colvin wrote:
My problem with auto_ptr isn't so much the semantics, which
have proved useful and are probably the minimum needed to
solve the problem that the committee wanted solved. And it
isn't so much the move as copy syntax that Howard dislikes.
I just read in a newsgroup post today:
I tried to apply predicate version of std::sort algorithm to vector
auto_ptrMyClass using my predicate. Sometimes, some of auto_ptr loses
the ownership while sorting. What is happening?
Now we all know that vectorauto_ptrMyClass won't compile, so this really
shouldn't be a problem.
But it still IS a problem, because this does compile:
Sigh...
To be clear, I'll be happy to see a better syntax
in the next standard -- auto_ptr was the best we
could do with the syntax we had, but ...
#include the proper stuff
void foo()
{
auto_ptr MyClass ia[100];
... fill ia
std::sort(ia, ia+100, the_proper_predicate);
}
This may even do the right thing. Or it may leave an auto_ptr moved into a local
inside of sort, never to be heard from again. And the reason is that sort thinks it
can copy an element from the range into a local temporary with:
T partition = *median;
If T is auto_ptr, this does a move instead of a copy, with the result that the range
to be sorted now no longer contains all of the elements that were supposed to be
sorted. The committee recognized this danger in 1996, and redesigned auto_ptr so
that it would not compile if put into a std::container. However, you can still put
auto_ptr into a raw array, and you can still use std::algorithms on raw arrays.
auto_ptr still presents a danger because it moves with copy syntax. A better
solution is to move with syntax other than copy so that code like foo() shown above
will fail at compile time, instead of at run time (or if it does compile, will run
correctly).
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] auto_ptr/move issue
On Thursday, January 30, 2003, at 08:53 PM, Greg Colvin wrote: Sigh... To be clear, I'll be happy to see a better syntax in the next standard -- auto_ptr was the best we could do with the syntax we had, but ... Agreed on all points. And glad to have your continued support for a better tomorrow (which you have expressed repeatedly, not just now). I like to think of auto_ptr as a bright headlight into the future. I have learned so much from it. Imho, standardized move syntax/semantics is very close to the top of important issues for C++. I guess that's why I'm pushing for current smart pointers to get the right syntax for move semantics. Thanks, -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
