xmllmx's questions

Considere o seguinte código:

void f1(bool ok) {
    if (ok) [[likely]] {
        // ...
    } else [[unlikely]] {
        // ...
    }
}

void f2(bool ok) {
    if (ok) [[likely]] {
        // ...
    } else {
        // ...
    }
}

void f3(bool ok) {
    if (ok)  {
        // ...
    } else [[unlikely]] {
        // ...
    }
}

f1, f2, e são f3equivalentes do ponto de vista do compilador?

#include <expected>
#include <span>
#include <iostream>

int main() {
    auto e = std::expected<std::span<char>, int>{};
    std::cout << e.value().size() << std::endl;
}

Meu compilador é clang-19.1.5. Compile o código com o seguinte comando:

clang++-19 -std=c++2c -stdlib=libc++ ./toy.cpp -lc++abi -lunwind -lc++

A compilação e a vinculação estão corretas, mas um erro de tempo de execução é gerado:

./a.out: erro de pesquisa de símbolo: ./a.out: símbolo indefinido: _ZTINSt3__119bad_expected_accessIvEE

$ nm -D /usr/local/lib/libc++.so.1 | grep access
00000000000607b0 T _ZNKSt18bad_variant_access4whatEv
0000000000054040 T _ZNKSt19bad_optional_access4whatEv
0000000000054060 T _ZNSt12experimental19bad_optional_accessD0Ev
0000000000054050 T _ZNSt12experimental19bad_optional_accessD1Ev
0000000000054050 T _ZNSt12experimental19bad_optional_accessD2Ev
0000000000054020 T _ZNSt19bad_optional_accessD0Ev
0000000000054010 T _ZNSt19bad_optional_accessD1Ev
0000000000054010 T _ZNSt19bad_optional_accessD2Ev
00000000000ee248 D _ZTINSt12experimental19bad_optional_accessE
00000000000ee440 D _ZTISt18bad_variant_access
00000000000ee208 D _ZTISt19bad_optional_access
00000000000b024b R _ZTSNSt12experimental19bad_optional_accessE
00000000000ccded R _ZTSSt18bad_variant_access
00000000000b0233 R _ZTSSt19bad_optional_access
00000000000ee220 D _ZTVNSt12experimental19bad_optional_accessE
00000000000ee418 D _ZTVSt18bad_variant_access
00000000000ee1e0 D _ZTVSt19bad_optional_access

Se eu mudar -stdlib=libc++para -stdlib=libstdc++, então ok.

Por que std::expected o libc++ não funciona?

C++23 permite definir um lambda como static. ou seja, se um lambda não captura nada, então ele pode ser definido como static:

// with superfluous argument `this`, less efficient.
auto fn1 = [](int a, int b) { return a + b; }; 

// no argument `this`, more efficient!
auto fn2 = [](int a, int b) static { return a + b; }; 

Eu só me pergunto:

Por que o padrão C++ não define implicitamente um lambda que não captura nada como staticpadrão?

Considere o seguinte código:

#include <concepts>

struct T1 {};

struct T2 {};

struct T3 {};

struct T4 {};

void bar(T1, T2, T3, T4) {
}

template<typename T>
concept IsT = std::same_as<T, T1> || std::same_as<T, T2> ||
              std::same_as<T, T3> || std::same_as<T, T4>;

void foo(IsT auto x1, IsT auto x2, IsT auto x3, IsT auto x4) {
    // How to order the types of x1, x2, x3, x4 and call bar(x?, x?, x?, x?)?
}

int main() {
    foo(T1{},T2{},T3{},T4{}); // ok
    foo(T4{},T3{},T2{},T1{}); // ok
    foo(T3{},T2{},T1{},T4{}); // ok
    // ...
}

Minha intenção é simples:

O usuário pode chamar fooem qualquer ordem de argumentos, mas finally barserá chamado com os argumentos na ordem correta.

A solução trivial é usar força bruta para dividir os 24 casos, o que é obviamente tedioso e propenso a erros.

Existe uma maneira sem força bruta de resolver esse problema? Estou usando C++20.

Considere o seguinte código:

#include <iostream>

struct A {
    A(int, int) {
        std::cout << "A::A(int, int)\n";
    }

    A(std::initializer_list<int>) {
        std::cout << "A::A(std::initializer_list<int>)\n";
    }
};

struct B {
    A a(1, 2); // compiler error
};

struct C {
    A a{1, 2}; // always call A::A(std::initializer_list<int>)
};

struct D {
    A a{A(1, 2)}; // always call A::A(int, int), how UgLy it is!
};

int main() {
    new B{};
    new C{};
    new D{};
}

Existe uma solução melhor do que A a{A(1, 2)};?

C++26 fornece std::copyable_function [cppref link] . No entanto, o existente std::functionjá é copyable. Então, tenho 3 perguntas:

1. Quais são as principais vantagens de std::copyable_functionmais de std::function?

2. Invocar um vazio std::copyable_functioné indefinido, enquanto invocar um vazio std::functionlançará uma exceção. Qual é a lógica por trás disso?

3. Foi std::functiondescontinuado std::copyable_functionem C++26?

Em uma proposta padrão C++ , encontro um trecho de código estranho como o seguinte:

template <input_iterator I, sentinel_for<I> S, nothrow_forward_iterator I2>
constexpr auto uninitialized_copy(I first, S last, I2 d_first) -> I2 {
    using T = iter_value_t<I2>;
    I2 current = d_first;
    try {
        for (; first != last; ++first, (void)++current) {
            ::new (std::addressof(*current)) T(*first);
        }
    } catch (...) {
        std::destroy(d_first, current);
        throw;
    }
}

Por que usar (void)++current em vez de apenas ++current aqui?

#include <iostream>

int main() {
#if __has_include(<coroutine>)
    std::cout << "__has_include(<coroutine>)" << std::endl;
#endif

#if defined(__cpp_impl_coroutine)
    std::cout << "__cpp_impl_coroutine is defined." << std::endl;
#endif

#if defined(__cpp_coroutines)
    std::cout << "__cpp_coroutines is defined." << std::endl;
#else
    std::cout << "__cpp_coroutines IS NOT defined!" << std::endl;
#endif
}

Meu compilador é clang-18.1.0.

Construa o código com clang++ -std=c++20 -stdlib=libc++ ./main.cppe a saída será:

__has_include(<coroutine>)
__cpp_impl_coroutine is defined.
__cpp_coroutines IS NOT defined!

Por que o clang mais recente não define a macro de teste de recursos __cpp_coroutines?

Meu compilador é clang 18.1.0-rc1; e o código a seguir aciona dois avisos:

#include <atomic>

std::atomic<int> n;

int main() {
    // Warning: Memory order argument to atomic operation is invalid
    n.load(std::memory_order_acq_rel); 

    // Warning: Memory order argument to atomic operation is invalid
    n.store(1, std::memory_order_acq_rel);
}

Qual é o uso legal de std::memory_order_acq_rel?

Atualizar

n.fetch_add(1, std::memory_order_acq_rel); // now is ok

Considere o seguinte código:

void Log(std::string_view       msg,
    std::source_location const& loc = std::source_location::current()) {
    
    // Performance penalty!
    auto const n = std::strlen(loc.file_name()); 
    auto s = ""s;
    s.resize(msg.size() + n);

    std::memcpy(&s[0], msg.data(), msg.size());
    std::memcpy(&s[msg.size()], loc.file_name(), n);
    s[msg.size() + n] = 0; // ensure to be null-terminated

    // sendToRemoteMachine(s); 
}

Obviamente, se std::source_location::file_nameretornar a std::string_view, a penalidade de desempenho pode ser facilmente evitada.

Eu acho que std::source_location::file_nameé uma informação gerada em tempo de compilação e somente leitura. O compilador pode armazená-lo em um std::string_viewobjeto.

Por que não std::source_locationfornece comprimentos para evitar penalidades de desempenho em C++20?

Atualizar

Outro artigo relacionado: std::source_locationestá quebrado

class A {    
};

class B {
    using C = A;

    // Compilation error: 
    // Type alias 'C' cannot be referenced with a class specifier 
    friend class C;    
};

Por que um alias de tipo não pode ser um nome de classe amigo em C++?

Qual é a lógica por trás?