Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #527

Re: Moving cv-qualified objects

Show all headers | View raw

On Monday, June 4, 2012 3:28:32 AM UTC+3, Robert Powell wrote:
> <snip>
> This makes it hard to reason about, so I'm assuming that, for the sake
> of that clause, "to move an object" means to direct-initialize some
> other object by an expression that is semantically equivalent to
> 'std::move(object)'

This is a mistake, ofcourse, it should have been
'std::forward<decltype(object)>(object)'. Which brings another issue.
In the library definition, 'forward' is frequently used not only to
forward parameters, but also to conditionally move objects that aren't
lv-refs (i.e. in the move-ctor of 'tuple' or 'pair'). These are two
different uses, conceptually, and I'm not sure whether this is
intended to be seen this as a kind of forwarding, or is it merely
terseness. But if we agree that 'move' should strip cv-qulifiers, then
surely so does this. Which means, departing from 'forward' in these
cases (possibly, in favor of a dedicated 'try_move' function, or
something similiar), as 'forward' should definitely preserve
cv-qualifiers.
Jumping back to the top, defining "moving an object" in terms of
'forward' was the reading of the current standard. Utlimately, this
too should be replaced with 'try_move'.

> <snip>
>
> (Btw, what's with the rule that an implicit move-ctor is deleted if
> one of the members/bases is non-movable and has a non-trivial copy
> (12.8.12)? If some members are movable and others aren't, wouldn't the
> most obvious move-ctor move what it can, and copy the rest? Why should
> one pay for a full copy?)

I just figured that the consequences 12.8/12 are far more severe,
definitely when combined with the cv-ness issue. It seems to be
out-of-sync with other parts of the standard.

For example, 'std::pair' and 'std::tuple' both declare a defaulted
move-ctor. This means, that if one of their elements is non-movable
(in the 12.8/12 sense) the instanciation of their move-ctor is
ill-formed. This contradicts the requirements of these functions,
namely that all element types satisfy 'is_move_construbtible<T>::value
== true', which is a weaker (and more appropriate) condition. Now,
since const objects aren't movable, you're in for trouble if any of
the elements is const. 'std::map' rings a bell?
The libstdc++ folks must have noticed that, as someone left a comment
above pair's move-ctor: "Defaulted?!? Breaks std::map!!!"

--

Robert P.


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Find similar

Thread

Moving cv-qualified objects Robert Powell<robertpwell@gmail.com> - 2012-06-03 17:28 -0700
  Re: Moving cv-qualified objects Jason McKesson <jmckesson@gmail.com> - 2012-06-04 17:11 -0700
  Re: Moving cv-qualified objects Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-06-04 17:13 -0700
  Re: Moving cv-qualified objects robertpwell@gmail.com - 2012-06-04 19:11 -0600

csiph-web