Início / coding / Perguntas / 78785176
Accepted
Fedor
Asked: 2024-07-24 03:07:41 +0800 CST

Mover elisão em funções de membro de objeto explícito

  • 772

Se alguém chama a função de membro do objeto explícito de um temporário, a movimentação do temporário deve ser omitida no parâmetro do objeto explícito?

Considere o exemplo a seguir, onde struct Ao construtor de movimentação foi excluído e f(this A)é invocado para um objeto temporário A:

struct A {
    A() {}
    A(A&&) = delete;
    void f(this A) {}
};

int main() {
    A{}.f();
}

O programa é aceito no GCC, mas tanto o Clang quanto o MSVC o rejeitam:

chamada para construtor excluído de 'A'

erro C2280: 'A::A(A &&)': tentando fazer referência a uma função excluída

Demonstração on-line: https://gcc.godbolt.org/z/rbv14cnz5

Qual compilador está correto aqui?

c++

2 respostas

  1. Best Answer

    Este é CWG2813 . Como observa a descrição do problema, o texto em C++ 23 requer um glvalue para o operando esquerdo do operador ponto, o que implica que se o operando esquerdo for um pré-valor, ele deve ser convertido primeiro em um glvalue (materializado), o que evita copiar/mover elisão. Este resultado é indesejável; gostaríamos que o prvalue inicializasse o parâmetro do objeto explícito diretamente. Assim, foi feita uma alteração na redação e o mesmo foi aprovado como DR. Os compiladores levarão algum tempo para se atualizarem, mas a intenção é que o exemplo seja aceito.

    • 8

  2. O CGC está correto. Infelizmente, a norma não contém uma declaração explícita sobre esse fato. Em vez disso, é a ausência de palavras especiais para parâmetros de objetos explícitos em vários locais que torna o seu programa correto.

    A expressão A{}.f()consiste na expressão A{}incorporada em uma expressão de acesso de membro de classe A{}.f, que por sua vez está incorporada em uma expressão de chamada de função A{}.f(). Começando com o acesso do membro, não há nenhuma redação que [expr.ref]exija que o operando receptor seja ou seja convertido em um glvalue neste caso. A cláusula 2 impõe esta restrição apenas para membros de dados não estáticos :

    Para a primeira opção (ponto), se a expressão id [aqui f] nomear um membro estático ou um enumerador, ...; se a expressão id nomear um membro de dados não estático, a primeira expressão deverá ser um glvalue. ...

    A cláusula (7.3) que trata do acesso às funções apenas diz

    Se E2[aqui f] for um conjunto de sobrecarga, a expressão deverá ser o operando esquerdo (possivelmente entre parênteses) de uma chamada de função membro (...), e a resolução de sobrecarga de função (...) será usada para selecionar a função a ser que E2se refere. O tipo de E1.E2[aqui E1 = A{}] é o tipo de E2e E1.E2refere-se à função referida por E2.

    • Se E2se refere a uma função de membro estático, ...
    • Caso contrário (quando E2se refere a uma função de membro não estática), E1.E2é um pré-valor.

    Novamente, a parte importante é a falta de qualquer redação que restrinja A{}ser um glvalue.

    Passando para a resolução de sobrecarga, a regra relevante é [over.call.func]/2:

    Em chamadas de função qualificadas, a função é nomeada por uma expressão id precedida por um operador ->ou .. ... As declarações de função encontradas pela pesquisa de nome (...) constituem o conjunto de funções candidatas. A lista de argumentos é a lista de expressões na chamada aumentada pela adição do operando esquerdo do .operador na chamada de função de membro normalizada como o argumento do objeto implícito (...).

    Então, no seu caso, A{}.f()torna-se f(A{})para fins de resolução de sobrecarga, enquanto a sobrecarga definida em questão é simplesmente f(this A). A resolução de sobrecarga deverá ser bem-sucedida. As mensagens de erro do Clang e do MSVC sugerem que eles chegaram até aqui com sucesso.

    Os parâmetros de objeto explícitos não são tratados especialmente pela regra que rege como os parâmetros de função são inicializados. Parâmetros de objeto implícitos são o caso especial. [expr.call]/6lê:

    Quando uma função é chamada, cada parâmetro (...) é inicializado (...) com seu argumento correspondente. Se a função for uma função membro de objeto explícita e houver um argumento de objeto implícito (...), a lista de argumentos fornecidos será precedida pelo argumento de objeto implícito para os fins desta correspondência. ... Se a função for uma função de membro de objeto implícita, a expressão de objeto do acesso de membro de classe deve ser um glvalue e ....

    Novamente, a sentença que faria seu código falhar (a última) não se aplica neste caso, pois fnão é uma função de membro de objeto implícita.

    Finalmente, à medida que a chamada de função é avaliada, o this Aparâmetro to fprecisa ser inicializado pela expressão prvalue A{}. Isso é bem-sucedido, sem o envolvimento do construtor do movimento, por[dcl.init.general]/16.6

    Caso contrário, se o tipo de destino for um tipo de classe:

    • Se a expressão do inicializador for um pré-valor e a versão não qualificada de cv do tipo de origem for igual ao tipo de destino, a expressão do inicializador será usada para inicializar o objeto de destino.
    • ...

    A{}( Afinal, a expressão não usa o construtor move.)

    À parte, salientarei que a sua formulação da pergunta não é estritamente correta. A{}não é “temporário”; é um pré-valor. Um pré-valor é uma expressão que, quando avaliada, inicializa uma determinada parte da memória com um objeto. Quando uma função void g(A);é chamada por g(A{}), o fato de não haver movimentação não deve ser considerado como "elisão". Pensar em termos de "elisão" só faz sentido quando comparamos C++ 11 com C++ 03. Desde o C++ 11, simplesmente não há movimento para elidir. Sua pergunta é melhor escrita "quando uma função com um parâmetro de objeto explícito por valor é chamada em um pré-valor do tipo de classe, um valor temporário é materializado e movido?" A resposta que estou dando é "não, o prvalue inicializa diretamente o parâmetro e não há movimento temporário nem movimento".

    • 2

relate perguntas