Re: Constrained Forwarding(R-Value Reference)
Pedro Lamar?o wrote:
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?
With the help of Howard Hinnant and others Russell Yanofsky has
produced a modified GCC 4.3 with support for Rvalue References.
You can download the source code here:
http://russ.yanofsky.org/rref/
Based on his work I have a partial implementation of the
Recommendations for the Standard Library, including Howard's
implementation of unique_ptr and optimizations for string, vector and
deque.
You can download my patch here:
http://mndfck.org/~pedro.lamarao/projects/c++0x/libstdc++-v3.patch
Care to provide an example program that exhibits this fundamental
failure you keep mentioning?
Nice answer. Are you offering to write own patch for GCC 4.3 myself to
support "moveable concept"?
The existence of the implementation is really interesting thing, but I do
not argue, that can be many kind of possible implementation of "moveable",
but i only think, that "r-value reference" is one of the irregular one.
So i more expect answers about problems, detected in "r-value reference",
which can not be avoided by any implememtation even in theory, not only in
GCC 4.3.
Maybe I am not right, but sometimes I think, that "r-value reference" has
appeared from the idea: "sign '&&' exist, but never used" :). Speaking
seriously, "r-value reference" does not solve problem of "safe moveable"
("compile time double move detection"), does not make differences between
"non-const" and "moveable", makes strange for C++ and unexplainable in
theory mixing "value" and "reference" terms and so on.
I can repeat, unexplainable because no one can invent replacement for two
diffrent types of data ("value" and "reference") by one type of data called
"special reference":
in the first example "p", declared as "clone_ptr&&", has been passed by
reference (only address of "p" used):
ref> // move semantics
ref> clone_ptr(clone_ptr&& p)
ref> : ptr(p.ptr) {p.ptr = 0;}
but in second example "return type of foo", declared as "clone_ptr&&",
already will be returned by value (address of "p" can not be used)
clone_ptr&& foo()
{
clone_ptr p;
return p;
}
The both different kind of operation is expressed by the same "clone_ptr&&"
declaration and function, returning value, declared exactly as constructor,
obtaining reference. It is wrong, because looking on declaration
"clone_ptr&&" it is impossible to understand what exactly will be done.
I very, very, very long time (long for so simple stuff) even can not
understand (probably still can not understand) what the "r-value reference"
is going to do, because its behaviour contradicts to all other C++
conventions without any reasons.
Looking from "regular moveable concept" side, I think the "r-value
reference" supports only "moveable value" rather than "moveable reference".
I think, that the source of the "r-value reference" error is based on the
fact, that during creating of "r-value reference" idea, its author was
working closely only with copy constructors, but in copy constructor we can
not use value, only reference, so in copy constructor the problem is hidden
and can be overlooked. If building of "r-value reference" idea has been
started from considering general functions instead of copy constructors, the
"r-value reference" never has been appeared in the world.
--
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 ]