Re: Constrained Forwarding(R-Value Reference)
On Feb 28, 6:13 pm, grizl...@yandex.ru ("Grizlyk") wrote:
1. No auto_ptr support.
=======================
It is intended that unique_ptr be a 'fixed' version of auto_ptr:
http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html
2. No ordered definitions
for "copyable" and "moveable" C++ concepts.
==============================================
Have you checked out the concepts proposal for C++0x?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2081.pdf
I believe the combination of concepts and rvalue references will do
all you're suggesting. (I don't know if there are concrete proposals
for concepts to do with move semantics, yet - I seem to remember
seeing some).
We want to use "move constructor" as well as "copy constructor", that is why
we are forced to mark variable to define what kind of constructor must be
used to create new value. Consider:
template<class type>
//parameter: moveable variable passed by value
type@ foo(const type @param)
{
type a; //default ctor used
type @b; //the same as a
type c(param); //copy ctor used if exist else error
type @d(param); //move ctor used
type @e(param); //error - double move
return d; //move ctor used
}
It's not clear exactly what you're trying to do, but as far as I can
tell, in C++0x this is likely to look something like
template <Movable type>
type foo(type&& param)
{
type a, b;
type c(param); // compile-time error if param not copyable
type d(std::move(param));
type e(std::move(param)); // not a compile-time error in C++0x
return std::move(d);
}
So, the substantive difference between what you suggest and the rvalue
reference proposal is about whether to make double-move a compile-time
error somehow. The consensus seems to be that the disadvantages
outweigh the advantages.
3. "Value" is not the same as "reference".
==========================================
In your example one have declared constructor for r-value reference
ref> // move semantics
ref> clone_ptr(clone_ptr&& p)
ref> : ptr(p.ptr) {p.ptr = 0;}
Look, it is really consructor of new instance from non-const one. But word
"reference" means "do not make new copy".
Note that 'clone' means 'copy'. I think with that in mind, you'll
understand the example.
4. "Non-const" is not the same as "moveable".
=============================================
In the rvalue reference proposal, moving is explicit (using
std::move), except from temporaries (rvalues).
5. What if parameter can not be passed by reference?
====================================================
As i have said, the ownership from auto_ptr can not be transferred more than
one time.
In order compiler take the correct ownership transferring under control,
lifetime of auto_ptr must be limited by local scope or anyway compiler must
trace creation and erasing any object of auto_ptr class.
That is why auto_ptr often _can not be passed by any reference_.
We'll have unique_ptr; it will not normally be passed by reference,
like auto_ptr today.
6. Interaction "copyable" and "moveable".
=========================================
Today we have only copyable/non-copyable support, that looks like boolean
type. But adding new property as moveable gives to object one of the
following ordered property: non-copyable/moveable/copyable.
And here we must define strict rules also ("functions expecting moveable
value can use copyable value" and so on).
I think if you study the rvalue reference proposal, you'll find all
this is covered. It does seem you are criticising without having taken
the time to understand what is being proposed.
James
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]