Como é que uma referência não-const não pode se vincular a um objeto temporário?

Por que não é permitido obter referências não constantes a um objeto temporário, que função getx()retorna? Claramente, isso é proibido pelo C ++ Standard, mas estou interessado no objetivo de tal restrição, não em uma referência ao padrão.

struct X
{
    X& ref() { return *this; }
};

X getx() { return X();}

void g(X & x) {}    

int f()
{
    const X& x = getx(); // OK
    X& x = getx(); // error
    X& x = getx().ref(); // OK
    g(getx()); //error
    g(getx().ref()); //OK
    return 0;
}

1. É claro que a vida útil do objeto não pode ser a causa, porque a referência constante a um objeto não é proibida pelo C ++ Standard.
2. É claro que o objeto temporário não é constante na amostra acima, porque chamadas para funções não constantes são permitidas. Por exemplo, ref()poderia modificar o objeto temporário.
3. Além disso, ref()permite enganar o compilador e obter um link para esse objeto temporário e isso resolve o nosso problema.

Além do que, além do mais:

Eles dizem que "atribuir um objeto temporário à referência const prolonga a vida útil desse objeto" e "Embora nada seja dito sobre referências não const". Minha pergunta adicional . A atribuição a seguir prolonga a vida útil do objeto temporário?

X& x = getx().ref(); // OK

Neste artigo do blog do Visual C ++ sobre referências de rvalue :

... C ++ não deseja que você modifique temporariamente acidentalmente, mas chamar diretamente uma função de membro que não seja const em um rvalue modificável é explícito, portanto é permitido ...

Basicamente, você não deve tentar modificar temporários pela mesma razão de que eles são objetos temporários e morrerão a qualquer momento. A razão pela qual você pode chamar métodos não-const é que, bem, você é bem-vindo a fazer algumas coisas "estúpidas", desde que saiba o que está fazendo e seja explícito (como usar reinterpret_cast). Mas se você vincular um temporário a uma referência que não seja const, poderá continuar transmitindo-o "para sempre" apenas para que sua manipulação do objeto desapareça, porque em algum momento ao longo do caminho você esqueceu completamente que isso era temporário.

Se eu fosse você, repensaria o design de minhas funções. Por que g () está aceitando referência, ele modifica o parâmetro? Se não, faça const const, se sim, por que você tenta passar temporariamente para ele, você não se importa que seja um temporário que você está modificando? Por que getx () está retornando temporário de qualquer maneira? Se você compartilhar seu cenário real e o que está tentando realizar, poderá obter boas sugestões sobre como fazê-lo.

Ir contra a linguagem e enganar o compilador raramente resolve problemas - geralmente ele cria problemas.

---

Editar: Responder a perguntas no comentário: 1) X& x = getx().ref(); // OK when will x die?- Não sei e não ligo, porque é exatamente isso que quero dizer com "ir contra a linguagem". A linguagem diz que "os temporários morrem no final da declaração, a menos que sejam obrigados a const const, caso em que morrem quando a referência sai do escopo". Aplicando essa regra, parece que x já está morto no início da próxima instrução, pois não está vinculado à referência const (o compilador não sabe o que ref () retorna). Este é apenas um palpite, no entanto.

2) Eu declarei o objetivo claramente: você não tem permissão para modificar temporários, porque simplesmente não faz sentido (ignorando as referências de valor C ++ 0x rvalue). A pergunta "então por que tenho permissão para chamar membros não-constantes?" é bom, mas não tenho uma resposta melhor do que a que eu já afirmei acima.

3) Bem, se eu estou certo sobre x ao X& x = getx().ref();morrer no final da declaração, os problemas são óbvios.

De qualquer forma, com base em suas perguntas e comentários, acho que nem essas respostas extras o satisfarão. Aqui está uma tentativa / resumo final: O comitê C ++ decidiu que não faz sentido modificar temporários; portanto, eles não permitiam a ligação a referências não constantes. Pode haver alguma implementação do compilador ou problemas históricos também envolvidos, não sei. Então, surgiu um caso específico, e foi decidido que, apesar de todas as probabilidades, eles ainda permitirão a modificação direta através da chamada do método não-const. Mas isso é uma exceção - geralmente você não tem permissão para modificar temporários. Sim, o C ++ costuma ser tão estranho.

No seu código, getx()retorna um objeto temporário, o chamado "rvalue". Você pode copiar rvalues ​​em objetos (também conhecidos como variáveis) ou vinculá-los a referências const (que prolongarão sua vida útil até o final da vida útil da referência). Você não pode vincular rvalues ​​a referências que não sejam const.

Esta foi uma decisão deliberada de design para impedir que os usuários modifiquem acidentalmente um objeto que morrerá no final da expressão:

g(getx()); // g() would modify an object without anyone being able to observe

Se você quiser fazer isso, precisará primeiro fazer uma cópia local ou do objeto ou vinculá-lo a uma referência const:

X x1 = getx();
const X& x2 = getx(); // extend lifetime of temporary to lifetime of const reference

g(x1); // fine
g(x2); // can't bind a const reference to a non-const reference

Observe que o próximo padrão C ++ incluirá referências rvalue. O que você conhece como referências está, portanto, se tornando chamado "referências de valor". Você poderá vincular rvalues ​​a referências de rvalue e poderá sobrecarregar funções em "rvalue-ness":

void g(X&);   // #1, takes an ordinary (lvalue) reference
void g(X&&);  // #2, takes an rvalue reference

X x; 
g(x);      // calls #1
g(getx()); // calls #2
g(X());    // calls #2, too

A idéia por trás das referências rvalue é que, como esses objetos vão morrer de qualquer maneira, você pode tirar proveito desse conhecimento e implementar o que é chamado de "mover semântica", um certo tipo de otimização:

class X {
  X(X&& rhs)
    : pimpl( rhs.pimpl ) // steal rhs' data...
  {
    rhs.pimpl = NULL; // ...and leave it empty, but deconstructible
  }

  data* pimpl; // you would use a smart ptr, of course
};


X x(getx()); // x will steal the rvalue's data, leaving the temporary object empty

O que você está mostrando é que o encadeamento do operador é permitido.

 X& x = getx().ref(); // OK

A expressão é 'getx (). Ref ();' e isso é executado até a conclusão antes da atribuição a 'x'.

Observe que getx () não retorna uma referência, mas um objeto totalmente formado no contexto local. O objeto é temporário, mas é não const, permitindo assim que você chamar outros métodos para calcular um valor ou ter outros efeitos colaterais acontecer.

// It would allow things like this.
getPipeline().procInstr(1).procInstr(2).procInstr(3);

// or more commonly
std::cout << getManiplator() << 5;

Veja o final desta resposta para um melhor exemplo disso.

Você não pode vincular um temporário a uma referência, pois isso gera uma referência a um objeto que será destruído no final da expressão, deixando assim uma referência pendente (que é desarrumada e o padrão não é desarrumado).

O valor retornado por ref () é uma referência válida, mas o método não presta atenção à vida útil do objeto que está retornando (porque não pode ter essas informações em seu contexto). Você basicamente fez o equivalente a:

x& = const_cast<x&>(getX());

O motivo de fazer isso com uma referência const a um objeto temporário é que o padrão estende a vida útil do temporário para a vida útil da referência, para que a vida útil dos objetos temporários seja estendida além do final da instrução.

Portanto, a única questão remanescente é por que o padrão não deseja permitir que a referência a temporários estenda a vida do objeto além do final da declaração?

Eu acredito que é porque isso tornaria muito difícil o compilador se corrigir para objetos temporários. Isso foi feito para referências const a temporários, pois isso tem uso limitado e, portanto, forçou você a fazer uma cópia do objeto para fazer algo útil, mas fornece algumas funcionalidades limitadas.

Pense nesta situação:

int getI() { return 5;}
int x& = getI();

x++; // Note x is an alias to a variable. What variable are you updating.

Estender a vida útil desse objeto temporário será muito confuso.
Enquanto o seguinte:

int const& y = getI();

Fornecerá o código que é intuitivo de usar e entender.

Se você deseja modificar o valor, retorne o valor a uma variável. Se você está tentando evitar o custo de copiar o objeto de volta da função (como parece que o objeto é uma cópia construída de volta (tecnicamente é)). Então não se preocupe, o compilador é muito bom em 'Return Value Optimization'

Por que é discutido nas perguntas frequentes sobre C ++ (mina de negrito ):

No C ++, as referências não const podem ser vinculadas a lvalues ​​e as referências const podem ser vinculadas a lvalues ​​ou rvalues, mas não há nada que possa ser vinculado a um valor não constante. Isso é para proteger as pessoas de alterar os valores dos temporários que são destruídos antes que seu novo valor possa ser usado . Por exemplo:

void incr(int& a) { ++a; }
int i = 0;
incr(i);    // i becomes 1
incr(0);    // error: 0 is not an lvalue

Se esse incr (0) fosse permitido, algum temporário que ninguém nunca viu seria incrementado ou - muito pior - o valor de 0 se tornaria 1. O último parece bobo, mas na verdade havia um bug como esse nos primeiros compiladores Fortran que definiam de lado um local de memória para armazenar o valor 0.

A questão principal é que

g(getx()); //error

é um erro lógico: gestá modificando o resultado, getx()mas você não tem chance de examinar o objeto modificado. Se gnão fosse necessário modificar seu parâmetro, ele não exigiria uma referência lvalue, poderia ter tomado o parâmetro por valor ou por referência const.

const X& x = getx(); // OK

é válido porque às vezes você precisa reutilizar o resultado de uma expressão e é bem claro que você está lidando com um objeto temporário.

No entanto, não é possível fazer

X& x = getx(); // error

válido sem g(getx())validar, que é o que os designers de linguagem estavam tentando evitar em primeiro lugar.

g(getx().ref()); //OK

é válido porque os métodos sabem apenas sobre a consistência do this, eles não sabem se são chamados em um lvalue ou em um rvalue.

Como sempre em C ++, você tem uma solução alternativa para essa regra, mas precisa sinalizar ao compilador que sabe o que está fazendo, sendo explícito:

g(const_cast<x&>(getX()));

Parece que a pergunta original sobre por que isso não é permitido foi respondida claramente: "porque provavelmente é um erro".

FWIW, pensei em mostrar como isso poderia ser feito, mesmo que eu não ache que seja uma boa técnica.

Às vezes, eu quero passar um método temporário para um método usando uma referência não-const, descartando intencionalmente um valor retornado por referência que o método de chamada não se importa. Algo assim:

// Assuming: void Person::GetNameAndAddr(std::string &name, std::string &addr);
string name;
person.GetNameAndAddr(name, string()); // don't care about addr

Conforme explicado nas respostas anteriores, isso não compila. Mas isso compila e funciona corretamente (com meu compilador):

person.GetNameAndAddr(name,
    const_cast<string &>(static_cast<const string &>(string())));

Isso apenas mostra que você pode usar a conversão para mentir para o compilador. Obviamente, seria muito mais limpo declarar e passar uma variável automática não utilizada:

string name;
string unused;
person.GetNameAndAddr(name, unused); // don't care about addr

Essa técnica introduz uma variável local desnecessária no escopo do método. Se, por algum motivo, você deseja impedir que ele seja usado posteriormente no método, por exemplo, para evitar confusão ou erro, você pode ocultá-lo em um bloco local:

string name;
{
    string unused;
    person.GetNameAndAddr(name, unused); // don't care about addr
}

- Chris

Por que você iria querer X& x = getx();? Basta usar X x = getx();e confiar no RVO.

A solução alternativa incorreta envolve a palavra-chave 'mutável'. Na verdade, ser mau é deixado como um exercício para o leitor. Ou veja aqui: http://www.ddj.com/cpp/184403758

Excelente pergunta, e aqui está minha tentativa de uma resposta mais concisa (já que muitas informações úteis estão nos comentários e são difíceis de descobrir no barulho).

Qualquer referência vinculada diretamente a um temporário prolongará sua vida útil [12.2.5]. Por outro lado, uma referência inicializada com outra referência não será (mesmo que seja finalmente a mesma temporária). Isso faz sentido (o compilador não sabe a que referência se refere).

Mas toda essa idéia é extremamente confusa. Por exemplo const X &x = X();, fará o temporário durar contanto que a xreferência, mas const X &x = X().ref();NÃO (quem sabe o que ref()realmente retornou). Neste último caso, o destruidor de Xé chamado no final desta linha. (Isso é observável com um destruidor não trivial.)

Portanto, geralmente parece confuso e perigoso (por que complicar as regras sobre a vida útil do objeto?), Mas presumivelmente havia uma necessidade pelo menos de referências const, portanto o padrão define esse comportamento para eles.

[Do comentário do sbi ]: Observe que o fato de vinculá- lo a uma referência const aumenta a vida útil de um temporário é uma exceção que foi adicionada deliberadamente (TTBOMK para permitir otimizações manuais). Não houve uma exceção adicionada para referências não-const, porque a ligação de uma referência temporária a uma não-const foi vista como provavelmente um erro de programador.

Todos os temporários persistem até o final da expressão completa. Para usá-los, no entanto, você precisa de um truque como o seu ref(). Isso é legal. Não parece haver uma boa razão para o aro extra, exceto para lembrar ao programador que algo incomum está acontecendo (a saber, um parâmetro de referência cujas modificações serão perdidas rapidamente).

[Outro comentário do sbi ] A razão pela qual Stroustrup dá (em D&E) a proibição de vincular rvalues ​​a referências não-const é que, se o g () de Alexey modificasse o objeto (o que você esperaria de uma função usando um não-const) referência), modificaria um objeto que morrerá, para que ninguém pudesse obter o valor modificado de qualquer maneira. Ele diz que isso, provavelmente, é um erro.

"Está claro que o objeto temporário não é constante na amostra acima, porque chamadas para funções não constantes são permitidas. Por exemplo, ref () pode modificar o objeto temporário."

No seu exemplo, getX () não retorna uma const X, portanto você pode chamar ref () da mesma maneira que poderia chamar X (). Ref (). Você está retornando uma referência não const e, portanto, pode chamar métodos não const, o que você não pode fazer é atribuir a referência a uma referência não const.

Juntamente com o comentário do SadSidos, isso torna seus três pontos incorretos.

Tenho um cenário que gostaria de compartilhar onde gostaria de poder fazer o que Alexey está pedindo. Em um plug-in do Maya C ++, eu tenho que fazer o seguinte shenanigan para obter um valor em um atributo de nó:

MFnDoubleArrayData myArrayData;
MObject myArrayObj = myArrayData.create(myArray);   
MPlug myPlug = myNode.findPlug(attributeName);
myPlug.setValue(myArrayObj);

Isso é entediante de escrever, por isso escrevi as seguintes funções auxiliares:

MPlug operator | (MFnDependencyNode& node, MObject& attribute){
    MStatus status;
    MPlug returnValue = node.findPlug(attribute, &status);
    return returnValue;
}

void operator << (MPlug& plug, MDoubleArray& doubleArray){
    MStatus status;
    MFnDoubleArrayData doubleArrayData;
    MObject doubleArrayObject = doubleArrayData.create(doubleArray, &status);
    status = plug.setValue(doubleArrayObject);
}

E agora eu posso escrever o código desde o início do post como:

(myNode | attributeName) << myArray;

O problema é que ele não é compilado fora do Visual C ++, porque está tentando vincular a variável temporária retornada do | operador à referência MPlug do operador <<. Eu gostaria que fosse uma referência, porque esse código é chamado muitas vezes e eu prefiro que o MPlug não seja copiado tanto. Eu só preciso que o objeto temporário viva até o final da segunda função.

Bem, este é o meu cenário. Apenas pensei em mostrar um exemplo em que alguém gostaria de fazer o que Alexey descreve. Congratulo-me com todas as críticas e sugestões!

Obrigado.