Re: Constrained Forwarding(R-Value Reference)

Howard Hinnant wrote:


Hello.

1. No auto_ptr support.
=======================

I agree, that any kind of move semantic support is useful in C++ as itself,
but we have a special requirements to select concrete forms of the move
semantic support. One of the important requirements is all what we need for
implementation of auto_ptr idiom as fast and effective manager of dynamic
memory, because auto_ptr is using move semantic to pass ownership.

The auto_ptr is RAII memory wrapper and can be implemented as free-standing
class with very light methods and its internal state has only one POD
pointer. It is really one of the most effective wrappers that is why
auto_ptr idiom is attractive and we are speaking about it here.

I can say, that in present days any auto_ptr implementation without
appearance of special C++ improvements (the improvements have been directed
exactly to support auto_ptr idiom) can be described as "elbow is close, but
to not bite", only teeth clattering in vain.

In the http reference (you have published here) one have written:

ref> Rvalue references allow programmers to avoid logically unnecessary
ref> copying and to provide perfect forwarding functions.
ref>
ref> It turns out that the combination of rvalue references
ref> and lvalue references is just what is needed to easily
ref> code move semantics.

and move semantic have introduced "in general" there, without taking into
account the concrete auto_ptr requirements. The target of auto_ptr support
is not listed there and as i can understand after reading, the published
general form of move semantic unfortunatelly is not suitable for auto_ptr,
because can not help us to write safe auto_ptr implementation.

So do we need the C++ movable that can not support even auto_ptr? I think
no. The "r-value reference" is good, but not enough. I will try to explain
it below.

2. No ordered definitions
   for "copyable" and "moveable" C++ concepts.
==============================================

One have said

ref> Rvalue references is a small technical extension to the C++ language

The "small extension" is impossible for "moveable". We need "copyable" and
"moveable" concepts integrated to C++ completely.

As I know, today C++ has no strict definition for copyable and moveable
objects. That is why one thinks that non-const copy constructor T(T&) is
suitable for copyable objects, other does not agree and does think, that
moveable must be always declared as non-const, so thinks that non-const copy
constructor T(T&) probably is suitable for moveable objects.

The kind of "undefinined behaviour" and confusions must be eleminated.

See page http://grizlyk1.narod.ru/cpp_new/index.htm#14 about the problem
(the page is under construction so can be changed in future without
advertisements).

Also you can see my thread "How to describe any type of parameter passed to
function" in the group. The thread is enumerating some questions, what must
be answered. Really, I can not answer to the questions after have read http
reference published by you, maybe information is not enough or I do not know
something unrelated to r-value reference?

For example, try to use your r-value reference to express the following
statements (the sign "@" has been randomly taken only to define moveable
type):

//copyable variable
type var;
//moveable variable
type @var;

//reference to copyable variable
type &var;
//reference to moveable variable
type & @ var;

//parameter: copyable variable passed by value
void foo([const] type name);
//parameter: moveable variable passed by value
void foo([const] type @name);

//parameter: copyable variable passed by reference
void foo([const] type& name);
//parameter: moveable variable passed by reference
void foo([const] type& @name);

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
}

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".

clone_ptr a;
//due to "reference" we are expecting "b" is the same as "a"
//but b is kind of copy of a
clone_ptr&& b(a);

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"?

4. "Non-const" is not the same as "moveable".
=============================================

One have used non-const parameter:

ref> clone_ptr(clone_ptr&& p)

But moveable is special case of "mutable" and often moveable must be called
as "once" rather than "non-const". The most important thing is that only
knowledge that a variable is non-const can not help us to safe work with the
kind of moveable.

Example of the behaviour is of course auto_ptr implementation. The ownership
from auto_ptr can not be transferred more than one time (_independently from
const attribute_).

See page http://grizlyk1.narod.ru/cpp_new/index.htm articles #11-#15 about
the C++ improvement for safe usage of the kind of moveable (the page is
under
construction so can be changed in future without adverticements).

Probably we can find in future other requirements for moveable and copyable,
so i think the best way to do moveable support - to make implementation of
moveable concept for C++ "in general" - as well completely integrated to
C++, as copyable can be done.

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 must
pass the auto_ptr to functions only by value. In order to do it we need to
get control (at least disable/enable) for each possible way in which
parameter can be passed to function (for example declaring some members of
class as public/protected).

See the same articles http://grizlyk1.narod.ru/cpp_new/index.htm#15 about
it.

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).

--
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 ]