Início / coding / Perguntas / 79195178
Accepted
Enlico
Asked: 2024-11-16 20:53:56 +0800 CST

std::ranges::enumerate pode enumerar qualquer array C++ válido possível?

  • 772

Uma vez perguntei se std::ranges::views::enumerateusa o tipo errado ( long) para indexação no GCC, mas aparentemente não é o caso , porque

std::views::enumerateé especificado para ser usado range_difference_t<Base>como seu valor de índice.

No entanto, a partir do rascunho

O tipo size_té um tipo inteiro sem sinal definido pela implementação que é grande o suficiente para conter o tamanho em bytes de qualquer objeto ( [expr.sizeof] ).

Portanto, pode-se pensar em uma matriz tão longa que os elementos finais de algum índice em diante não se encaixam no tipo usado para enumerateindexação, embora ainda se encaixem std::size_tpor definição, desde que em uma determinada máquina, o seguinte seja válido

static_assert(std::numeric_limits<std::size_t>::max() > std::numeric_limits<long>::max());

Por exemplo, tal matriz seria esta:

std::vector<int> v(std::numeric_limits<std::size_t>::max());

para o qual eu gostaria de saber como kevolui o seguinte:

auto w = v | std::ranges::views::enumerate;
for (auto [k, _] : w) {
    std::cout << k << std::endl;
}

Infelizmente, std::vectornão parece permitir esse tamanho de forma alguma, lançando exceções, enquanto um std::arraycom esse mesmo tamanho nem é compilável (exemplo completo aqui ), mas presumo que nenhum comportamento seja obrigatório pelo padrão. Ou é?

c++

1 respostas

  1. Best Answer

    Não, é possível que enumeratenão seja possível enumerar todos os elementos de um array.

    Mas isso não é nada incomum. É um problema geral que sempre existiu em C e C++.

    Por exemplo, se std::size_te std::ptrdiff_ttêm a mesma largura de bits e a implementação realmente permite que os objetos tenham o tamanho std::numeric_limits<std::size_t>::max(), então

    char arr[std::numeric_limits<std::size_t>::max()];

    será válido, mas std::numeric_limits<std::ptrdiff_t>::max()será menor que o índice máximo do array. range_difference_tpois o array também é std::ptrdiff_te, portanto, enumerateacabará transbordando, causando um comportamento indefinido.

    No entanto, o mesmo problema exato ocorre com qualquer forma de diferenças de ponteiro no array, não apenas enumerate. Por exemplo, &arr[std::numeric_limits<std::size_t>::max()-1] - &arr[0]também tem tipo std::ptrdiff_te então tem comportamento indefinido porque o valor não é representável.

    Então, na prática, a implementação não pode permitir matrizes maiores que o valor máximo de std::ptrdiff_t(em vez de std::size_t) para evitar quebrar completamente a biblioteca padrão e muito código do usuário.

    O mesmo se aplica ao uso de size_typee difference_typeem intervalos/contêineres. Na prática, o tamanho máximo permitido deve ser limitado ao máximo de difference_type(em vez de size_type) para evitar que esses casos extremos de UB sejam possíveis. Não há garantia de que o tamanho de um contêiner possa atingir o valor máximo de size_type. Os contêineres geralmente têm uma max_sizefunção de membro para informar o tamanho máximo real.

    Tudo isso é o motivo pelo qual uma opinião comum é que size_t/ size_typefoi um erro e que tudo deveria ter sido definido com ptrdiff_t/ difference_typecomo base. Acho que essa opinião também é o motivo pelo qual a escolha de usar difference_typein enumerate(e outras visões) foi feita.

    • 1

relate perguntas