Início / coding / Perguntas / 78564905
Accepted
Thornsider3
Asked: 2024-06-02 04:58:13 +0800 CST

Visualização digitada possível? Ou estou pensando errado

  • 772

este não é um bug específico, mas uma questão geral de design em C++. Considere o seguinte cenário:

struct MyInterface {};

struct Data : MyInterface{};

struct DataWrapper
{
    SomeContainerOf<MyInterface*> getData()
    {...}
private:
    std::vector<Data> dataStorage;
};

Em termos dos meus requisitos, preciso da função de acesso para DataWrapperretornar um contêiner de MyInterface*valores (ponteiros porque estamos realmente retornando Datavalores).

Idealmente, queremos fazer isso sem fazer uma cópia. Quero saber a melhor maneira de fazer isso. Pelo que posso dizer, algo como o seguinte é a maneira idiomática do C++ de fazer isso:

auto DataWrapper::getData()
{
    return dataStorage
        | std::ranges::views::transform(
            [](Data& d) -> MyInterface* { return &d; }
        );
}

Mas o problema é que está muito claro que esse método acessador é explícito sobre seus valores de retorno - preciso que saibam que esse método retorna essa lista, e estou preocupado que ao fazer o tipo de retorno auto, isso atrapalhe um pouco isso . Parece que (posso estar errado aqui) você não deveria saber qual viewé o tipo de a (em um estilo semelhante aos lambdas)

A alternativa que estou considerando seria fazer uma visualização customizada (onde eu poderia deixar o tipo um pouco mais claro), mas realmente me dói reimplementar algo que está tão claramente no padrão. Qual seria a medida recomendada para tal cenário? O C++ moderno diz que devo manter o valor de retorno auto?

c++

3 respostas

  1. Best Answer

    O C++ moderno diz que devo manter o valor de retorno auto?

    Se você está preocupado com o fato de isso autoestar muito implícito na expressão do tipo de retorno, usar restrito auto pode ser uma escolha apropriada. Por exemplo

    template <typename R, typename V>
concept RangeOf = std::ranges::range<R> && 
                  std::same_as<std::ranges::range_value_t<R>, V>;

struct DataWrapper
{
    RangeOf<MyInterface*> auto getData()
    {
      return dataStorage
        | std::ranges::views::transform(
            [](Data& d) -> MyInterface* { return &d; }
        );
    }
private:
    std::vector<Data> dataStorage;
};
    • 9

  2. Farei várias recomendações semi-ortogonais:

    Recomendação 1: Esclareça o tipo de retorno com uma definição de tipo

    Preciso que saibam que esse método retorna essa lista

    Então, faça isso! Em vez de declarar a função como retornando automaticamente:

    1. Fatore o lambda - em uma função de membro privado estático ou em uma função em um detail_namespace, etc. Agora você pode usá-lo, ou seu tipo, sem repeti-lo. Suponha que você o tenha definido como chamadofoo()
    2. Escreva algo como: 
      using bar = std::decltype(dataStorage | std::ranges::views::transform(foo));
      e é claro que você substituirá barpelo tipo pelo qual deseja que os usuários deste método conheçam o resultado.

    Nota: a resposta de 康桓瑋sugere o uso de um restrito auto, para um efeito semelhante. É uma boa ideia, possivelmente ainda melhor que esta (embora um pouco mais detalhada). Então, por favor, vote a favor da resposta deles.

    Recomendação 2: Considere cuidadosamente a necessidade de herança

    Antes mesmo de considerar a DataWrapperclasse "maior", mantendo o vetor - talvez você deva pensar se realmente precisa usar MyInterfaceem vez de Data. Você parece estar confiando, até certo ponto, no retorno Datade getData()- daí o nome.

    • Você tem outros herdeiros de MyInterface? Caso contrário, considere abandoná-lo (ou mantê-lo, mas não usá-lo, a não ser para simplificar a maneira como você define Data).
    • Existem muitas classes herdeiras de MyInterface? Ou eles não são conhecidos no momento da definição de MyInterface? Se a resposta for "não", considere usar an std::variant<Data,C1,C2,C3>para o caso de C1, C2, C3serem os herdeiros de MyInterface.
    • Você pode modelar o código acessando as classes filhas MyInterface? Você pode transformar MyInterface em um conceito em vez de uma classe base. Ou o CRTP pode entrar em ação de alguma forma.

    Se você puder fazer qualquer um desses, é possível evitar a necessidade de uma DataWrapperclasse _completamente e simplesmente ter um std::vector<foo>para algum foo relevante ( Data, ou a variante, classe ou mesmo std::any).

    Não estou dizendo que evitar herança seja “melhor”; significa mudar de uma compensação de benefícios e prejuízos para outra. Mas muitas pessoas simplesmente optam pela herança porque é a maneira mais tradicional de fazer as coisas em C++, em vez de ser a que melhor atende às suas necessidades.

    Recomendação 3: Não devolva um container (ou intervalo), seja o container!

    Você tem uma classe do tipo valor ( DataWrapper) com um vetor de dados. Agora, você não está disposto a permitir que as pessoas usem esse vetor diretamente, portanto, DataWrappernão pode ser usado como um contêiner C++ de Datas.

    Bem - explore isso! Torne-o utilizável como um contêiner de objetos herdados MyInheritance, ou seja, MyInheritancereferências! Implemente o início, o cbegin, o tamanho, o vazio, o iterador e todas as outras partes desse requisito nomeado. Talvez vá tão longe quanto implementar tudo em ContiguousContainer ... embora isso torne sua classe um pouco mais complexa, você estará na verdade economizando a complexidade indireta do uso std::ranges(muito código subjacente lá), além de - seus usuários não precisa saber sobre getData(), então, em termos de uso, você provavelmente está simplificando as coisas.

    • 5

  3. Como a lista de captura do lambda está vazia, o construtor padrão pode instanciá-la. Portanto, podemos declarar detalhadamente o tipo de retorno. Mas como os construtores do adaptador de intervalo são explícitos, ocorre alguma repetição de código:

    namespace rng = std::ranges;
auto DataWrapper::getData() ->
rng::transform_view<
     rng::ref_view<decltype(dataStorage)>,
     decltype ([](Data& d) -> MyInterface& { return d; })
> {//DataWrapper::getData()
     return rng::transform_view{
            rng::ref_view{dataStorage},
            {/*lambda::lambda()*/}
     };//! return 
};//!DataWrapper::getData()

    Usei ref_viewno snippet porque não consegui verificar se o primeiro argumento de tipo transform_viewdeveria ser um contêiner ou uma referência a um contêiner. Mas ref_viewsatisfaz as restrições e incorpora uma referência ao contêiner.

    • 2

relate perguntas