Início / coding / Perguntas / 78354311
Accepted
ValueError
Asked: 2024-04-19 22:13:54 +0800 CST

A expressão condicional produz tipos diferentes entre MSVC e GCC/Clang

  • 772

Este código funciona em GCC e Clang, bug não em MSVC:

#include <concepts>
#include <utility>

struct S {};

const S&& f();
S g();

static_assert(std::same_as<decltype(false ? f() : g()), const S>);

https://godbolt.org/z/99rMPzecM

MSVC pensa decltype(false ? f() : g())que éconst S&&

Qual deles está certo? E porque?

c++

1 respostas

  1. Best Answer

    Com base no meu entendimento, todos os compiladores estão errados e o programa deveria estar mal formado.

    Trabalho relatado

    Há uma questão do CWG enviada, mas ainda não numerada, onde @BrianBi explica esse cenário e também conclui que o texto implica má formação.

    Por outro lado, @Barry compilou essas combinações de tipos no operador condicional em P3177R0 e afirma que const Sseriam produzidas. Não está claro se isso está correto e como o autor chegou a essa conclusão.

    Advogado Idiomático

    Para determinar o tipo correto no final, considere as regras para determinar o tipo do operador condicional em [expr.cond] . Entre outras coisas, em ... ? f() : g(), o compilador tenta converter f()para g()e g()para f(), conforme descrito em [expr.cond] p4 .

    Etapa 1: Determinando os tipos de destino

    Para efeitos das conversões mencionadas acima, o compilador determina os tipos de destino para ambas as sequências de conversão implícitas.

    Observe que:

    • f()é do tipo const S&&, que se transformaria em um xvalue do tipo const Santes de qualquer análise ( [expr.type] p1 ), e
    • g()é um pré-valor do tipo S.

    Conversão de f()para um tipo relacionado aS

    Esta conversão ocorre de acordo com [expr.cond] p4.3 :

    Se E2 for um pré-valor ou se nenhuma das sequências de conversão acima puder ser formada e pelo menos um dos operandos tiver tipo de classe (possivelmente qualificado para cv): [...]

    g()é um pré-valor, então este é o caso relevante.

    Como const Se Ssão do mesmo tipo de classe (ignorando a qualificação cv), mas Ssão menos qualificados para cv, [expr.cond] p4.3.1 não se aplica, mas sim, a conversão de lvalor em rvalor é aplicada a E2, que é g()( [expr.cond] p4.3.3 ):

    caso contrário, o tipo de destino é o tipo que E2 teria após aplicar as conversões padrão lvalue para rvalue, array para ponteiro e função para ponteiro.

    Resultado: o tipo de destino éS

    Nota: E2é g()e nenhuma das conversões listadas é aplicável, no entanto, tudo bem. Como obviamente você não pode aplicar todas as três conversões listadas, a intenção do texto é que qualquer uma dessas conversões seja aplicada, se possível. Em outras palavras, o tipo de destino simplesmente não tem E2nada aplicado.

    Conversão de g()para um tipo relacionado aconst S

    Se E2 for um xvalue, o tipo de destino será “referência de rvalue para T2”, mas uma sequência de conversão implícita só poderá ser formada se a referência for vinculada diretamente.

    - [expr.cond] p4.2

    Todas as condições aqui são satisfeitas, visto que f()é um xvalue e uma referência const S&&pode ser vinculada diretamente a um pré-valor do tipo S( [dcl.init.ref] p5.3.1 ).

    Resultado: o tipo de destino é "rvalue reference to const S"

    Etapa 2: conversões implícitas

    Agora, o compilador verifica se as conversões implícitas podem ser executadas com os tipos de destino fornecidos.

    • f()pode ser convertido para Susar o construtor de cópia definido implicitamente (trivial) que seria chamado como parte de uma sequência de conversão definida pelo usuário , e
    • g()pode ser convertido const S&&simplesmente vinculando uma referência.

    Devemos agora encontrar [expr.cond] p4, frase 5 :

    Se ambas as sequências puderem ser formadas, ou uma puder ser formada, mas for a sequência de conversão ambígua, o programa estará mal formado.

    O compilador deve rejeitar o código neste ponto, porém ninguém o faz.

    A perspectiva do GCC/clang

    Se continuássemos como se o programa não estivesse bem formado, encontraríamos [expr.cond] p6 :

    Caso contrário, o resultado será um pré-valor. [...] Caso contrário, as conversões assim determinadas são aplicadas, e os operandos convertidos são utilizados no lugar dos operandos originais para o restante desta subseção.

    O resultado é um pré-valor e aplicamos uma rodada final de conversão de lvalor em rvalor para fazer g()(uma vez que foi convertido em uma referência de rvalor). Aparentemente, o GCC acha que esse valor deveria ser do tipo const S, mas nunca deveríamos ter chegado a esse ponto.

    Como o resultado é um pré-valor e decltypenão está sendo aplicado a uma expressão de id sem parênteses, decltypedeve produzir Sor const S( [dcl.type.decltype] p1.6 ).

    A perspectiva MSVC

    O MSVC provavelmente pensa que uma das duas conversões falhou; nesse caso, o resultado pode ser const S&&:

    Se o segundo e terceiro operandos forem glvalues ​​da mesma categoria de valor e tiverem o mesmo tipo, o resultado será desse tipo e categoria de valor e será um campo de bits se o segundo ou terceiro operando for um campo de bits, ou se ambos são campos de bits.

    - [expr.cond] p5

    No entanto, não está claro por que o MSVC pensa que isso f()não pode ser convertido em S, o que teria resultado em um cenário em que ambos os operandos são xvalores do tipo const S&&agora.

    • 2

relate perguntas