libc ++의 벡터는 왜

libc ++의 벡터는 왜:: const_reference가 bool이 아닙니까?

---

섹션 23.3.7 클래스 vector<bool>[vector.bool], 단락 1은 다음과 같이 설명합니다.

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

그러나이 프로그램은 libc ++를 사용할 때 컴파일되지 않습니다.

#include <vector>
#include <type_traits>

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

또한 C ++ 표준은이 사양에서 C ++ 98로 거슬러 올라갈 때까지 일관 적이었습니다. 그리고 libc ++는 libc ++가 처음 도입 된 이후로이 사양을 지속적으로 따르지 않았습니다.

이 부적합의 동기는 무엇입니까?

---

이 확장에 대한 동기는 준수 프로그램에 의해 감지되어 부적합 하며 참조 (const 및 기타)와 관련하여 vector<bool>더 유사 하게 동작 하도록 만드는 것 vector<char>입니다.

소개

1998 년부터 vector<bool>"그렇지 않은 컨테이너"로 조롱되었습니다. 최초의 LWG 문제 중 하나 인 LWG 96 이 토론을 시작했습니다. 17 년이 지난 오늘날에는 vector<bool>거의 변함이 없습니다.

이 백서 에서는의 동작이의 vector<bool>다른 모든 인스턴스화와 어떻게 다른지 에 대한 몇 가지 특정 예제를 살펴보고 vector일반 코드를 손상시킵니다. 그러나 동일한 문서에서는 vector<bool>제대로 구현 된 경우 매우 좋은 성능 속성 이 가질 수있는 것에 대해 자세히 설명 합니다.

요약 : vector<bool>나쁜 컨테이너가 아닙니다. 실제로 매우 유용합니다. 이름이 좋지 않습니다.

돌아가다 const_reference

위에서 소개하고 여기 에 자세히 설명 했듯이 나쁜 점 vector<bool>은 일반 코드에서 다른 vector인스턴스화 와 다르게 동작한다는 것 입니다. 다음은 구체적인 예입니다.

#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);
}

표준 규격은 어설 표시된 것을 말한다 // Fires!트리거하지만 경우에만 test으로 실행됩니다 vector<bool>. 로모그래퍼 실행하면 vector<char>(또는 vector외에 bool적절한 기본이 아닌이 때 T할당), 시험은 통과한다.

The libc++ implementation sought to minimize the negative effects of having vector<bool> behave differently in generic code. One thing it did to achieve this is to make vector<T>::const_reference a proxy-reference, just like the specified vector<T>::reference, except that you can't assign through it. That is, on libc++, vector<T>::const_reference is essentially a pointer to the bit inside the vector, instead of a copy of that bit.

On libc++ the above test passes for both vector<char> and vector<bool>.

At what cost?

The downside is that this extension is detectible, as shown in the question. However, very few programs actually care about the exact type of this alias, and more programs care about the behavior.

What is the motivation for this non-conformance?

To give the libc++ client better behavior in generic code, and perhaps after sufficient field testing, propose this extension to a future C++ standard for the betterment of the entire C++ industry.

Such a proposal might come in the form of a new container (e.g. bit_vector) that has much the same API as today's vector<bool>, but with a few upgrades such as the const_reference discussed here. Followed by deprecation (and eventual removal) of the vector<bool> specialization. bitset could also use a little upgrading in this department, e.g. add const_reference, and a set of iterators.

That is, in hindsight bitset is to vector<bool> (which should be renamed to bit_vector -- or whatever), as array is to vector. And the analogy ought to hold true whether or not we are talking about bool as the value_type of vector and array.

There are multiple examples of C++11 and C++14 features that started out as extensions in libc++. This is how standards evolve. Actual demonstrated positive field experience carries strong influence. The standards folk are a conservative bunch when it comes to changing existing specifications (as they should be). Guessing, even when you are sure you are guessing correctly, is a risky strategy for evolving an internationally recognized standard.

참고URL : https://stackoverflow.com/questions/31974237/why-is-libcs-vectorboolconst-reference-not-bool