Re: Constrained Forwarding(R-Value Reference)
tasjaevan@gmail.com 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
You can call auto_ptr as unique_ptr, but the question remains: unique_ptr
can not be safe implemented with the help of "r-value reference" and i have
tryed to explain it in my previous post with the help of 6 points of
disagreement.
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).
I do not need any beleif here and more - i have tryed to explain it in my
previous post with the help of 6 points of disagreement.
By the way, the previous considered definition of the "r_value reference" is
completed and does not require any extra definitions in addition to use the
"r_value reference". So it is enough to see that the "r_value reference" can
not be improved by any other definitions.
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,
What concrete line of the code above have made confusions?
but as far as I can tell,
in C++0x this is likely to look something like
template <Movable type>
type foo(type&& param)
Probably you want to say
type&& foo(type&& param)
else in return statement:
return std::move(d);
you can not return like this in C++, because you target is "type value", but
"std::move(d)" returns "move_return_type value", so we need cast here and
the return expression will be unrolled in C++ to
type temporary(std::move(d)); //constructor "type(move_return_type&)"
return temporary; //error "type" is not copyable
{
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
The three lines above are constructors of class "type" and expression "type
d(std::move(param))" uses constructor "type(move_return_type&)".
We of course can _not_ use the trivial explicit cast for moveable in
practial cases, because we often need _implicit_ return value without
explicit "std::move" ( more - auto_ptr(unique_ptr) require to have a
kind of _implicit, hidden_ constructor to pass ownership ).
We need to say
type&& d(param);
type&& e(param); // not a compile-time error in C++0x
and we need assuming that for the two lines above due to "type&&" will be
called any kind of constructor "type(const type&&)" instead of "type(const
type&)".
return std::move(d);
Probably you want to say
return 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.
Any could call "moveable value" as "r-value reference", but we can not
invent any language stuff for "moveable value" better than total
integration of "moveable" attribute into language, similar to constness (see
below).
Do we need to explode all ordinary names, rules and conventions in C++ to be
compatible with "r-value reference" (in ordinary value sense (not in
reference sense)) instead of to be compatible with "moveable" attribute?
Note, "moveable" attribute do not require the mistery.
Probably "r-value reference" is useful to be reference to rvalue, but
useless to be substitute of "moveable value".
So you see that not only "double-move detection at compile-time" is
disagreement, and other 5 marked points of disagreement have been posted by
me in previous post also prove it.
By the way, I want to say, that "double-move detection at compile-time" is
so important thing for "practical programming with moveable" as well as
"assignment to const compile time detection". Without "double-move detection
at compile-time" programming with "moveable" is dangerous.
I think the source of problem is due to C originally has no "moveable
concept" only "copyable" and for "copyable" the "move" and "destroy" is
simultaneous operations, unlike "moveable", "copyable" normally can not be
accessable during incorrect sate.
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.
Can not be any "in mind". Either an expression do copy/move value or do not
and using reference (address) to other object instead. It can not be joined
or mixed.
I do not know why we must call "moveable value" as "reference" - it is
only point of confusions. And if "moveable value" is "reference"
then what is "moveable reference"?
If assuming that "r-value reference" is "mobeable value" (ugly assuming)
then for "mobeable reference" must we use ordinary reference? We can not
use "reference to copyable" as "reference to moveable", because we lost
information about moveable restrictions in functions that take reference (we
can not express with "r-value reference" that function expect reference only
to copyable or only to moveable).
It is evidently, "moveable" is the same "limiter" as "const", you can not
invent any kind of simple "const-value reference" to express constness and
for the "moveable" also can not. If you do not like sign "@" use word
"moveable", similarly to word "const", so for previouse example can be like
this:
template<class type>
//parameter: moveable variable passed by value
type moveable foo(const type moveable param)
{
type a; //default ctor used
type moveable b; //the same as a
type c(param); //copy ctor used if exist else
error
type moveable d(param); //move ctor used
type moveable e(param); //error - double move
return d; //move ctor used
}
4. "Non-const" is not the same as "moveable".
=============================================
In the rvalue reference proposal, moving is explicit (using
std::move), except from temporaries (rvalues).
Do you agree that "non-const" is not the same as "moveable" or not? If not
try to prove your opinion.
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.
What kind of language/unique_ptr features protect us from passing unique_ptr
by reference?
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.
I wanted to say If we will add normal "moveable" attribute, we are forced to
declare the strict interaction rules also.
The "rvalue reference" is partially substituting the "moveable" attribute,
so the thing can not be good covered by any other complete attribute, the
"rvalue reference" is one of the irregular stuff in C++.
It does seem you are criticising without having taken
the time to understand what is being proposed.
I think the better way to be right is just prove that concrete arguments of
your opponent is incorrect, without any abstract suspicions or abstract
references. I have post tons of _concrete_ examples on the page
http://grizlyk1.narod.ru/cpp_new articles #11-#15.
The _concrete_ examples show that "r-value reference" can not be used, that
with the help "r-value reference" it will be impossible to implement safe
moveable in general (and concrete simplest case as auto_ptr (uniq_ptr)
also ) in C++ even in theory. Can you say any _concrete_ against the
_concrete_ examples?
Outcome:
I know, there are many peolple who are happy to have even current
std::auto_ptr implementation. I do not argue, as they wish, but just let's
include into language all necessary features to make moveable classes
implementation is possible and all other people could make own classes under
own conditions.
--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new
---
[ 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 ]