On Monday, August 26, 2013 12:46:26 AM UTC-7, Bengt Gustaf= sson wrote:

=20 =20 =20
I was just trying to be pragmatic about solving the actual problems we are discussing, which should be problems that are of interest to real programmer's use of the language. I freely admit that the vector<bool> specialization is a wart but I don't see that this actually creates a lot of problems in the real world. Could anyone exemplify a reasonable usage that fails in a hard to detect way?

It's not that it fails in a "hard t= o detect" way. Generally speaking, when vector<bool> fails to act lik= e a `vector` of `bool`s, it's pretty noisy about it. The problem is that, s= ilent or not, if you really needed an honest-to-God `vector` that contains = `bool`s, you can't get one.

=20 The real problems I could detect with vector<bool> were that the performance of algorithms like count() is significantly less than it could be. I suggested how this could be solved in a way that is totally invisible to the programmer. I also suggested that the API required could be standardized to allow user-defined algorithms to take advantage of the speedup.

From a practical programmer's standpoint I think it is very n= eat that vector<bool> hides the fact that there is a special implementation underneath.

If it actually hi= d the fact, that might be true. But it doesn't. Consider the following:
=

void OperateOnBoolArray(const bool *array, size_t count);
=

vector=
<bool> stuff =
=3D {...};
OperateOnBoolArray<=
span style=3D"color: #660;" class=3D"styled-by-prettify">(stuff.data(), stuff.size());

If the types here were anything besi= des `bool`, this would be perfectly legitimate code. But it's not..
=
Nothing is being hidden here; `vector<bool>` is not a `vector`. I= t doesn't provide the interface for a vector. And if you think this is too = theoretical, consider some template code:

template<class T>
void <= /span>Proc= ()
{
vector<T> arr =3D = {...};
= Ope= rateOnArray(arr.data(), arr.size());
}

By all rights, this code ought to wo= rk with any type T. But it doesn't; if you stick `bool` in there, the compi= ler will fail, since `vector<bool>` doesn't have a `data` member. Bec= ause `vector<bool>` isn't a `vector` of `bool`s.

If another very similar but different class is introduced I can't see that this would make the language easier to understand or use.

=20 If bit_vector is introduced all template code that uses vector<T> and would benefit from a packed structure would need to be specialized for bool. Is that really better?

No, it's not. The only way "bit_vector" is better is that it pro= vides us a pathway whereby we can get rid of `vector<bool>`. T= hat's the only reason we want it: so that people who currently use `= vector<bool>` have a type that they can use. They can do a find-repla= ce on "vector<bool>" with "bit_vector", and their code should immedia= tely work as before. It needs to be a drop-in replacement so that they can = stop using `vector<bool>`.

That way, C++17 can deprecate the `= vector<bool>` specialization, and C++20 can remove it. Then, w= e will have what we should have had 20 years before: a real `vector` that c= an contain real `bool`s, and a type that is a space-optimized pseudo-contai= ner that has `bool`-like stuff in it. We can even add new interfaces to tha= t container, the way boost::dynamic_bitset has some useful functions on it.=

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_64_15372834.1377523320745-- .