From -4217765832684141540 X-Google-Thread: f78e5,516d54c6ff652958,start X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!lnewsinpeer00.lnd.ops.eu.uu.net!emea.uu.net!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: grizlyk1@yandex.ru ("Grizlyk") Newsgroups: comp.std.c++ Subject: "moveable data type" in comparison with "r-value reference" Date: Wed, 21 Mar 2007 23:33:18 GMT Organization: Aioe.org NNTP Server Lines: 161 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1174520007 27014 158.152.254.254 (21 Mar 2007 23:33:27 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 21 Mar 2007 23:33:27 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-MSMail-Priority: Normal X-Received: (from fjh@localhost) by mulga.csse.unimelb.edu.au (8.13.8+Sun/8.13.8/Submit) id l2LNXI6c024540; Thu, 22 Mar 2007 10:33:18 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@mailman.ucar.edu X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:8165 Hello. I will try to continue to show differences between "moveable data type" and "r-value reference", in order to project, that even simplest kind of algorithms with moveable data type could not be implemented with the help of "r-value reference". So being refinement of copyable data type, "r-value reference" can not claim to be representation of "moveable data type" as ordinary type in C++. >"r-value reference" Page of "r-value reference" is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm Page of "moveable concept" is http://grizlyk1.narod.ru/cpp_new articles #11-#15 Copy vs Move ============ > The state of the source may be unchanged, or it may be radically > different. The only requirement is that the object remain in a self > consistent state (all internal invariants are still intact). The requirement is theoretically correct, but practically useless one, because even auto_ptr wrapper has other behaviour. Note, it is very important for auto_ptr that its state after "move" became incorrect and user must not have access to auto_ptr during incorrect state, because else we can not implement desired behaviour of auto memory substitution. Article "apperance of moveable concept" on my page http://grizlyk1.narod.ru/cpp_new#14_1 coming soon. > From a client code point of view, choosing move instead of copy means > that you don't care what happens to the state of the source. Here "copying from non-const source" and "move" are mixed. There are differences beetwen them. For "move" source state _never_ will be correct or UB, _always_ will be incorrect. It is situation that as if we can imagine "moveable" data type sharp divided into internal and external state, and "move" change placement of internal state. Source object without internal state can not exist, and we may not assign to source internal state any random value, in order to make the state "as if correct or consistent". Of course, we can imagine a kind of data type for which after "move" any other (but correct) value exist for source, but we can not demand the specific behaviour from all moveable data, originally moveable data type must has ability to turn source after "move" into incorrect state. > For PODs, move and copy are identical operations > (right down to the machine instruction level). The cause of the POD behaviour is just the fact, that POD data is copyable data type without specific implementation of "move" and instead of "move" using "copy". In comparison with moveable data type, source external state of copyable data type after "copy" _always_ remains unchanged, _never_ source state after "copy" can be changed, because we can not get two equal copies, if source will be changed after copy. Binding temporaries to references ================================= > The new reference type introduces syntax for allowing that > functionality without changing the meaning of any existing code. Yes, it is "without changing existing code" that r-value reference is trying to do, instead of introducing "moveable data type" as itself. The heroic attempt to make moveable from unchanged old code, working only with copyable, can be ironically compared with apearence of "implicit const reference T&&&" template void foo(T&&& t); here "t" is implicitly "const", because in the case foo( int(3) ); compiler can elide copy ctor to create "t" and makes perfectly forwarding. Note, introducing moveable data type will not require any changes to code working with copyable and does not change execution of the code. More on A&& =========== > The rvalue reference is a new type, distinct from the current > (lvalue) reference. I think, we must note, that difference can be only behaviour. Because semantics of term "reference" means "address", in comparison with semantics of term "value". The difference is size of memory allocated for parameter, passed to function: ( sizeof(parameter passed by any reference) == sizeof(parameter passed by pointer ) ) != sizeof(parameter passed by value ) > The most common overload set anticipated is: > > void foo(const A& t); // #1 > void foo(A&& t); // #2 > > A source(); > const A const_source(); > foo(source()); // binds to #2 > foo(const_source()); // binds to #1 This is suspicional idea to make overloading by const/non-const parameter, it can be place of vague casts and human errors. The function const A const_source(); is logical nonsence, because function must not limit returned _value_ of A for other context as "const". The construction can be allowed, but can not change "constness". Moving from local values ======================== 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". For "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). The "(r-value reference)" proposal makes type of variable is secondary, but place of code is primary condition of behaviour of variable. Article 'differences between "rvalues", "movability" and "moveable data type"' on my page http://grizlyk1.narod.ru/cpp_new#14_2 coming soon. -- 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 ]