Fedor's questions

Vejo uma pergunta semelhante Construtor de movimento padrão recebendo um parâmetro constante , que tem 8 anos, com a resposta Não .

Mas, ao mesmo tempo, um programa ligeiramente modificado com o construtor padrão após a definição da classe:

struct A {
    A(const A&&);
};
A::A(const A&&) = default;

aceito pelo EDG 6.7 e lançado recentemente pelo GCC 15.1. Demonstração online: https://gcc.godbolt.org/z/E4qT3sTEq

E um exemplo ainda mais complexo parece funcionar corretamente com estes dois compiladores:

struct A {
    int i;
    constexpr A(int v) : i(v) {}
    constexpr A(const A&&);
};

constexpr int f() {
    A a(1);
    A b = static_cast<const A&&>( a );
    return b.i;
}

constexpr A::A(const A&&) = default;
static_assert( f() == 1 );

Mas o MSVC ainda não gosta disso:

error C2610: 'A::A(const A &&)': is not a special member function or comparison operator which can be defaulted
<source>(13): note: the argument must be a non-const rvalue reference

assim como Clang:

error: the parameter for an explicitly-defaulted move constructor may not be const

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

Alguma coisa mudou nos últimos 8 anos nessa relação? Qual implementação está correta agora?

Se alguém copia um std::vectorem outro, ou copia elementos de um std::vectorem um bloco maior ( reserve) ou menor ( shrink_to_fit) da memória heap, qual construtor do tipo do elemento é chamado?

No programa de exemplo:

#include <vector>
#include <iostream>

struct A {
    A() {}
    A(A&) { std::cout << "A(A&) "; }
    A(const A&) { std::cout << "A(const A&) "; }
};

int main() {
    std::vector<A> v(1);
    v.reserve(10);
    auto w = v;
    v.shrink_to_fit();
}

Eu esperaria ver A(const A&) A(const A&) A(const A&)uma saída. Mas, na realidade, as implementações da biblioteca padrão divergem:

• libc++impressões A(const A&) A(A&) A(const A&),
• libstdc++impressões A(const A&) A(const A&) A(A&),
• e o Microsoft STL imprime A(A&) A(A&) A(A&).

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

É correto supor que se o construtor de not- constlvalue for chamado, o código do usuário terá permissão para modificar seu argumento (pelo menos temporariamente)?

É legal escrever algo assim?

#include <memory>

struct A {
    int i, j;
    constexpr A() : i((std::construct_at(&j, 2), j-1)) {}
};
constexpr A a{};
static_assert(a.i == 1);
static_assert(a.j == 2);

Aqui, io inicializador -member primeiro inicializa jo membro usando std::construct_ate depois lê seu valor em j-1.

Na prática, vejo que todos os GCC, MSVC e Clang aceitam o programa. Demonstração online: https://gcc.godbolt.org/z/YzEoPPj96

Mas Clang emite o aviso:

<source>:5:50: warning: field 'j' is uninitialized when used here [-Wuninitialized]
    5 |     constexpr A() : i((std::construct_at(&j, 2), j-1)) {}
      |                                                  ^

Isso parece contraditório, já que a leitura de valores não inicializados em expressões constantes deve resultar em falha grave. O programa está bem formado e o diagnóstico está simplesmente errado?

E graças ao @TedLyngmo, aqui está um exemplo mais complicado com alocações de heap:

#include <string>

struct A {
    std::string i, j;

    constexpr A()
        : i(((void)std::construct_at(&j,
                                     "Hello world, this is very funny indeed "
                                     "and this is a long string"),
             j + " with some exta in it"))
        , j([k=std::move(j)]()mutable { return std::move(k); }()) {}
};

static_assert( A{}.i.length() == 85 );
static_assert( A{}.j.length() == 64 );

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

Tenho uma constante declarada em uma casedas minhas switchdeclarações:

void foo( int& v ) {
    switch( v ) {
    case 0:
        static constexpr int c{ 0 };
        break; 
    case 1:
        v = c;
        break;
    }
}

Tudo funciona bem no GCC, Clang e EDG. Mas se eu compilar o programa no Visual Studio, ele reclama

erro C2360: a inicialização de 'c' é ignorada pelo rótulo 'case'

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

É correto que a inicialização da constante cpode ser pulada? O programa está realmente malformado ou deve ser aceito?

É proibido usar std::bit_castpara conversão de ou para std::nullptr_t = decltype(nullptr)o tipo? E se for permitido, 1) o resultado de deve std::bit_castser o mesmo que static_cast, 2) a conversão de ida e volta deve retornar o valor original?

Testei os compiladores atuais e todos eles aceitam o seguinte programa sem nenhum aviso:

#include <bit>
#include <iostream>

int p = 0;
auto n = std::bit_cast<decltype(nullptr)>( &p );

int main() {
  std::cout 
    << (std::bit_cast<int*>(n) == static_cast<int*>(n))
    << ' '
    << (&p == std::bit_cast<int*>(n));
}

Mas os compiladores divergem na forma como tratam as conversões, o que é visível na saída do programa:

• Impressões sonoras 0 1.
• Impressões GCC 1 0.
• Impressões MSVC 1 1.

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

Qual implementação está correta aqui, se houver alguma?

Meu colega porta um programa C++ com intervalos no macOS e observa um erro de compilação inesperado.

Após a simplificação máxima, o programa de exemplo fica assim:

#include <optional>
#include <algorithm>

int main() {
    std::optional<int> ops[4];
    //...
    return (int)std::ranges::count_if( ops, &std::optional<int>::has_value );
};

O GCC e o MSVC funcionam bem com o programa, mas o Clang exibe um longo erro:

 error: no matching function for call to object of type 'const __count_if::__fn'
    7 |     return (int)std::ranges::count_if( ops, &std::optional<int>::has_value );
      |                 ^~~~~~~~~~~~~~~~~~~~~
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:62:3: note: candidate template ignored: constraints not satisfied [with _Range = std::optional<int> (&)[4], _Proj = identity, _Predicate = bool (std::__optional_storage_base<int>::*)() const noexcept]
   62 |   operator()(_Range&& __r, _Predicate __pred, _Proj __proj = {}) const {
      |   ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:60:13: note: because 'indirect_unary_predicate<_Bool (std::__optional_storage_base<int>::*)() const noexcept, projected<iterator_t<optional<int> (&)[4]>, identity> >' evaluated to false
   60 |             indirect_unary_predicate<projected<iterator_t<_Range>, _Proj>> _Predicate>
      |             ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__iterator/concepts.h:191:60: note: because 'predicate<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, iter_value_t<__type> &>' evaluated to false
  191 |     indirectly_readable<_It> && copy_constructible<_Fp> && predicate<_Fp&, iter_value_t<_It>&> &&
      |                                                            ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/predicate.h:28:21: note: because 'regular_invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false
   28 | concept predicate = regular_invocable<_Fn, _Args...> && __boolean_testable<invoke_result_t<_Fn, _Args...>>;
      |                     ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:34:29: note: because 'invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false
   34 | concept regular_invocable = invocable<_Fn, _Args...>;
      |                             ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:28:3: note: because 'std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...)' would be invalid: no matching function for call to 'invoke'
   28 |   std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...); // not required to be equality preserving
      |   ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:54:3: note: candidate function template not viable: requires at least 3 arguments, but 2 were provided
   54 |   operator()(_Iter __first, _Sent __last, _Predicate __pred, _Proj __proj = {}) const {
      |   ^          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Não entendi o que há de errado com o programa?

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?