Dave Harris <brangdon@cix.co.uk> wrote:

> dietmar_kuehl@yahoo.com () wrote (abridged):
> > That is, I claim that the change you ask for breaks code of most
> > users of 'std::vector<bool>' (not necessarily syntactically but
> > semantically because vectors something 8 and 32 times the currenty
> > size don't fit into memory anymore). This is not aceptable for
> > something which can be worked around as easily as this.
>
> Let's say the proposal is to have a specialisation of vector<bool> that is
> similar to vector<T> in every way, except that it adds flip(). So we get a
> proper container and all existing code continues to compile.

The "flip" member function was part of the "vector<bool>::reference"
type.  That type is a class, so it can have a member function.  For all
other versions, "vector<T>::reference" should be "T &", a type
expression which is obviously closed for extensions.

> The only issue is the memory overhead. However, the std says very little
> about memory costs in general, and especially about constant factors. So
> technically we can do this.

The dereference policy is a big issue.  It was basically a mistake to
create this type of specialization, since its interface is incompatible
with the main version (and with container requirements!).

> Let's further say we add a bit_vector class, so getting the memory
> efficiency back is easy; a Find&Replace job. And let's also accept the
> reality that when you upgrade your compiler, stuff is liable to break. You
> don't do it without testing.
>
> Given all that, is there any real user who prefers to keep the status quo?

More importantly, is there anyone that really needs the status quo?
It's needed if someone either needs the "flip" member function or is
abusing the fact that "vector<bool>::reference" is a class type (and/or
isn't "bool &").  I'm guessing that the amount of people that qualify
are few.

Right now, people who write function templates that use "vector<T>",
where "T" is one of the template parameters, risk breakage whenever "T"
is "bool" (due to the subtle interface mismatch).

> You say "most users", but I think that's pessimistic. Surely most users'
> vector<bools> do not take up 1/32th or 1/8th of their total memory? That's
> a big vector. Can you point to even 1 user who has done that? And even if
> you can, I want to ask them how they feel about this. As with the
> for-scope issue, the status quo is so broken I think even the people most
> affected will be willing to pay the cost of fixing it.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Hinnant <hinnant@metrowerks.com> wrote:

[SNIP]
> I believe the best we can possibly do for C++0X is deprecate the
> vector<bool> specialization, and only if we supply an alternative with
> vector<bool>'s current functionality.  And of course, I would like to
> see this alternative qualify as a container, or perhaps a proxied
> container (i.e. usable with most (all?) algorithms).

If the specialization won't be removed, and we supply an alternative, we
still have the original problem: there's no way to get a vector
container of "bool" with normal storage and reference semantics.  We
would have to have two special containers.

1.  bit_vector, the compact bit container (what the specialization
should have been)
2.  bool_vector, a 'normal' bool container (like an unspecialized
vector<bool> would have been)

Here vector<bool> would still act like bit_vector.  (Maybe there could
be macros controlling which behavior vector<bool> has.)

> Sorry if I sound discouraging.  But I'm trying to paint a realistic
> picture.  If there is any reader familiar with the standardization
> process who believes I'm depicting the situation too conservatively,
> please correct me.
[TRUNCATE]

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com wrote:
> If you are using a library which breaks when
> using 'std::vector<bool>' due to the specialization, I think it is
> a problem of the involved library.

Sorry for replying a second time to the same message, but something
interesting occurs to me.

By my reading of the C++ standard, then actually very few of the
mutating algorithms provided in the standard library have to function on
vector<bool>, as it fails to even provide forward iterators. While it
looks (on a brief search, and from personal experience) that most
library maintainers will try to make sure vector<bool> does function, it
looks like they don't have to?

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com () wrote (abridged):
> That is, I claim that the change you ask for breaks code of most
> users of 'std::vector<bool>' (not necessarily syntactically but
> semantically because vectors something 8 and 32 times the currenty
> size don't fit into memory anymore). This is not aceptable for
> something which can be worked around as easily as this.

Let's say the proposal is to have a specialisation of vector<bool> that is
similar to vector<T> in every way, except that it adds flip(). So we get a
proper container and all existing code continues to compile.

The only issue is the memory overhead. However, the std says very little
about memory costs in general, and especially about constant factors. So
technically we can do this.

Let's further say we add a bit_vector class, so getting the memory
efficiency back is easy; a Find&Replace job. And let's also accept the
reality that when you upgrade your compiler, stuff is liable to break. You
don't do it without testing.

Given all that, is there any real user who prefers to keep the status quo?

You say "most users", but I think that's pessimistic. Surely most users'
vector<bools> do not take up 1/32th or 1/8th of their total memory? That's
a big vector. Can you point to even 1 user who has done that? And even if
you can, I want to ask them how they feel about this. As with the
for-scope issue, the status quo is so broken I think even the people most
affected will be willing to pay the cost of fixing it.

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

caj@cs.york.ac.uk (Chris Jefferson) writes:

| dietmar_kuehl@yahoo.com wrote:
| > If you are using a library which breaks when
| > using 'std::vector<bool>' due to the specialization, I think it is
| > a problem of the involved library.

huh?!?  Don't shoot the messenger.  Fix the standard.

| Sorry for replying a second time to the same message, but something
| interesting occurs to me.
|
| By my reading of the C++ standard, then actually very few of the
| mutating algorithms provided in the standard library have to function
| on vector<bool>, as it fails to even provide forward iterators. While
| it looks (on a brief search, and from personal experience) that most
| library maintainers will try to make sure vector<bool> does function,
| it looks like they don't have to?

yes.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
 Texas A&M University -- Department of Computer Science
 301, Bright Building -- College Station, TX 77843-3112

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

With the controversy "std::vector<bool>" brings with its problematic
iterators, references, and its (lack of) matching sequence and container
requirements, I feel that using a specialization of "std::vector" for
the "bool" type as a way to pack bits is a failed experiment.
Conceptual types that are similar, but with at least one notable
difference in semantics, should be represented by completely different
types, and not by stuffing one type as a 'specialization' of the other!
Anyway, how would a user get normal semantics if s/he picked the chosen
specialization?  (In other words, how would someone get a "vector" of
"bool" with normal semantics?)  Let's end this controversy.

1.  For table 63, add the following row after the "bitset" one:

//==========================================
23.3.X bit_vector  <bit_vector>
//==========================================

Where "X" is a sub-sub-section number to be filled in later.

2.  For the beginning of s23.2 [lib.sequences], for the "Header <vector>
synopsis," the parts referring to "vector<bool>" are stricken.  (These
parts are on the top of page 477 [on the sheet] a.k.a. page 505 [in the
PDF file].)

3.  For s23.2.4 [lib.vector] paragraph 1, the final sentence shall be
changed to:

//==========================================
The elements of a vector are stored contiguously, meaning that if v is a
vector<T, Allocator>, then it obeys the identity &v[n] == &v[0] + n for
all 0 <= n < v.size().
//==========================================

(It removes any implication of a specialization for "bool".)

4.  Section 23.2.5 [lib.vector.bool] shall be stricken in its entirety.

5.  Section 23.3.X [lib.bit_vector] shall be added.

//==========================================
23.3.X  Class template bit_vector  [lib.bit_vector]

Header <bit_vector> synopsis

namespace std {

template < class Allocator = allocator<bool> > class bit_vector;

template < class Allocator >
    bool  operator ==( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);
template < class Allocator >
    bool  operator < ( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);
template < class Allocator >
    bool  operator !=( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);
template < class Allocator >
    bool  operator > ( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);
template < class Allocator >
    bool  operator >=( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);
template < class Allocator >
    bool  operator <=( const bit_vector<Allocator>& x,
                       const bit_vector<Allocator>& y);

template < class Allocator >
    void  swap( bit_vector<Allocator>& x, bit_vector<Allocator>& y);

}

The header <bit_vector> defines a class template and several related
functions for representing and manipulating sequences of bits within an
allocation optimized for space.  It provides an interface based on the
vector class template.

namespace std {

template <class Allocator> class bit_vector {
public:
    // types:
    typedef bool                                   const_reference;
    typedef implementation defined                 iterator;        //
See 23.1
    typedef implementation defined                 const_iterator;  //
See 23.1
    typedef implementation defined                 size_type;       //
See 23.1
    typedef implementation defined                 difference_type; //
See 23.1
    typedef bool                                   value_type;
    typedef Allocator                              allocator_type;
    typedef implementation defined                 pointer;
    typedef implementation defined                 const_pointer;
    typedef std::reverse_iterator<iterator>        reverse_iterator;
    typedef std::reverse_iterator<const_iterator>
const_reverse_iterator;

    // bit reference:
    class reference {
        friend class bit_vector;
        reference();
    public:
        _reference();
        operator bool() const;
        reference& operator =(const bool x);
        reference& operator =(const reference& x);
        void flip();  // flips the bit
    };

    // construct/copy/destroy:
    explicit  bit_vector(const Allocator& = Allocator());
    explicit  bit_vector(size_type n, const bool& value = bool(),
                         const Allocator& = Allocator());
              bit_vector(const bit_vector<Allocator>& x);
    template <class InputIterator>
              bit_vector(InputIterator first, InputIterator last,
                         const Allocator& = Allocator());

    ~bit_vector();

    bit_vector<Allocator>&  operator =(const bit_vector<Allocator>& x);
    template <class InputIterator>
        void                assign(InputIterator first, InputIterator
last);
    void                    assign(size_type n, const T& t);
    allocator_type          get_allocator() const;

    // iterators:
    iterator                begin();
    const_iterator          begin() const;
    iterator                end();
    const_iterator          end() const;
    reverse_iterator        rbegin();
    const_reverse_iterator  rbegin() const;
    reverse_iterator        rend();
    const_reverse_iterator  rend() const;

    // capacity:
    size_type  size() const;
    size_type  max_size() const;

    void       resize(size_type sz, bool c = false);
    size_type  capacity() const;
    bool       empty() const;
    void       reserve(size_type n);

    // element access:
    reference        operator [](size_type n);
    const_reference  operator [](size_type n) const;
    const_reference  at(size_type n) const;
    reference        at(size_type n);
    reference        front();
    const_reference  front() const;
    reference        back();
    const_reference  back() const;

    // modifiers:
    void         push_back(const bool& x);
    void         pop_back();
    iterator     insert(iterator position, const bool& x);
    void         insert (iterator position, size_type n, const bool& x);
    template <class InputIterator>
        void     insert(iterator position, InputIterator first,
                        InputIterator last);

    iterator     erase(iterator position);
    iterator     erase(iterator first, iterator last);

    void         swap(bit_vector<Allocator>&);
    static void  swap(reference x, reference y);

    void         flip();  // flips all bits
    void         clear();
};

template <class Allocator>
    bool operator ==(const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);
template <class Allocator>
    bool operator < (const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);
template <class Allocator>
    bool operator !=(const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);
template <class Allocator>
    bool operator > (const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);
template <class Allocator>
    bool operator >=(const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);
template <class Allocator>
    bool operator <=(const bit_vector<Allocator>& x,
                     const bit_vector<Allocator>& y);

// specialized algorithms:
template <class Allocator>
    void swap(bit_vector<Allocator>& x, bit_vector<Allocator>& y);

}

reference is a class that simulates the behavior of references of a
single bit in bit_vector<>.

//==========================================

(It's basically a rip-off of the old 23.2.5 section.)

I guess this would be too late for TR1; it should be considered for
whenever the next update cycle is.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1gt9c32.axublguwdygsN%thedl0-usenet1@yahoo.com>,
 thedl0-usenet1@yahoo.com (Daryle Walker) wrote:

> With the controversy "std::vector<bool>" brings with its problematic
> iterators, references, and its (lack of) matching sequence and container
> requirements, I feel that using a specialization of "std::vector" for
> the "bool" type as a way to pack bits is a failed experiment.
> Conceptual types that are similar, but with at least one notable
> difference in semantics, should be represented by completely different
> types, and not by stuffing one type as a 'specialization' of the other!
> Anyway, how would a user get normal semantics if s/he picked the chosen
> specialization?  (In other words, how would someone get a "vector" of
> "bool" with normal semantics?)  Let's end this controversy.

I'm really glad you proposed this.  I made a verbal offer to the LWG to
create a similar proposal and received a luke warm response.  But now
that I know that at least one other person on the planet would like to
see this happen, I'm more motivated to do the work.  I would be
interested in knowing if there are only two of us on the planet, or if
there are more that feel as we do.

Caveat:  We can not remove vector<bool> as you propose.  Instead C++0X
would need to simultaneously introduce bit_vector and deprecate (not
remove) vector<bool>.  The backward compatibility hit on this one is big
enough that it needs a gentle transition.  Hopefully C++1X would finally
remove vector<bool>.  This is a very long term operation.

Caveat^2:  Vendors may be encouraged to remove vector<bool> as a
non-conforming option in C++0X.  Metrowerks already offers such an
option.  This would make the next decade a bit more palatable for those
looking to make use of the "real" vector<bool>.

Quibbles:

1.  Should we spell it bit_vector or bitvector?  I like the former
better for reading, but the latter is consistent with bitset.

2.  I think we can do better than:

typedef bool    const_reference;

I would like to see bit_vector<>::const_reference more closely reflect
the behavior of a const bool&.  For example:

#include <bit_vector>
#include <cassert>

int main()
{
    bit_vector<> bv(3);
    bit_vector<>::const_reference cr = bv[0];
    assert(cr == false);
    bv[0] = true;
    assert(cr == true);
}

The second assert will fire if const_reference is simply a bool, instead
of a smart const reference into the bit_vector.

3.  Interoperability between pointers and references:

Taking the address of a (const_)reference should give you a
bit_vector<>::(const_)pointer, which subsequently can be dereferenced to
give you back a bit_vector<>::(const_)reference.  An easy way to think
about this is simply that the iterators and pointers are the same type
(though they shouldn't be required to be the same), and the iterators
dereferenced will give you references, and if you take the address of a
reference, you get a pointer (which may also be an iterator).

#include <bit_vector>
#include <cassert>

int main()
{
    bit_vector<> bv(3);
    bit_vector<>::const_reference cr = bv[0];
    bit_vector<>::const_pointer cp = &cr;
    assert(cr == false);
    assert(*cp == false);
    bv[0] = true;
    assert(cr == true);
    assert(*cp == true);
}

4.  Add other bitset-like operations?  I'm especially thinking of:

any, none, count, shift, &, |, ^, ~ which can be made very much more
efficient with the packed data structure, compared with a "real"
vector<bool>.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Howard Hinnant,

Howard Hinnant schrieb:

>I'm really glad you proposed this.  I made a verbal offer to the LWG to
>create a similar proposal and received a luke warm response.  But now
>that I know that at least one other person on the planet would like to
>see this happen, I'm more motivated to do the work.  I would be
>interested in knowing if there are only two of us on the planet, or if
>there are more that feel as we do.
>
I also strongly support the proposal to provide a replacement class
template for std::vector<bool>.

>Quibbles:
>
>1.  Should we spell it bit_vector or bitvector?  I like the former
>better for reading, but the latter is consistent with bitset.
>
I like the naming choice of boost, namely dynamic_bitset. It seems a bit
;-) irritating to use either a "set"
or a "vector" suffix.

>2.  I think we can do better than:
>
>typedef bool    const_reference;
>
>I would like to see bit_vector<>::const_reference more closely reflect
>the behavior of a const bool&.  For example:
>
>#include <bit_vector>
>#include <cassert>
>
>int main()
>{
>    bit_vector<> bv(3);
>    bit_vector<>::const_reference cr = bv[0];
>    assert(cr == false);
>    bv[0] = true;
>    assert(cr == true);
>}
>
>The second assert will fire if const_reference is simply a bool, instead
>of a smart const reference into the bit_vector.
>
>3.  Interoperability between pointers and references:
>
>Taking the address of a (const_)reference should give you a
>bit_vector<>::(const_)pointer, which subsequently can be dereferenced to
>give you back a bit_vector<>::(const_)reference.  An easy way to think
>about this is simply that the iterators and pointers are the same type
>(though they shouldn't be required to be the same), and the iterators
>dereferenced will give you references, and if you take the address of a
>reference, you get a pointer (which may also be an iterator).
>
>#include <bit_vector>
>#include <cassert>
>
>int main()
>{
>    bit_vector<> bv(3);
>    bit_vector<>::const_reference cr = bv[0];
>    bit_vector<>::const_pointer cp = &cr;
>    assert(cr == false);
>    assert(*cp == false);
>    bv[0] = true;
>    assert(cr == true);
>    assert(*cp == true);
>}
>
I like this more symmetric reference-const_reference behaviour, you
propose. Others might not like
the additional overhead of const_reference's, but one could add a

bool test(size_type n) const;

member function for those more efficient uses.

>4.  Add other bitset-like operations?  I'm especially thinking of:
>
>any, none, count, shift, &, |, ^, ~ which can be made very much more
>efficient with the packed data structure, compared with a "real"
>vector<bool>.
>
Absolutely. And I would like to emphasize that the current
boost::dynamic_set template interface
allows user-defined block sizes. Further noteworthy member functions are
is_subset_of, is_proper_subset_of,
find_first, find_next as well as the  the block-related functions and
one might consider the following member
functions of the reference class:

        reference& operator|=(bool value);
        reference& operator&=(bool value);
        reference& operator^=(bool value);
        reference& operator-=(bool value);

Good luck for the proposal and warm greetings from Bremen,

Daniel





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com wrote:
> Daryle Walker wrote:
>
>>But tweaking the iterator or sequence rules won't help if the user
>>problem is that s/he needs "std::vector<bool>" to have the normal
>>storage and/or reference semantics as the regular version.
>>Optimizations that break these semantics should have been bumped to a
>>different class.
>
>
> Changing 'std::vector<bool>' to become something different will break
> existing code.

Just out of curiosity, what would break if the std::vector<bool>
specialisation was removed? Obviously vector<bool>s would get 8 times
larger (ish, OK I realise that is system specific)..

I get annoyed that I have a library which uses vector<T>s, and in at
least one place I've found that I got bitten by the vector<bool>
specialisation..

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Howard Hinnant,

Howard Hinnant schrieb:

>I like these suggestions, especially is_subset_of, is_proper_subset_of,
>find_first, find_next.
>
>But the block-related functionality is making me nervous (and actually
>I'm not positive why).  Perhaps it is overexposure of the internal data
>structure.  It would be like exposing the segments of a deque.
>
Actually one of the most prominent critiques of the std::deque interface
is the **lack** of access to
the segment structure. I don't mean a reference based access, but the
simple fact, that even the segment
**size** cannot be influenced by the programmer. I really don't
understand why. Maybe one of the
main reasons for providing deque as a std container was, that during
those times some prominent
platforms had severe restrictions concerning en-block-allocations and
thus to provide users of the
std container library an "extended" std::vector which most often used
the greatest possible segement
size. This is a very simplified view, I know, and I don't want to
widespread misinformation here, but on
the other side I can't see, why the deque-segement size should be
implementation-defined as currently
the case. The reason for challenging this current state is, that due to
my own experience the user of
a deque usually has much more knowledge for a reasonable segment size,
if s/he wants to take advantage
of corresponding effects of insertion/deletion costs, because only the
user can be aware of expected
sizes and thus expected **real** costs (not only O-notational ones) of
these mutable operations.
A template std::size_t param with a reasonable implementation-defined
default size seems a good design
choice for those not interested into such details.
Of course I see proposed change this would make currently possible
implementations invalid, but I don't
have a survey concerning the current state of real-life-implementations
of std::deque. That brings me to your
other sentence:

>Perhaps if there were a concepts framework along the lines of a
>"segmented container" this would fit neatly into that.
>
This could be an interesting sub-categorization of the current containers.
But the main question is: Can anything in the current library take advantage
of such further divison or is it only a help for human's intellect? Currently
I assume, that the very simple segment support I speak of can't be used in a
generic way (w/o knowing more details), but I would like to be disproved.

Concerning your jumpiness with the segment structure exposure of std::deque
I can say that I wouldnt' have any problems with a segment_vector container, but
this kind of fallback has the disadvantage that we have one **further** container
in the std library and this seems most propably not justified (Concerning the introduction
of something like dynamic_bitset I have another position).

Can anyone say something concerning the current state of deque implementations which
are not segment-based? Or whether s/he sees any real problems in adding a simplified
segment interface to std::deque?

Greetings from Bremen,

Daniel




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chris Jefferson wrote:
> Just out of curiosity, what would break if the std::vector<bool>
> specialisation was removed?

The obvious problem is the lack of a 'flip()' method for 'bool'
objects. Of course, this could theoretically be avoided by
equipping the built-in type 'bool' with a 'flip()' method.

> Obviously vector<bool>s would get 8 times larger (ish, OK I realise
> thatis system specific)..

I have seen systems with 'sizeof(bool) == 4', i.e. the additional
memory requirements could increase by a factor of up to 32 (well,
theoretically even more but I have never worked on a system where
a 'char' had more than 8 bits). However, even a factor of 8 is
likely to cause problems for large 'std::vector<bool>'. For example,
just assume you got an implementation of the Sieve of Eratosthenes
which barely fits into your memory: the need to page the additional
memory will almost certainly kill the performance if not the
program at all (after all, who uses swap files eight times bigger
than their memory).

> I get annoyed that I have a library which uses vector<T>s, and in at
> least one place I've found that I got bitten by the vector<bool>
> specialisation..

. and I get annoyed by people who state that someone's code using
a [non-deprecated] feature of the standard C++ library "deserves
to break" (OK, this statement was tentatively made and was in a
different subthread). If you are using a library which breaks when
using 'std::vector<bool>' due to the specialization, I think it is
a problem of the involved library. And I would be interested in
what "got bitten by the vector<bool>" means? Sure, you need to
use 'std::vector<T>::reference' if you want to hold a reference to
an element in a vector but this is not that bad. The only scenario
where 'std::vector<bool>' cannot be made to work is when you want
to obtain its internal representation ('&v[0]') but this is
intended to cope with C legacy interface and C does not have a
'bool' type. Sure, 'std::vector<bool>' is not a container but this
can be fixed rather differently (see elsewhere in this thread).
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com wrote:
.
 > And I would be interested in
> what "got bitten by the vector<bool>" means?

(First of all I think I've come to agree it's too late to take
vector<bool> out now, although I stand by that it should never have been
there in the first place, and compressed vector symantics been provided
by a specialised type..)

My problem (which I'm still having) is that given a
vector<bool>::iterator i, then *i is a temporary so I can't pass it to
functions expecting a "T& t". I therefore have to write a special case
for vector<bool>::iterator (or just ignore it..)

Out of curiosity (slightly off track I realise..) is there a good way to
"detect" if *i is a temporary and then dispatch to a correct function
accordingly (espically when I know that it won't be const) I've tried
playing a few times to catch if I can map it to const T& or T& and then
design the function accordingly, but I've never quite got it to work
properly...

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr=FCgler (ne Spangenberg) wrote:
> Actually one of the most prominent critiques of the std::deque interfac=
e=20
> is the **lack** of access to
> the segment structure. I don't mean a reference based access, but the=20
> simple fact, that even the segment
> **size** cannot be influenced by the programmer. I really don't=20
> understand why. Maybe one of the
> main reasons for providing deque as a std container was, that during=20
> those times some prominent
> platforms had severe restrictions concerning en-block-allocations and=20
> thus to provide users of the
> std container library an "extended" std::vector which most often used=20
> the greatest possible segement
> size.

I suspect it's much  simpler than that. The perceived benefit is too=20
small to justify the added complexity. But don't let that stop you: if=20
you want this feature, design your own container, use it, get some=20
real-world experience with it, and propose it.

--=20

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chris Jefferson <caj@cs.york.ac.uk> wrote:

> dietmar_kuehl@yahoo.com wrote:
> .
>  > And I would be interested in
> > what "got bitten by the vector<bool>" means?
>
> (First of all I think I've come to agree it's too late to take
> vector<bool> out now, although I stand by that it should never have been
> there in the first place, and compressed vector symantics been provided
> by a specialised type..)
>
> My problem (which I'm still having) is that given a
> vector<bool>::iterator i, then *i is a temporary so I can't pass it to
> functions expecting a "T& t". I therefore have to write a special case
> for vector<bool>::iterator (or just ignore it..)
>
> Out of curiosity (slightly off track I realise..) is there a good way to
> "detect" if *i is a temporary and then dispatch to a correct function
> accordingly (espically when I know that it won't be const) I've tried
> playing a few times to catch if I can map it to const T& or T& and then
> design the function accordingly, but I've never quite got it to work
> properly...
>
> Chris
>
 in the standard no, but boost type_traits alon with
std::iterator_traits might help. Something like this??

template <class Iter> struct is_proxy:boost::is_same
<
 typename std::iterator_traits<Iter>::value_type &,
 typename std::iterator_traits<Iter>::reference
>
{
}:


{


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com <dietmar_kuehl@yahoo.com> wrote:

[SNIP]
> Actually, I would not even deprecate the class! If you don't like
> 'std::vector<bool>'s behavior, propose the addition of a class template
> which has the same semantics as 'std::vector<T>' but without the
> specialization for 'bool'.

Then some newbie a few years will ask "why do we have two class
templates that are 99% identical?".  The best way this should work is if
we make such a never-specialized "new_vector" template, then we should
depreciate "vector" totally, both the general case and its "bool"
specialization.  And we make a compact "bit_vector" container type.

We still have the problem of not having a conventional container of
"bool" with normal storage and reference semantics.  Maybe we should
make a "std::bool_vector" that acts like an unspecialized
"std::vector<bool>" would have.  Then at least we'll get the desired
missing semantic in the standard.  (But the future newbie will ask why
"std::bool_vector" and "std::vector<bool>" weren't swapped.  I'll let
you answer his/her query.)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Hinnant wrote:
> I would be
> interested in knowing if there are only two of us on the planet, or
if
> there are more that feel as we do.

As said before, I don't think changing 'std::vector<bool>' in any form
is the right fix! In fact, I think it an entirely wrong direction to
go.
The right fix, IMO, is to correct the concepts algorithms operate upon.
The iterator stuff which was temporarily in the TR1 draft but retracted
was a step into the right direction allowing proxy containers like
'std::vector<bool>'. The complete step would be a separation of
iterator
concepts into cursor and property map concepts for position and
property
access, respectively. This would also allow addressing various problems
resulting from the iterator/const_iterator dichotomy.

The single real complaint I see with 'std::vector<bool>' is that it has
made an optimization choice some are uncomfortable with: it trades [the
possibility of] a size reduction for speed. Since I consider the
containers in the standard C++ library as examples for sequence, albeit
useful in many cases, this is no real problem: it is fairly easy to
create a sequence resembling 'std::vector<T>' if profiling has shown
that 'std::vector<bool>' is indeed a problem.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1110813971.028869.239970@l41g2000cwc.googlegroups.com>,
 "dietmar_kuehl@yahoo.com" <dietmar_kuehl@yahoo.com> wrote:

> Howard Hinnant wrote:
> > I would be
> > interested in knowing if there are only two of us on the planet, or
> if
> > there are more that feel as we do.
>
> As said before, I don't think changing 'std::vector<bool>' in any form
> is the right fix! In fact, I think it an entirely wrong direction to
> go.
> The right fix, IMO, is to correct the concepts algorithms operate upon.
> The iterator stuff which was temporarily in the TR1 draft but retracted
> was a step into the right direction allowing proxy containers like
> 'std::vector<bool>'. The complete step would be a separation of
> iterator
> concepts into cursor and property map concepts for position and
> property
> access, respectively. This would also allow addressing various problems
> resulting from the iterator/const_iterator dichotomy.
>
> The single real complaint I see with 'std::vector<bool>' is that it has
> made an optimization choice some are uncomfortable with: it trades [the
> possibility of] a size reduction for speed. Since I consider the
> containers in the standard C++ library as examples for sequence, albeit
> useful in many cases, this is no real problem: it is fairly easy to
> create a sequence resembling 'std::vector<T>' if profiling has shown
> that 'std::vector<bool>' is indeed a problem.

You make a very good point here that I half way agree with. :-)

While I still favor transitioning vector<bool> to another container, I
also fully support making that other container (bitvector or whatever
it's called) a full fledged first-class citizen in the "STL world".  And
that means doing exactly the work you allude to:  fixing
iterator/algorithm concepts.

Exactly how all that is done is still an area of interesting debate, and
I genuinely hope that work continues.

The reason I still favor transitioning the vector<bool> specialization
out is simply that the vector<bool> specialization is detectible, and
has different semantics (albeit only slightly) than the non-specialized
vector<bool>.  Thus it occasionally surprises the client.

But both the specialized vector<bool> and the unspecialized vector<bool>
semantics are very useful.  We need both.  And I would like both to be
first class citizens.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dietmar_kuehl@yahoo.com <dietmar_kuehl@yahoo.com> wrote:

> Howard Hinnant wrote:
> > I would be interested in knowing if there are only two of us on the
> > planet, or if there are more that feel as we do.
>
> As said before, I don't think changing 'std::vector<bool>' in any form is
> the right fix! In fact, I think it an entirely wrong direction to go. The
> right fix, IMO, is to correct the concepts algorithms operate upon. The
> iterator stuff which was temporarily in the TR1 draft but retracted was a
> step into the right direction allowing proxy containers like
> 'std::vector<bool>'. The complete step would be a separation of iterator
> concepts into cursor and property map concepts for position and property
> access, respectively. This would also allow addressing various problems
> resulting from the iterator/const_iterator dichotomy.
>
> The single real complaint I see with 'std::vector<bool>' is that it has
> made an optimization choice some are uncomfortable with: it trades [the
> possibility of] a size reduction for speed. Since I consider the
> containers in the standard C++ library as examples for sequence, albeit
> useful in many cases, this is no real problem: it is fairly easy to create
> a sequence resembling 'std::vector<T>' if profiling has shown that
> 'std::vector<bool>' is indeed a problem.

But tweaking the iterator or sequence rules won't help if the user
problem is that s/he needs "std::vector<bool>" to have the normal
storage and/or reference semantics as the regular version.
Optimizations that break these semantics should have been bumped to a
different class.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Hinnant <hinnant@metrowerks.com> wrote:

> In article <1gt9c32.axublguwdygsN%thedl0-usenet1@yahoo.com>,
>  thedl0-usenet1@yahoo.com (Daryle Walker) wrote:
>
> > With the controversy "std::vector<bool>" brings with its problematic
> > iterators, references, and its (lack of) matching sequence and container
> > requirements, I feel that using a specialization of "std::vector" for
> > the "bool" type as a way to pack bits is a failed experiment.
> > Conceptual types that are similar, but with at least one notable
> > difference in semantics, should be represented by completely different
> > types, and not by stuffing one type as a 'specialization' of the other!
> > Anyway, how would a user get normal semantics if s/he picked the chosen
> > specialization?  (In other words, how would someone get a "vector" of
> > "bool" with normal semantics?)  Let's end this controversy.
>
> I'm really glad you proposed this.  I made a verbal offer to the LWG to
> create a similar proposal and received a luke warm response.  But now
> that I know that at least one other person on the planet would like to
> see this happen, I'm more motivated to do the work.  I would be
> interested in knowing if there are only two of us on the planet, or if
> there are more that feel as we do.
>
> Caveat:  We can not remove vector<bool> as you propose.  Instead C++0X
> would need to simultaneously introduce bit_vector and deprecate (not
> remove) vector<bool>.  The backward compatibility hit on this one is big
> enough that it needs a gentle transition.  Hopefully C++1X would finally
> remove vector<bool>.  This is a very long term operation.

Doesn't the "bool" specialization have the same external interface as
the mainline version?  The only difference would be for programmers that
exploited the fact that the specialization's iterators and references
couldn't act like conventional ones (i.e. exactly or like "bool *" and
"bool &").  Maybe that code deserves to break, especially if we're going
to add other breaking changes to the next revision of C++.

> Caveat^2:  Vendors may be encouraged to remove vector<bool> as a
> non-conforming option in C++0X.  Metrowerks already offers such an
> option.  This would make the next decade a bit more palatable for those
> looking to make use of the "real" vector<bool>.
>
> Quibbles:
>
> 1.  Should we spell it bit_vector or bitvector?  I like the former
> better for reading, but the latter is consistent with bitset.
>
> 2.  I think we can do better than:
>
> typedef bool    const_reference;
>
> I would like to see bit_vector<>::const_reference more closely reflect
> the behavior of a const bool&.  For example:
>
> #include <bit_vector>
> #include <cassert>
>
> int main()
> {
>     bit_vector<> bv(3);
>     bit_vector<>::const_reference cr = bv[0];
>     assert(cr == false);
>     bv[0] = true;
>     assert(cr == true);
> }
>
> The second assert will fire if const_reference is simply a bool, instead
> of a smart const reference into the bit_vector.
>
> 3.  Interoperability between pointers and references:
>
> Taking the address of a (const_)reference should give you a
> bit_vector<>::(const_)pointer, which subsequently can be dereferenced to
> give you back a bit_vector<>::(const_)reference.  An easy way to think
> about this is simply that the iterators and pointers are the same type
> (though they shouldn't be required to be the same), and the iterators
> dereferenced will give you references, and if you take the address of a
> reference, you get a pointer (which may also be an iterator).

But how would you get the actual address of the reference object itself?

> #include <bit_vector>
> #include <cassert>
>
> int main()
> {
>     bit_vector<> bv(3);
>     bit_vector<>::const_reference cr = bv[0];
>     bit_vector<>::const_pointer cp = &cr;
>     assert(cr == false);
>     assert(*cp == false);
>     bv[0] = true;
>     assert(cr == true);
>     assert(*cp == true);
> }
>
> 4.  Add other bitset-like operations?  I'm especially thinking of:
>
> any, none, count, shift, &, |, ^, ~ which can be made very much more
> efficient with the packed data structure, compared with a "real"
> vector<bool>.

Maybe (but you can't do ~ in a mathematically defined way, it only works
for fixed-sized registers).

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daryle Walker wrote:
> But tweaking the iterator or sequence rules won't help if the user
> problem is that s/he needs "std::vector<bool>" to have the normal
> storage and/or reference semantics as the regular version.
> Optimizations that break these semantics should have been bumped to a
> different class.

Changing 'std::vector<bool>' to become something different will break
existing code. Thus, it is effectively a non-option to change it to
something else without a migration strategy which ascertains that no
code will break. In the past 'std::vector<bool>' was used as a test
case for such migration strategy but none was brought up which is
suitable, AFAIK. The best we can do is changing the rules for concepts
which have no impact on existing code (i.e. essentially relaxing the
requirements) to give guarantees which do not yet exist.

If you need a vector class which works differently than the current
one you will need to create your own. However, this is not at all
hard. In fact, the whole idea behind the STL is that user can easily
create their own sequences and still have all algorithms which can
reasonably be applied to such sequence. The containers in the standard
C++ library should be considered example, albeit generally quite useful
ones. If you like, you can consider 'std::vector<bool>' as an example
of something you should probably not do although this was not really
the intention.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daryle Walker wrote:
> Doesn't the "bool" specialization have the same external interface as
> the mainline version?  The only difference would be for programmers
that
> exploited the fact that the specialization's iterators and references
> couldn't act like conventional ones (i.e. exactly or like "bool *"
and
> "bool &").  Maybe that code deserves to break, especially if we're
going
> to add other breaking changes to the next revision of C++.

There are simple work-arounds for the 'std::vector<bool>'
specialization
and thus this does not warrant to break existing code. In fact, I
wonder
which other purpose using a 'std::vector<bool>' could have than having
a
compact representation of some binary value. That is, I claim that the
change you ask for breaks code of most users of 'std::vector<bool>'
(not
necessarily syntactically but semantically because vectors something 8
and 32 times the currenty size don't fit into memory anymore). This is
not aceptable for something which can be worked around as easily as
this.
Actually, I'm a little bit surprised that some code "deserves" to break
just because it uses a feature someone else does not like? Admittedly,
it
can be considered an error but it still is a useful feature for some.
.and the reason it can be seen as an error (the lack of
interoperability with algorithm requirements) can be corrected without
breaking anyone's code! I think that code shall not be broken unless
there is no alternative. 'std::vector<bool>' does not fit this
description. Actually, I would not even deprecate the class! If you
don't
like 'std::vector<bool>'s behavior, propose the addition of a class
template which has the same semantics as 'std::vector<T>' but without
the
specialization for 'bool'.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1gth05c.gzeuqrh12bnzN%thedl0-usenet1@yahoo.com>,
 thedl0-usenet1@yahoo.com (Daryle Walker) wrote:

> > Caveat:  We can not remove vector<bool> as you propose.  Instead C++0X
> > would need to simultaneously introduce bit_vector and deprecate (not
> > remove) vector<bool>.  The backward compatibility hit on this one is big
> > enough that it needs a gentle transition.  Hopefully C++1X would finally
> > remove vector<bool>.  This is a very long term operation.
>
> Doesn't the "bool" specialization have the same external interface as
> the mainline version?  The only difference would be for programmers that
> exploited the fact that the specialization's iterators and references
> couldn't act like conventional ones (i.e. exactly or like "bool *" and
> "bool &").  Maybe that code deserves to break, especially if we're going
> to add other breaking changes to the next revision of C++.

Almost, not quite.  There is the flip member, which is a fairly minor
addition.  I suspect the extra storage space would be the main problem
in the field, or possibly the binary incompatibility.

Exactly what the backwards compatibility limits are with C++0X haven't
really been worked out.  They will probably be considered on a case by
case basis.

I'm sure most backwards incompatibilities will be taken most seriously.
The only ones I can think of that might not be considered too seriously
are those caused by conflicts will all lowercase user-defined macros
(e.g. the class template "shared_ptr" is introduced, which could break a
user-defined macro "shared_ptr").  And even that one may be fixed by a
new macro scoping mechanism.

Even if I strongly agreed with you about removing the vector<bool>
specialization in C++0X, I'm 90% sure that I could never convince the
LWG, much less the full committee that this would be a good move, at
least not without massive, very outspoken support.  If you (and others)
feel strongly that this is the correct thing to do, it will take a
massive, multi-year effort on your parts to attempt it - including
attendance to many, if not most, of the committee meetings between now
and then.  And a very possible (if not likely) outcome will be that
vector<bool> stays unchanged for C++0X.

I believe the best we can possibly do for C++0X is deprecate the
vector<bool> specialization, and only if we supply an alternative with
vector<bool>'s current functionality.  And of course, I would like to
see this alternative qualify as a container, or perhaps a proxied
container (i.e. usable with most (all?) algorithms).

Sorry if I sound discouraging.  But I'm trying to paint a realistic
picture.  If there is any reader familiar with the standardization
process who believes I'm depicting the situation too conservatively,
please correct me.

> But how would you get the actual address of the reference object itself?

<shrug> you wouldn't (short of something along the lines of
boost::address_of).  How do you get the actual address of a real
reference?  Answer:  You don't,  you instead get a pointer to the
referenced object.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <42354849$0$4355$4d4ebb8e@businessnews.de.uu.net>,
 "Daniel Kr   gler (ne Spangenberg)" <dsp@bdal.de> wrote:

> >4.  Add other bitset-like operations?  I'm especially thinking of:
> >
> >any, none, count, shift, &, |, ^, ~ which can be made very much more
> >efficient with the packed data structure, compared with a "real"
> >vector<bool>.
> >
> Absolutely. And I would like to emphasize that the current
> boost::dynamic_set template interface
> allows user-defined block sizes. Further noteworthy member functions are
> is_subset_of, is_proper_subset_of,
> find_first, find_next as well as the  the block-related functions and
> one might consider the following member
> functions of the reference class:
>
>         reference& operator|=(bool value);
>         reference& operator&=(bool value);
>         reference& operator^=(bool value);
>         reference& operator-=(bool value);

I like these suggestions, especially is_subset_of, is_proper_subset_of,
find_first, find_next.

But the block-related functionality is making me nervous (and actually
I'm not positive why).  Perhaps it is overexposure of the internal data
structure.  It would be like exposing the segments of a deque.

Perhaps if there were a concepts framework along the lines of a
"segmented container" this would fit neatly into that.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hinnant@metrowerks.com (Howard Hinnant) wrote in message news:<hinnant-0BE3A3.19543414032005@syrcnyrdrs-01-ge0.nyroc.rr.com>...
> The reason I still favor transitioning the vector<bool> specialization
> out is simply that the vector<bool> specialization is detectible, and
> has different semantics (albeit only slightly) than the non-specialized
> vector<bool>.

Not slightly at all. vector<T> is a contiguous array of T traversible
by T*. vector<bool> is not. It is an abomination. It must die. Where's
my pill.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]