Fedor's questions

A declaração de função em um escopo de função pode ter uma constante definida localmente como argumento padrão?

Por exemplo,

void f(int) {}

int main() {
    constexpr int c = 1;
    void f(int = c);
    f();
}

O GCC não gosta disso, dizendo

erro: a variável local 'c' pode não aparecer neste contexto

O MSVC se comporta de forma semelhante:

erro C2587: 'c': uso ilegal de variável local como parâmetro padrão

Mas Clang aceita muito bem. Demonstração online: https://gcc.godbolt.org/z/9vWoK6TEz

Qual implementação está correta aqui?

Tenho um programa em C++20 que pode ser criado com sucesso no Ubuntu 20 com GCC 10 ou no Visual Studio 2019. E agora preciso compilá-lo para o macOS 13.7.2 x64 (atualmente disponível no runner hospedado no GitHub ), que possui o compilador AppleClang 15.

O programa usa std::atomic<float>tipos de dados e fetch_addoperações para eles como no exemplo:

#include <atomic>

int main() {
    std::atomic<float> a{0};
    a.fetch_add(1);
}

Infelizmente, ele não compila no AppleClang 15 com o

erro: nenhum membro chamado 'fetch_add' em 'std::atomic'

Demonstração online: https://gcc.godbolt.org/z/8WvGrczq7

Gostaria de manter std::atomic<float>os tipos de dados no programa (para minimizar as mudanças), mas substituir fetch_addpor algo mais disponível (provavelmente menos performático). Existe uma solução alternativa para Clangs antigos com libc++?

Um colega de trabalho me mostrou este programa:

#include <iostream>
#include <memory>

struct A {
    std::shared_ptr<int> u{ new int };
};

struct B : virtual A {};
struct C : virtual A {};
struct D : B, C {};

int main() {
    D d;
    d = D( d );
    std::cout << d.u;
}

que apesar de inicializar shared_ptrcom new intimprime zero. Demonstração online: https://gcc.godbolt.org/z/n3Kxbc3Pf

Vejo que isso está de alguma forma relacionado à herança de diamante e à classe base virtual comum.

O programa tem algum comportamento indefinido ou está bem formado e o padrão exige a impressão de zero aqui?

É possível alterar um membro ativo em uma união copiando o valor do membro ativo anterior usando std::construct_at?

Este exemplo mínimo

#include <memory>

constexpr int f() {
    union U {
        char x{0};
        int y;
    } u;
    std::construct_at(&u.y, u.x);
    return u.y;
}

static_assert( f() == 0 );

é aceito pelo GCC e MSVC, mas o Clang o rejeita com o erro:

/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__memory/construct_at.h:41:50: 
note: read of member 'x' of union with active member 'y' is not allowed in a constant expression
   41 |   return ::new (std::__voidify(*__location)) _Tp(std::forward<_Args>(__args)...);

Demonstração online: https://gcc.godbolt.org/z/xrj57jroj

Qual implementação está correta aqui?

É possível declarar uma ligação estruturada com constinitespecificador começando em C++20?

Por exemplo

struct A { int i, j; };

constinit auto [x, y] = A{ 0, 1 };

Aqui os compiladores divergem um pouco. MSVC reclama:

erro C3694: uma declaração de ligação estruturada não pode conter especificadores diferentes de 'static', 'thread_local', 'auto' e cv-qualifiers

Clang segue com o

erro: a declaração de decomposição não pode ser declarada 'constinit'

Mas o GCC apenas aceita o exemplo. Demonstração online: https://gcc.godbolt.org/z/jaY7ncsPP

Qual implementação está correta aqui?

Para usar um nome da classe base dependente no modelo de classe derivada (por exemplo, B<T>), é preciso adicionar um prefixo destacando para o compilador que é um nome dependente ( B<T>::). E para evitar fazer isso muitas vezes, uma declaração using pode ser usada em vez disso.

Abaixo o código com tal declaração de uso:

template <class T>
struct A {
    constexpr static int x = 0;
};

template <class T>
struct B : A<T> {
    // ok everywhere
    constexpr static int y = B<T>::x;

    // ok in MSVC
    using B<T>::x;
    constexpr static int z = x;
};

funciona bem no compilador MSVC, enquanto outros não gostam. Clang em particular reclama

erro: nenhum membro chamado 'x' em 'B'

Hovewer Clang não vê nenhum erro em y = B<T>::xuma linha acima. Demonstração online: https://gcc.godbolt.org/z/PvKW753M8

Qual implementação está correta aqui e por quê?

Meu programa se comporta como eu espero no modo C++20 do Visual Studio, mas preciso fazê-lo rodar no modo C++17, onde o programa altera sua saída.

Após a minimização, fica assim:

template <typename T>
int f() { return g(T{}); }

namespace {
    struct A{
        friend int g(const A &) { return 1; }
    };
}

template <typename T>
int g(T&&) { return 2; }

int main() { return f<A>(); }

No modo C++20 a saída de main()é 1, enquanto no modo C++17 a saída é 2. Demonstração online: https://gcc.godbolt.org/z/h8b8qoGGj

Gostaria de saber qual novo recurso do C++20 (ausente no C++17) é responsável pela discrepância do resultado.

Operadores de comparação para uma classe em C++23 podem ter parâmetros de objeto explícitos de um tipo distinto do tipo de classe?

Considere por exemplo

struct A {
    int i;
    constexpr bool operator==(this int x, int y) { return x == y; }
    constexpr operator int() const { return i; }
};

Agora a comparação para desigualdade

static_assert( A{0} != A{1} );

é aceito pelo GCC e Clang, mas o MSVC reclama:

error C2803: 'operator ==' must have at least one formal parameter of class type
error C2333: 'A::operator ==': error in function declaration; skipping function body

E a comparação para igualdade

static_assert( A{2} == A{2} );

é aceito apenas pelo GCC, enquanto o Clang já não gosta dele:

error: use of overloaded operator '==' is ambiguous (with operand types 'A' and 'A')
   11 | static_assert( A{2} == A{2} );
note: candidate function
    3 |     constexpr bool operator==(this int x, int y) { return x == y; }
note: built-in candidate operator==(int, int)

Demonstração online: https://gcc.godbolt.org/z/dnKc1fhcT

Qual compilador está correto aqui?

O programa abaixo foi reduzido ao máximo para mostrar o problema encontrado com o compilador Visual Studio C++.

fé alguma função de algoritmo que assume o objeto predicado de entrada P p, que possui um construtor de cópia definido pelo usuário que lembra o ponteiro no objeto de origem. Nesse construtor é verificado se os objetos fonte e cópia são realmente distintos, if (s == this) throw 0;mas na operator ()mesma verificação retorna o resultado oposto:

struct P {
    const P * s = nullptr;
    constexpr P() {}
    constexpr P(const P & p) : s(&p) {
        if (s == this) throw 0; // never happens
    }
    constexpr bool operator()() const {
        return s != this; // shall be always true?
    }
};

constexpr bool f(P p) {
    return p.s ? p() : f(p);
}

int main() {
    static_assert( f(P{}) ); // fails in MSVC, where static_assert( f(P{}) == false );
}

Demonstração online: https://gcc.godbolt.org/z/nqYoshExj

Como explicar que a mesma verificação passa no construtor de um objeto, mas falha em seu método?

Abaixo está uma expressão lambda recursiva que pode calcular os valores da sequência de Fibonacci tanto em tempo de execução quanto durante a avaliação constante:

auto fib = [](this auto && f, auto && p) {
    if ( p < 3 ) return 1;
    decltype(+p) v{};
    v = p - 2;
    return f(v+1) + f(v);
};

// ok everywhere
static_assert( fib(1) == 1 );
static_assert( fib(2) == 1 );
static_assert( fib(3) == 2 );
static_assert( fib(4) == 3 );
static_assert( fib(5) == 5 );
static_assert( fib(6) == 8 );
static_assert( fib(7) == 13 );
static_assert( 20 <= fib(8) && fib(8) <= 21 );
// fails in MSVC
static_assert( fib(8) == 21 );

Pelo que posso ver, funciona bem no GCC e no Clang, mas no Visual Studio funciona apenas para os primeiros 7 elementos e fib(8)é calculado de forma imprecisa, resultando em uma falha na asserção estática. Demonstração online: https://gcc.godbolt.org/z/dMM6f16do

Se o programa estiver correto, por que ele funciona bem para números pequenos e não funciona para números maiores (por exemplo, estouro de inteiros, muitas chamadas recursivas)?

No seguinte programa C++23

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

int main() {
    A{}.f(); // ok
    A{}();   // Clang error
}

struct Aé móvel e suas funções de membro f()têm operator()parâmetro de objeto explícito (this A).

No compilador Clang surpreendentemente A{}.f()funciona bem, mas A{}()falha com o erro:

<source>:10:5: error: call to implicitly-deleted copy constructor of 'A'
<source>:3:5: note: copy constructor is implicitly deleted because 'A' has a user-declared move constructor

Demonstração online: https://gcc.godbolt.org/z/hbfzMvE9f

Existe alguma diferença entre funções f()e operator()do ponto de vista da linguagem que explica seu tratamento observável pelo compilador?

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?

Como o compilador C++20 pode gerar operadores de comparação padrão para uma classe, inclusive como função não-membro amigo, consulte (2) em cppreference.com .

Me deparei com o código trabalhando no MSVC que faz isso para uma classe local dentro de uma função:

void foo() {
    struct A;
    bool operator ==(const A&, const A&);
    struct A { 
        friend bool operator ==(const A&, const A&) = default;
    };
}

Infelizmente, não funciona no Clang ou no GCC, que reclama:

error: cannot define friend function 'operator==' in a local class definition

Demonstração online: https://godbolt.org/z/Ts1fer1d1

Existe uma maneira de tornar o código aceito pelo GCC:

void foo() {
    struct A;
    bool operator ==(const A&, const A&);
    struct A { 
        friend bool operator ==(const A&, const A&);
    };
    bool operator ==(const A&, const A&) = default;
}

que agora apenas imprime algum aviso vago:

warning: declaration of 'bool operator==(const foo()::A&, const foo()::A&)' has 'extern' and is initialized

mas os outros dois compiladores não gostam, demonstração online: https://godbolt.org/z/he1zjj46G

Enquanto os compiladores divergem, qual deles está correto em ambos os exemplos acima?