Retornando unique_ptr das funções

unique_ptr<T>não permite a construção da cópia, mas suporta a semântica de movimentação. No entanto, posso retornar a unique_ptr<T>de uma função e atribuir o valor retornado a uma variável.

#include <iostream>
#include <memory>

using namespace std;

unique_ptr<int> foo()
{
  unique_ptr<int> p( new int(10) );

  return p;                   // 1
  //return move( p );         // 2
}

int main()
{
  unique_ptr<int> p = foo();

  cout << *p << endl;
  return 0;
}

O código acima compila e funciona como pretendido. Então, como é que essa linha 1não invoca o construtor de cópia e resulta em erros do compilador? Se eu tivesse que usar a linha 2, faria sentido (usar a linha também 2funciona, mas não somos obrigados a fazê-lo).

Eu sei que o C ++ 0x permite essa exceção, unique_ptrjá que o valor de retorno é um objeto temporário que será destruído assim que a função sair, garantindo assim a exclusividade do ponteiro retornado. Estou curioso para saber como isso é implementado, é especial no compilador ou há alguma outra cláusula na especificação de linguagem que isso explora?

existe alguma outra cláusula na especificação da linguagem que isso explora?

Sim, veja 12.8 §34 e §35:

Quando certos critérios são atendidos, uma implementação pode omitir a construção de copiar / mover de um objeto de classe. [...] Essa elisão de operações de copiar / mover, chamada cópia elision , é permitida em uma declaração de retorno em uma função com um tipo de retorno de classe, quando a expressão é o nome de um objeto automático não volátil com o mesmo tipo não qualificado de cv que o tipo de retorno de função [...]

Quando os critérios para a elisão de uma operação de cópia são atendidos e o objeto a ser copiado é designado por um lvalue, a resolução de sobrecarga para selecionar o construtor da cópia é executada primeiro como se o objeto tivesse sido designado por um rvalue .

Só queria acrescentar mais um ponto de que o retorno por valor deve ser a opção padrão aqui, porque um valor nomeado na declaração de retorno, na pior das hipóteses, ou seja, sem elisões em C ++ 11, C ++ 14 e C ++ 17, é tratado como um rvalue. Por exemplo, a função a seguir é compilada com o -fno-elide-constructorssinalizador

std::unique_ptr<int> get_unique() {
  auto ptr = std::unique_ptr<int>{new int{2}}; // <- 1
  return ptr; // <- 2, moved into the to be returned unique_ptr
}

...

auto int_uptr = get_unique(); // <- 3

Com o sinalizador definido na compilação, há dois movimentos (1 e 2) acontecendo nessa função e depois um movimento mais tarde (3).

Isso não é de forma alguma específico std::unique_ptr, mas se aplica a qualquer classe que seja móvel. É garantido pelas regras de idioma, pois você está retornando por valor. O compilador tenta excluir cópias, chama um construtor de movimentação se não pode remover cópias, chama um construtor de cópia se não pode mover e falha na compilação se não pode copiar.

Se você tivesse uma função que aceite std::unique_ptrcomo argumento, não seria capaz de passar p para ela. Você precisaria invocar explicitamente o construtor move, mas nesse caso não deve usar a variável p após a chamada para bar().

void bar(std::unique_ptr<int> p)
{
    // ...
}

int main()
{
    unique_ptr<int> p = foo();
    bar(p); // error, can't implicitly invoke move constructor on lvalue
    bar(std::move(p)); // OK but don't use p afterwards
    return 0;
}

unique_ptr não possui o construtor de cópias tradicional. Em vez disso, possui um "construtor de movimentação" que usa referências de rvalue:

unique_ptr::unique_ptr(unique_ptr && src);

Uma referência rvalue (o duplo e comercial) será vinculada apenas a um rvalue. É por isso que você recebe um erro ao tentar passar um lvalue unique_ptr para uma função. Por outro lado, um valor retornado de uma função é tratado como um rvalue, portanto, o construtor de movimentação é chamado automaticamente.

A propósito, isso funcionará corretamente:

bar(unique_ptr<int>(new int(44));

O unique_ptr temporário aqui é um rvalue.

Eu acho que é perfeitamente explicado no item 25 do Effective Modern C ++ de Scott Meyers . Aqui está um trecho:

A parte da bênção padrão do RVO continua dizendo que, se as condições para o RVO forem atendidas, mas os compiladores optarem por não executar a remoção da cópia, o objeto retornado deverá ser tratado como um rvalor. Com efeito, a Norma exige que, quando a RVO for permitida, a elisão da cópia ocorra ou std::moveseja aplicada implicitamente aos objetos locais que estão sendo devolvidos.

Aqui, o RVO se refere à otimização do valor de retorno e, se as condições para o RVO forem atendidas, significa retornar o objeto local declarado dentro da função que você esperaria executar o RVO , o que também é bem explicado no item 25 de seu livro, consultando o padrão (aqui o objeto local inclui os objetos temporários criados pela instrução de retorno). A maior retirada do trecho é a remoção da cópia ou std::moveé aplicada implicitamente aos objetos locais que estão sendo retornados . Scott menciona no item 25 que std::moveé aplicado implicitamente quando o compilador decide não excluir a cópia e o programador não deve fazê-lo explicitamente.

No seu caso, o código é claramente um candidato ao RVO , pois retorna o objeto local pe o tipo de pé o mesmo que o tipo de retorno, o que resulta em elisão de cópia. E se o compilador optar por não excluir a cópia, por qualquer motivo, std::moveteria entrado em ação 1.

Uma coisa que eu não vi em outras respostas éPara esclarecer outras respostas, há uma diferença entre o retorno de std :: unique_ptr que foi criado dentro de uma função e um dado a essa função.

O exemplo pode ser assim:

class Test
{int i;};
std::unique_ptr<Test> foo1()
{
    std::unique_ptr<Test> res(new Test);
    return res;
}
std::unique_ptr<Test> foo2(std::unique_ptr<Test>&& t)
{
    // return t;  // this will produce an error!
    return std::move(t);
}

//...
auto test1=foo1();
auto test2=foo2(std::unique_ptr<Test>(new Test));