Re: Constrained Forwarding(R-Value Reference)

James Dennett wrote:


As I can understand, you have said, that term "relationship" must be applied
to bind "Lvalue" and "const", because of either something exist or something
can be considered in quite a lot of detail.

Then i have said, that


So we always can consider any term, binding several objects, and consider in
quite a lot of detail.


It does not matter here "reasonably" or not, it is only important that we
can do consider any term, binding any several objects.


So I have said, that in spite of the fact, that we always can consider any
term, the existence of process of consideration is not the same, that the
considered term must be applied to binding the concrete combination of the
concrete objects.

If we have found after consideration process, that relationship is not exist
(objects unrelated), we can continue to apply the term "relationship" in the
form of "has no relationship" (unrelated).


So you have agreed with me, that "Lvalue" can be as well related (has
relationship) as unrelated (has no relationship) to "const", "copyable" or
"moveable" data type. It does not matter either can "relationship of
"Lvalue" and "const" has been considered in quite a lot of detail" or can
not in order to be able to apply "relationship" term to bind "Lvalue" and
"const".


_formally_ it is always correct, because you have agreed with me, that
"Lvalue" can be as well related as unrelated to "const", "copyable" or
"moveable" data type.


As i can guess, you does not agree with concrete _form of relationship_: i
think "unrelated", you think "related".

There are differences between "rvalues", "movability" and "moveable data
type".

Conceptually "movability" or just "moveable property" is ability of _any_
concrete object to allow to process "move" to be applyed to the object, the
property can be unrelated to the type of the object and can appear only in
one concrete _place_ of code.

Conceptually "moveable data type" is data type, that in addition to
"movability", define some other important rules of behaviour for all objects
of own types _always_.

This is important difference, because "moveable data type" related to _data
type_, but "moveable property" related to _place of code_.

The conceptual difference defines differences in behaviour for "objects of
moveable data type" and "objects only with moveable property".

The example of the difference in behaviour is RVO:

1. r-value reference FAQ
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Moving%20from%20local%20values)

[quote]
Moving from local values

A further language refinement can be made at this point. When returning a
non-cv-qualified object with automatic storage from a function, there should
be an implicit cast to rvalue:
string
operator+(const string& x, const string& y)
{
    string result;
    result.reserve(x.size() + y.size());
    result = x;
    result += y; // as if return static_cast<string&&>(result);
    return result;
}The logic resulting from this implicit cast results in an automatic
hierarchy of "move semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)
- Else if there is a move constructor, use it
- Else if there is a copy constructor, use it
- Else the program is ill formed

[/quote]

2. moveable concept as defined in http://grizlyk1.narod.ru/cpp_new

The example of "Moving from local values" will be:

a)
When returning #any# object with automatic storage from a function, there
should be an #explicit# cast to rvalue, #function must be declared
properly#:

string
operator+(const string& x, const string& y)
{
    string result;
    result.reserve(x.size() + y.size());
    result = x;
    result += y;

    //here _always_ "copy constructor"
    //never "move constructor"!
    return result;
}
The logic resulting from this #explicit# cast results in an #explicit#
hierarchy of "copy semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)

note, the question of "eliding" is unrelated to question of "data type"

- Else if there is a copy constructor, use it
- Else the program is ill formed

b)
If you need use moveable data type, function must be declared properly

moveable string
operator+(const string& x, const string& y)
{
    string result;
    result.reserve(x.size() + y.size());
    result = x;
    result += y;

    //here either "move constructor"
    //or "copy constructor"
    return result;
}
The logic resulting from this #explicit# cast results in an #explicit#
hierarchy of "move semantics" from best to worst:

- If you can elide the move/copy, do so (by present language rules)

note, the question of "eliding" is unrelated to question of "data type"

- Else if there is a move constructor, use it
- Else if there is a copy constructor, use it
- Else the program is ill formed

***

The main differences is the fact, that:

- for "moveable data type", behaviour of objects defined only by class
_declaration_ and variable _declaration_ (as any ordinary C++ type _must_
do), "moveable data type" looks like "volatile data type" or "const data
type".

- but for "moveable property(r-value reference)", behaviour of objects
defined only by concrete _place_ of usage of variable of undefined type,
_never_ by declarations (as any ordinary C++ type _never_ must do).
"(r-value reference)" makes type of variable is secondary, but place is
primary condition of behaviour of variable.

***
Co-existance of "moveable property" and "moveable data type"

In theory, "moveable property" is just limited subset of "moveable data
type", but because "r-value reference" define own behaviour, orthogonal to
behaviour of ordynary C++ data type, the both of them can co-exist
simultaneoulsy.

Consider following declaration of class string, supporting all of them:

class string
{
//copyable data type
public:
    string(const string&);
    any_type operator= (const string&);

//r-value refinement of copyable data type
public:
    string(const? string&&);
    any_type operator= (const? string&&);

//moveable data type
public:
    string(moveable const string&);
    any_type operator= (moveable const string&)ctor;

//does not define copyable data type if unhided
//can override implicit copy ctor/assignment
public:
    //compile time error
    //string(string&) is hidden by
    //string(const string&)
    string(string&);

    //compile time error
    //operator= (string&) is hidden by
    //operator= (const string&)
    operator= (const string&)

//does not define moveable data type if unhided
//can override implicit move ctor/assignment
public:
    //compile time error
    //string(moveable string&) is hidden by
    //string(moveable const string&)
    string(moveable string&);

    //compile time error
    //operator= (moveable string&) is hidden by
    //operator= (moveable const string&)
    any_type operator= (const string&)ctor;
};

I am sure - "moveable data type" is more regular and important stuff, than
"r-value reference", so if C++ can not contain both, than "moveable data
type" must be selected.


There are _no_ relationship between rvalues and "moveable data type". We can
easy imagine "conceptual moveable" as rvalue as well as lvalue.

moveable T add(const moveable T, const moveable T);

extern moveable T& src;
moveable T dst= add(src,src);

In the example above, return value of function "add" is "rvalue moveable",
but "dst" and "src" are "lvalue moveable", in spite of "src" is "reference
to moveable".


I do not argue, that "temporary objects are rvalues".

But if address of "rvalue" can be taken, then the "rvalue" has been
implicitly casted into "lvalue", because by definition of "rvalue" - address
of "rvalue" never can be taken. For CPU's opcodes "rvalue" means data is
immediate:

enum { data=3 };
    //3 -> %eax
    movl $data,%eax
here "data" is "rvalue"

int data=3;
    //3 -> %eax
    movl data,%eax
here "data" is "lvalue", we can find its address as following:
    //&data -> %eax
    leal data,%eax

The fact of non-existence of address for any "rvalue" is unrelated to the
fact that "rvalue" can not be casted into "lvalue".

I can agree, that syntax "int&&" can be used to make explicit cast of
"temporary rvalue of type int" into "reference to temporary lvalue of type
int", but the question is unrelated to moveable data type. Absolutelly
unrelated to moveable as well as RVO unrelated to moveable.

I think, it can be better to call "r-value reference" as "reference to
temporary", because semantics of "reference" assuming "lvalue", because
reference always implemented as encapsulated "const pointer".

The "r-value reference" is sounded paradoxically: "address of something,
that has no address".


I do not argue, that during temporary life time "moving from a temporary
object is generally safe".

But the fact of safe moving from temporary during temporary life is
unrelated to properties of moveable data type.

This is because "conceptual moveable" is data type, that can create new
instance from itself only by moving its internal state, insted of copying
and "conceptual copyable" is data type, that can create new instance from
itself as well by moving its internal state, as by copying.

Both "conceptual moveable" and "conceptual copyable" can be as well "lvalue"
as "rvalue" or temporary.


I will agree with "std::move" for "moveable data type" only if you will use
in your programs "std::assing" and "std::copy" for copyable. For "r-value
reference", "r-value reference" is not going to be C++ moveable data type it
does not matter.


Because you have made implicit cast rvalue to temporary lvalue. And the fact
that class is not POD type do not prevent compiler to make compile time copy
of the class as rvalue (at least it can be done in future).


Can you write example of the prevention?


There are no relationship between "conceptual moveable" and "Rvalue". To be
moveable is defined by the class declaration, never by "std::move from
lvalue".


I will agree with "std::move" for "moveable data type" only if you will use
in your programs "std::assing" and "std::copy" for copyable. For "r-value
reference", "r-value reference" is not going to be C++ moveable data type it
does not matter.


What exactly not clear? By accident means rvalue _looks_ like moveable by
accident. It is not core property of rvalue. That is just an accident,
because non-accident property of any data type can be defined _only by
declaration_, never by accident.

I think, the "r-value reference" is just not a data type, it is special set
of rules to work with copyable data type in special places of code,
unrelated to data type declaration.

The "r-value reference" never can replace ordinary moveable data type (
"r-value reference" is just limited subset of correct moveable data type and
"r-value reference" has special rules to interacts with copyable, the rules
does not dedined by class decalration ) because with the help of "r-value
reference" user never will be able to express simplest kind of algorithms
with moveable data type.

It is especially touching, when one can see, that C++ easy can support
complete moveable data type.

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