Oersted's questions

Essa questão pode ser considerada provavelmente teórica, pois não vejo por que eu teria esse design em código real. Tenho duas classes com alguns operadores de conversão:

class B;
class A {
   public:
    A() = default;
    A(B const &);
};
class B {
   public:
    B() = default;
    operator A();
};

A::A(B const &) {};
B::operator A() { return A{}; };

int main() {
    [[maybe_unused]] A ad{B{}};   // direct init
    [[maybe_unused]] A ac = B{};  // copy init
}

AO VIVO

Com gcc somente e com inicialização de cópia somente, recebo este aviso:

aviso: escolhendo 'B::operator A()' em vez de 'A::A(const B&)' [-Wconversion]
aviso: para conversão de 'B' para 'A' [-Wconversion]
nota: porque a sequência de conversão para o argumento é melhor

Não sendo bem versado nas regras de conversão, não entendo se esse aviso é relevante? Se não, como pode ser silenciado (pode ser doloroso com -Werror)?

NB Adicionando um pouco de traces , observei comportamentos diferentes de acordo com os compiladores e a natureza da inicialização. As sequências de conversão são dependentes da implementação até certo ponto?

Ouvi falar do clang-cl como uma versão "com sabor da Microsoft" do clang, mas olhando minha configuração, estou observando o seguinte:

• Tenho um clang executável nos meus diretórios msys2
• Tenho um executável clang-cl nos meus diretórios msys2
• Tenho um clang executável nos meus diretórios de ferramentas de construção do Visual Studio
• Tenho um executável clang-cl nos meus diretórios de ferramentas de construção do Visual Studio

Quais são as diferenças entre essas versões? (No final das contas, gostaria de ver se vale a pena o esforço de adicionar suporte para clang-cl na minha estrutura de compilação)

Dados adicionais: Chamar cada um deles com -v me dá o resultado Target: x86_64-w64-windows-gnupara o primeiro e Target: x86_64-pc-windows-msvcpara todos os outros.

Eu descobri que é S{}.rvaluma expressão lvalue. Quero saber a lógica por trás de considerá-la uma expressão lvalue.

Por que o acesso ao membro não estático do tipo de referência é lvalue, mesmo quando o objeto é um rvalue?

struct S {
    int val;
    int& rval = val;
};
int main() {
    S{}.val; // xvalue
    S{}.rval; // lvalue
}

Minha expectativa seria que uma referência a uma "entidade que morrerá em breve" também seria "morrerá em breve". Então, eu gostaria de entender a lógica da(s) regra(s).

Analisando a definição de categorias de valor, tentei um trecho proposto aqui: https://stackoverflow.com/a/16638081/21691539

template <typename T>
struct value_category {
    // Or can be an integral or enum value
    static constexpr auto value = "prvalue";
};

template <typename T>
struct value_category<T&> {
    static constexpr auto value = "lvalue";
};

template <typename T>
struct value_category<T&&> {
    static constexpr auto value = "xvalue";
};

// Double parens for ensuring we inspect an expression,
// not an entity
#define VALUE_CATEGORY(expr) value_category<decltype((expr))>::value

Mas testando-o não entendo sua saída em uma situação que implique referências. Aqui está meu "banco de testes":

#include <iostream>

struct S {
    int val;
    int& rval = val;
};

int f();
int& rf();

// VALUE_CATEGORY as in previous snippet

#define SHOW_CATEGORY(expr) std::cout << #expr << "\t" << VALUE_CATEGORY(expr) << '\n';

int main() {
    SHOW_CATEGORY(f());
    SHOW_CATEGORY(rf());    // expecting prvalue, got lvalue
    SHOW_CATEGORY(S{}.val);
    SHOW_CATEGORY(S{}.rval);    // expecting xvalue, got lvalue
}

AO VIVO

e a saída

f()      prvalue
rf()     lvalue
S{}.val  xvalue
S{}.rval lvalue

Nos dois casos em que a expressão está relacionada a uma referência, estou recebendo um arquivo lvalue.

O trecho está correto e, neste caso, por quê? Está errado, então qual seria a categoria de valor correta (e também por quê)?

NB de https://timsong-cpp.github.io/cppwp/n4861/basic.lval#4.4 Eu entendi, S{}.rvalmas xvaluegostaria de saber o motivo.

Não tenho certeza se o título da minha pergunta é o mais apropriado e terei prazer em alterá-lo para algo mais claro se receber sugestões adequadas.

Em um vídeo em C++ cujo assunto não é esse aqui, vi esta definição:

#include <vector>

// before ":" V is forward declared, it's enough for std::vector?
// node in a tree
struct V : std::vector<V> {};

(os comentários são de minha autoria).

Meu entendimento é que é possível ter essa declaração aparentemente circular, pois no base-clauselocal, struct Vjá está (forward) declarado.

Mas é C++ legal, pois não acho que a declaração de classe seja explícita sobre isso.

forward declarationé definido por si mesmo ( struct V;, então você pode declarar a std::vector<V>), mas não na sintaxe completa da declaração de classe.

O texto na classe derivada :

Qualquer tipo de classe ( seja declarado com class-key class ou struct ) pode ser declarado como derivado...

(negrito meu) parece implicar que class-key classou class-key struct(sem terminar ;) já são declarações completas. É verdade, está mais explícito na norma?

Se sim, isso pode me dar oportunidades para designs interessantes, então gostaria de ter certeza de que é legal.

[EDIT] um exemplo mais explícito, semstd::vector

template <typename T>
struct refwrapper {
    T* wrapped;
    virtual ~refwrapper() = default;
};

template <typename T>
struct plainwrapper {
    T wrapped;
    virtual ~plainwrapper() = default;
};

// OK? R is declared at the base-clause
struct R : refwrapper<R> {};

// KO P is incomplete at the base-clause
// struct P: plainwrapper<P>
// {};

Ao vivo