Does frameworks allow move semantics unconditionally?

[Alex Merry]

On Thursday 30 July 2015 20:46:24 Mark Gaiser wrote:
> On Thu, Jul 23, 2015 at 9:59 PM, Mark Gaiser <markg85 at gmail.com> wrote:
> > Hi,
> > 
> > The wiki page doesn't state it explicitly [1].
> > 
> > The status of move semantics when searching for the status of N3053 on the
> > compilers that frameworks support:
> > GCC 4.6 [2] (frameworks requires 4.5)
> > CLANG 3.0 [3] (frameworks requires 3.1)
> > Visual Studio 2010/2012 [4] (it has some (most?) move semantics with N3053
> > being implemented in 2015. But has it enough till 2012 for normal move
> > semantics? That i don't know.)
> > 
> > Allowing this unconditionally (with the exception of *this since that's
> > apparently fixed in GCC 4.8.1) seems possible since the compiler support
> > seems there and the operation - when implemented - can give quite nice
> > benefits.

Our only language constraints are what is allowed by the compilers we support.

I know that VS 2013 has most move semantics support except that the compiler 
can't generate default move constructors and move assignment operators.

The VS 2010 compiler provides rvalue references, but not always as effeciently 
as you'd like (it doesn't properly account for temporary values, if I 
understand the explanation correctly). What I'm not certain about is the 
standard library support on this front, but I think it's basically absent from 
2010 and mostly present in 2012.

So when you say "move semantics", what does that encompass? You can use rvalue 
references in 2010 just fine, but someone would need to check that Qt detects 
that properly and provides appropriate overloads of various methods, and you 
may not get std::move (if you use qMove, it will degrade properly in 
std::move's absence, though).

Alex