HolyBlackCat's questions

Observe que esta é uma pergunta de direito linguístico . Conheço o significado comum de "variável", mas estou tentando entender exatamente o que o padrão chama de "variáveis". Estou escrevendo um material didático e quero usar as definições corretas.

Variáveis ​​são comumente definidas como "objetos nomeados", ou mais corretamente "objetos que foram declarados" (já que variáveis ​​podem não ter nome, mas são sempre declaradas).

Mas há um segundo ponto de vista: variáveis ​​são um conceito de tempo de compilação. Segundo essa definição, uma declaração no código-fonte sempre corresponde a uma variável, mesmo que, em tempo de execução, vários objetos sejam criados a partir dela.

Qual está correta?

Aqui está um exemplo em que isso é importante. Digamos que você tenha

void foo(bool a)
{
    int x = 42;

    if (a)
        foo(false);
}

Quando você chama foo(true), duas instâncias de int x = 42;get existem ao mesmo tempo.

Eles são claramente dois objetos diferentes, mas tecnicamente são variáveis ​​diferentes ou a mesma variável?

Se variáveis ​​são uma coisa de tempo de compilação, então as duas são a mesma variável.

A segunda definição parece errada à primeira vista, mas aqui temos um membro do comitê C++ argumentando que ela é a correta , por exemplo.

Eu fiz uma macro para o operador "implies". Funciona bem em geral, mas quebra no Clang quando usado em um conceito ou uma cláusula require.

run on gcc.godbolt.org

namespace detail
{
    template <typename T>
    concept BoolLike = requires(T &&t) {(T &&)t ? true : false;};

    struct Implies
    {
        template <BoolLike T>
        friend constexpr bool operator||(T &&lhs, Implies)
        {
            return !bool((T &&)lhs);
        }
    };
}

#define IMPLIES ||::detail::Implies{}||

template <typename T>
concept A = true IMPLIES true;

static_assert(A<int>);

Clang diz:

<source>:19:18: error: atomic constraint must be of type 'bool' (found '::detail::Implies')
   19 | concept A = true IMPLIES true;
      |                  ^~~~~~~
<source>:16:19: note: expanded from macro 'IMPLIES'
   16 | #define IMPLIES ||::detail::Implies{}||
      |                   ^~~~~~~~~~~~~~~~~~~

Enquanto GCC e MSVC aceitam alegremente esse código. Qual compilador está correto?

Considere o seguinte código:

#include <iostream>
#include <string>

union U
{
    std::string s;

    U()
    {
        new(&s) std::string;
    }

    void Set(std::string new_s)
    {
        s.~basic_string();
        new(&s) std::string(std::move(new_s));
    }

    ~U()
    {
        s.~basic_string();
    }
};

int main()
{
    U u;
    u.Set("foo");
    std::cout << u.s << '\n'; // Do I need `std::launder` here?
}

Eu sei que se eu usasse um array de bytes em vez de uma união, eu teria que std::launder(&s)acessar a string. Mas eu preciso disso aqui?

A resposta do senso comum parece ser "não", mas então onde está a bênção padrão unionde não precisar std::launder?

Estou lendo a documentação em std::expected::operator==, e aparentemente não é amigável ao SFINAE. Em vez de "não participa da resolução de sobrecarga se [os tipos não forem eq-comparáveis]", diz "o programa está malformado [nesse caso]".

E de fato:

#include <concepts>
#include <expected>

struct A {};

static_assert(!std::equality_comparable<std::expected<A, A>>);

Esta afirmação falha no MSVC e no Clang com libc++ e causa um erro grave no Clang com MSVC STL.

Mas por que não é compatível com SFINAE?

std::expected<T,U>requer que ambos Te Usejam completos de qualquer forma, então aparentemente nada impede que todas as operações nele sejam compatíveis com SFINAE.

Eu tenho uma string C ( const char *) e quero convertê-la em um intervalo C++ 20 (a forward_range) para aplicar alguns algoritmos padrão a ela.

Não quero usar std::string_viewporque não quero calcular seu comprimento (a string pode ser longa e só me importo com os primeiros caracteres). Felizmente, a forward_rangenão precisa saber seu comprimento com antecedência.

Como eu faço isso? Eu poderia escrever um iterador personalizado, mas espero que haja uma maneira mais fácil.