Por que o vetor de libc ++ <bool> :: const_reference não é bool?

Seção 23.3.7 Classe vector<bool>[vector.bool], parágrafo 1 afirma:

template <class Allocator> class vector<bool, Allocator> {
public:
    // types:
    typedef bool              const_reference;
    ...

No entanto, este programa falha ao compilar ao usar libc ++:

#include <vector>
#include <type_traits>

int
main()
{
    static_assert(std::is_same<std::vector<bool>::const_reference, bool>{}, "?");
}

Além disso, observo que o padrão C ++ tem sido consistente nesta especificação desde o C ++ 98. Além disso, observo que a libc ++ não tem seguido esta especificação de forma consistente desde a primeira introdução da libc ++.

Qual é a motivação para esta não conformidade?

A motivação para esta extensão, que é detectável por um programa em conformidade e, portanto, não conforme, é fazer com que o vector<bool>comportamento seja mais semelhante vector<char>em relação às referências (const e não).

Introdução

Desde 1998, vector<bool>tem sido ridicularizado como "não exatamente um contêiner". O LWG 96 , um dos primeiros problemas do LWG, lançou o debate. Hoje, 17 anos depois, vector<bool>permanece praticamente inalterado.

Este artigo apresenta alguns exemplos específicos de como o comportamento de vector<bool>difere de todas as outras instanciações de vector, prejudicando assim o código genérico. No entanto, o mesmo artigo discute detalhadamente as excelentes propriedades de desempenho que vector<bool>podem ter se implementadas corretamente.

Resumo : vector<bool>não é um recipiente ruim. Na verdade, é bastante útil. Ele só tem um nome ruim.

De volta a const_reference

Conforme apresentado acima e detalhado aqui , o que é ruim vector<bool>é que ele se comporta de maneira diferente no código genérico do que em outras vectorinstanciações. Aqui está um exemplo concreto:

#include <cassert>
#include <vector>

template <class T>
void
test(std::vector<T>& v)
{
    using const_ref = typename std::vector<T>::const_reference;
    const std::vector<T>& cv = v;
    const_ref cr = cv[0];
    assert(cr == cv[0]);
    v[0] = 1;
    assert(true == cv[0]);
    assert(cr == cv[0]);  // Fires!
}

int
main()
{
    std::vector<char> vc(1);
    test(vc);
    std::vector<bool> vb(1);
    test(vb);
}

A especificação padrão diz que a declaração marcada // Fires!será acionada, mas apenas quando testfor executada com um vector<bool>. Quando executado com um vector<char>(ou qualquer vectoralém boolquando um não-padrão apropriado Té atribuído), o teste passa.

A implementação da libc ++ buscou minimizar os efeitos negativos de ter um vector<bool>comportamento diferente no código genérico. Uma coisa que ele fez para conseguir isso foi fazer vector<T>::const_referenceuma referência de proxy , exatamente como o especificado vector<T>::reference, exceto que você não pode atribuir por meio dele. Ou seja, no libc ++, vector<T>::const_referenceé essencialmente um ponteiro para o bit dentro do vector, em vez de uma cópia desse bit.

Em libc ++, o acima testpassa para ambos vector<char>e vector<bool>.

A que custo?

A desvantagem é que essa extensão é detectável, conforme mostrado na pergunta. No entanto, poucos programas realmente se preocupam com o tipo exato desse alias e mais programas se preocupam com o comportamento.

Qual é a motivação para esta não conformidade?

Para dar ao cliente libc ++ um comportamento melhor em código genérico, e talvez depois de testes de campo suficientes, proponha esta extensão para um futuro padrão C ++ para o aprimoramento de toda a indústria C ++.

Essa proposta pode vir na forma de um novo contêiner (por exemplo bit_vector) que tem praticamente a mesma API de hoje vector<bool>, mas com algumas atualizações, como as const_referencediscutidas aqui. Seguido pela descontinuação (e eventual remoção) da vector<bool>especialização. bitsettambém poderia usar uma pequena atualização neste departamento, por exemplo const_reference, adicionar e um conjunto de iteradores.

Ou seja, em retrospectiva bitseté para vector<bool>(que deve ser renomeado para bit_vector- ou qualquer outra coisa), como arrayé para vector. E a analogia deve ser verdadeira, quer estejamos falando ou não sobre boolcomo value_typede vectore array.

Existem vários exemplos de recursos C ++ 11 e C ++ 14 que começaram como extensões em libc ++. É assim que os padrões evoluem. A experiência de campo positiva real demonstrada exerce forte influência. O pessoal dos padrões é um grupo conservador quando se trata de alterar as especificações existentes (como deveriam ser). Adivinhar, mesmo quando você tem certeza de que está adivinhando corretamente, é uma estratégia arriscada para desenvolver um padrão reconhecido internacionalmente.