Re: Constrained Forwarding(R-Value Reference)
Grizlyk wrote:
James Dennett wrote:
He has asked me how it can be implemented with my proposal. Try open
http://grizlyk1.narod.ru/cpp_new and find there words "lvalue". Really,
lvalue/rvalue has ablsolutely no any sense in context of data type.
"Lvalue" means "address can be taken" and nothing more.
"Lvalue" is unrelated to "const", "copyable" or "moveable" data type.
The relationship is something that exists and has been
considered in quite a lot of detail.
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.
You misstate me. The fact that the relationship has
been discussed in much detail, and that the details
are significant, specific and reasonable, is very,
very strong evidence for its existence. If you wish
to claim, in spite of such evidence, that there is no
connection, you need to refute this somehow.
Then i have said, that
Any term, binding several objects, as relationship do, of course can be
considered for any combinations of any objects.
So we always can consider any term, binding several objects, and consider in
quite a lot of detail.
That is not true; if there is no significant relationship,
there is no significant detail to consider.
For example, we can consider
question about any relationships between C++ and rain in any desert.
But we would not reasonably be able to consider it
"in detail", as there is no significant relationship
between C++ and weather in some specified geographical
region.
It does not matter here "reasonably" or not, it is only important that we
can do consider any term, binding any several objects.
Reasonableness is very important. If you do not consider
reasonableness as a crucial factor in discussions, it is
unlikely that your discussions will be fruitful.
But the possible ability of consideration is not the same, that the
considered term can be applied to binding the concrete combination of the
concrete 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).
That would be most unhelpful. It is not consistent to say
that there is a relationship and that the items have no
relationship. This is a self-contradictory use of
terminology, which is why precision in terminology is
vital in these discussions.
For example, there are no any relationship between C++
and rain in any desert.
Right, so that would not be a useful thing for us to
discuss.
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.
That is untrue. I do not agree with that, and I have
never stated anything to suggest that I do.
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".
This "argument" does not seem to be based on logic.
So original sentence: "there are no any relationship between "Lvalue" and
"const", "copyable" or "moveable" data type" is correct statement at
least
formally.
How can it be correct
_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.
I have not agreed with you, and it is not correct.
Again, a false premise (that I have agreed with you)
leads to a false conclusion (that your statement
was factually correct). Reasoning from valid
premises, using logic, will be much more likely
to avoid reaching false conclusions.
when others have supplied specific
details of the concrete relationship that exists between
rvalues and movability?
As i can guess, you does not agree with concrete _form of relationship_: i
think "unrelated", you think "related".
If there is a relationship, they are related. This is what
the words mean in English.
There are differences between "rvalues", "movability" and "moveable data
type".
Yes, obviously.
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.
With our normal definitions of the terms, this is not
true. Maybe you are using other definitions?
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]
What do you aim to illustrate with this 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;
}
Even C++98 avoided the need to copy in that case. Are you
proposing a move backwards from RVO?
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;
}
What is the motivation for this? What benefit does it
have over the current wording for C++ with rvalue
references?
I'm afraid I lack the time to respond to the rest of your
post. There's a lot of material, and each small part takes
a long time to try to understand, and even then I am largely
unsuccessful in working out what you could mean. Maybe
others will do better, or maybe you can work out a way to
translate your ideas more conventionally?
-- 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 ]