Topic: Remove vector<bool>?
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 28 May 2013 11:50:23 -0400
Raw View
I saw Herb's paper:
http://www.gotw.ca/publications/N1185.pdf
But it's not adopted.
Anyway, vector<bool> sucks, and we know it. How about to entirely
remove it?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 28 May 2013 11:17:06 -0500
Raw View
--001a11c2793215ae6204ddc99bec
Content-Type: text/plain; charset=ISO-8859-1
On 28 May 2013 10:50, Zhihao Yuan <lichray@gmail.com> wrote:
> I saw Herb's paper:
>
> http://www.gotw.ca/publications/N1185.pdf
>
> But it's not adopted.
>
> Anyway, vector<bool> sucks, and we know it. How about to entirely
> remove it?
>
That could be a silent breaking change to potentially a lot of users; I
would be against that. Export notwithstanding, we don't just pull things
out of the standard.
If someone were to propose making it deprecated in C++17, I could be for
that.
Because this is a breaking change, I would like to see such a proposal talk
about the practical use cases for having a vector<bool> that was just
another instance of vector. What are the useful things that cannot be done
/ cannot be done efficiently now with vector<bool>.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c2793215ae6204ddc99bec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 28 May 2013 10:50, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:l=
ichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I saw Herb's paper:<br>
<br>
=A0 <a href=3D"http://www.gotw.ca/publications/N1185.pdf" target=3D"_blank"=
>http://www.gotw.ca/publications/N1185.pdf</a><br>
<br>
But it's not adopted.<br>
<br>
Anyway, vector<bool> sucks, and we know it. =A0How about to entirely<=
br>
remove it?<br></blockquote><div><br>That could be a silent breaking change =
to potentially a lot of users; I would be against that.=A0 Export notwithst=
anding, we don't just pull things out of the standard.<br><br>If someon=
e were to propose making it deprecated in C++17, I could be for that.<br>
<br>Because this is a breaking change, I would like to see such a proposal =
talk about the practical use cases for having a vector<bool> that was=
just another instance of vector.=A0 What are the useful things that cannot=
be done / cannot be done efficiently now with vector<bool>.<br clear=
=3D"all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c2793215ae6204ddc99bec--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 28 May 2013 12:32:21 -0400
Raw View
--001a11c365aa3556f804ddc9cff6
Content-Type: text/plain; charset=ISO-8859-1
On Tue, May 28, 2013 at 12:17 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
> On 28 May 2013 10:50, Zhihao Yuan <lichray@gmail.com> wrote:
>
>> I saw Herb's paper:
>>
>> http://www.gotw.ca/publications/N1185.pdf
>>
>> But it's not adopted.
>>
>> Anyway, vector<bool> sucks, and we know it. How about to entirely
>> remove it?
>>
>
> That could be a silent breaking change to potentially a lot of users; I
> would be against that. Export notwithstanding, we don't just pull things
> out of the standard.
>
> If someone were to propose making it deprecated in C++17, I could be for
> that.
>
> Because this is a breaking change, I would like to see such a proposal
> talk about the practical use cases for having a vector<bool> that was just
> another instance of vector. What are the useful things that cannot be done
> / cannot be done efficiently now with vector<bool>.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
>
Yes, the real trick is that we don't really want to remove vector<bool>, we
just want to remove its specialization. A vector<bool> that was a, well,
vector of bools, would be great, but how do we get from here to there?
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c365aa3556f804ddc9cff6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 28, 2013 at 12:17 PM, Nevin Liber <span dir=3D"ltr"><=
;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 28 May 2013 10:50, Zhih=
ao Yuan <span dir=3D"ltr"><<a href=3D"mailto:lichray@gmail.com" target=
=3D"_blank">lichray@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
I saw Herb's paper:<br>
<br>
=A0 <a href=3D"http://www.gotw.ca/publications/N1185.pdf" target=3D"_blank"=
>http://www.gotw.ca/publications/N1185.pdf</a><br>
<br>
But it's not adopted.<br>
<br>
Anyway, vector<bool> sucks, and we know it. =A0How about to entirely<=
br>
remove it?<br></blockquote></div><div><br>That could be a silent breaking c=
hange to potentially a lot of users; I would be against that.=A0 Export not=
withstanding, we don't just pull things out of the standard.<br><br>
If someone were to propose making it deprecated in C++17, I could be for th=
at.<br>
<br>Because this is a breaking change, I would like to see such a proposal =
talk about the practical use cases for having a vector<bool> that was=
just another instance of vector.=A0 What are the useful things that cannot=
be done / cannot be done efficiently now with vector<bool>.<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br clear=3D"all">
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">--=
<br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@e=
viloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a hre=
f=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(84=
7) 691-1404</a></font></span><div class=3D"HOEnZb">
<div class=3D"h5">
<p></p>
-- <br>=A0
<br></div></div></blockquote><div><br></div><div>Yes, the real trick is tha=
t we don't really want to remove vector<bool>, we just want to re=
move its specialization.=A0 A vector<bool> that was a, well, vector o=
f bools, would be great, but how do we get from here to there?<br>
<br></div><div>Tony<br>=A0<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c365aa3556f804ddc9cff6--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 28 May 2013 09:33:07 -0700 (PDT)
Raw View
------=_Part_3971_19935479.1369758787242
Content-Type: text/plain; charset=ISO-8859-1
I don't believe it could break users- as far as I'm aware, the vector<bool>
specialization offers strictly less functionality than a real vector<bool>.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_3971_19935479.1369758787242
Content-Type: text/html; charset=ISO-8859-1
I don't believe it could break users- as far as I'm aware, the vector<bool> specialization offers strictly less functionality than a real vector<bool>.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_3971_19935479.1369758787242--
.
Author: Marshall Clow <mclow.lists@gmail.com>
Date: Tue, 28 May 2013 09:37:48 -0700
Raw View
On May 28, 2013, at 9:33 AM, DeadMG <wolfeinstein@gmail.com> wrote:
> I don't believe it could break users- as far as I'm aware, the vector<bool> specialization offers strictly less functionality than a real vector<bool>.
Except, of course, for being 1/32nd of the size. ;-)
(which could be observable, for example, if you had a 1 million long vector<bool>)
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 28 May 2013 11:40:34 -0500
Raw View
--047d7b624956057af204ddc9ef74
Content-Type: text/plain; charset=ISO-8859-1
On 28 May 2013 11:33, DeadMG <wolfeinstein@gmail.com> wrote:
> I don't believe it could break users- as far as I'm aware, the
> vector<bool> specialization offers strictly less functionality than a real
> vector<bool>.
It *obviously* breaks users, given 23.3.1 "To optimize space allocation, a
specialization of vector for bool elements is provided" (not to mention the
need to support "flip()", but at least that breaking change isn't silent).
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7b624956057af204ddc9ef74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On 28 May 2013 11:33, DeadMG <span dir=3D"lt=
r"><<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeins=
tein@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't believe it could break users- as far as I'm aware, the vect=
or<bool> specialization offers strictly less functionality than a rea=
l vector<bool>.
</blockquote><div><br>It *obviously* breaks users, given 23.3.1 "To op=
timize space allocation, a specialization of vector for bool elements is pr=
ovided" (not to mention the need to support "flip()", but at=
least that breaking change isn't silent).<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b624956057af204ddc9ef74--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 28 May 2013 12:43:36 -0400
Raw View
On May 28, 2013, at 12:17 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 28 May 2013 10:50, Zhihao Yuan <lichray@gmail.com> wrote:
>> I saw Herb's paper:
>>=20
>> http://www.gotw.ca/publications/N1185.pdf
>>=20
>> But it's not adopted.
>>=20
>> Anyway, vector<bool> sucks, and we know it. How about to entirely
>> remove it?
>>=20
> That could be a silent breaking change to potentially a lot of users; I w=
ould be against that. Export notwithstanding, we don't just pull things ou=
t of the standard.
+1
>=20
> If someone were to propose making it deprecated in C++17, I could be for =
that.
>=20
> Because this is a breaking change, I would like to see such a proposal ta=
lk about the practical use cases for having a vector<bool> that was just an=
other instance of vector. What are the useful things that cannot be done /=
cannot be done efficiently now with vector<bool>.
The premise is wrong: vector<bool> doesn't suck. The functionality vector=
<bool> provides is good, and could be much improved. The data structure: d=
ynamic array of bits is a classic and valuable data structure in computer s=
cience:
http://en.wikipedia.org/wiki/Bit_array
What sucks is that we named this useful data structure vector<bool>.
I will oppose deprecating vector<bool> until we put in place something for =
clients of vector<bool> to migrate to. That something should have much the=
same API as vector<bool> to ease said migration. I.e. clients of vector<b=
ool> should have to do little more than change the name of the container.
Additionally we could add sweetener to encourage the migration. For exampl=
e we could mandate that bit_vector<Allocator> (or whatever the new name is)=
is hyper efficient when used with std::algorithms such as:
template <class InputIterator, class T>
InputIterator
find(InputIterator first, InputIterator last, const T& value);
template <class InputIterator, class T>
typename iterator_traits<InputIterator>::difference_type
count(InputIterator first, InputIterator last, const T& value);
template <class ForwardIterator, class T>
void
fill(ForwardIterator first, ForwardIterator last, const T& value);
template <class InputIterator, class OutputIterator>
OutputIterator
copy(InputIterator first, InputIterator last, OutputIterator result);
template <class ForwardIterator1, class ForwardIterator2>
ForwardIterator2
swap_ranges(ForwardIterator1 first1, ForwardIterator1 last1, ForwardIte=
rator2 first2);
template <class ForwardIterator>
ForwardIterator
rotate(ForwardIterator first, ForwardIterator middle, ForwardIterator l=
ast);
template <class InputIterator1, class InputIterator2>
bool
equal(InputIterator1 first1, InputIterator1 last1, InputIterator2 first=
2);
etc.
The potential for *portable* dramatic gains in performance are here. Let's=
not squander this opportunity. For actual performance numbers that can be=
realized, see:
http://home.roadrunner.com/~hinnant/onvectorbool.html
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 28 May 2013 19:47:28 +0300
Raw View
--001a11c2337a4df80c04ddca054f
Content-Type: text/plain; charset=ISO-8859-1
On 28 May 2013 19:43, Howard Hinnant <howard.hinnant@gmail.com> wrote:
>
> I will oppose deprecating vector<bool> until we put in place something for
> clients of vector<bool> to migrate to. That something should have much the
> same API as vector<bool> to ease said migration. I.e. clients of
> vector<bool> should have to do little more than change the name of the
> container.
>
> Additionally we could add sweetener to encourage the migration. For
> example we could mandate that bit_vector<Allocator> (or whatever the new
> name is) is hyper efficient when used with std::algorithms such as:
>
Snip. +10. Howard, as usual, has words of wisdom to offer as guidance to us
puny mortals. :)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c2337a4df80c04ddca054f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 May 2013 19:43, Howard Hinnant <span dir=3D"ltr"><<a href=
=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnant@gmail=
..com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
I will oppose deprecating vector<bool> until we put in place somethin=
g for clients of vector<bool> to migrate to. =A0That something should=
have much the same API as vector<bool> to ease said migration. =A0I.=
e. clients of vector<bool> should have to do little more than change =
the name of the container.<br>
<br>
Additionally we could add sweetener to encourage the migration. =A0For exam=
ple we could mandate that bit_vector<Allocator> (or whatever the new =
name is) is hyper efficient when used with std::algorithms such as:<br></bl=
ockquote>
<div><br></div><div>Snip. +10. Howard, as usual, has words of wisdom to off=
er as guidance to us puny mortals. :) <br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c2337a4df80c04ddca054f--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 28 May 2013 13:05:16 -0400
Raw View
On Tue, May 28, 2013 at 12:43 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> The premise is wrong: vector<bool> doesn't suck. The functionality vector<bool> provides is good, and could be much improved. The data structure: dynamic array of bits is a classic and valuable data structure in computer science:
>
> http://en.wikipedia.org/wiki/Bit_array
>
> What sucks is that we named this useful data structure vector<bool>.
Exactly.
> The potential for *portable* dramatic gains in performance are here. Let's not squander this opportunity. For actual performance numbers that can be realized, see:
>
> http://home.roadrunner.com/~hinnant/onvectorbool.html
I like this. If it's not a STL container, then it's neither named as container
nor looks like a container. Can you propose it?
However, to remove vector<bool> can happen at the same time, IMO.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 28 May 2013 13:11:48 -0400
Raw View
On Tue, May 28, 2013 at 12:40 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> It *obviously* breaks users, given 23.3.1 "To optimize space allocation, a
> specialization of vector for bool elements is provided" (not to mention the
> need to support "flip()", but at least that breaking change isn't silent).
I see. But:
1. Optimization is not mandatory, let's forget about it;
2. It's OK to backport some special interfaces, like `flip()`, which can be
SFINAEd if T is not bool.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 28 May 2013 10:32:49 -0700 (PDT)
Raw View
------=_Part_302_26895907.1369762369500
Content-Type: text/plain; charset=ISO-8859-1
There is boost::dynamic_bitset, and we could pull the usual "Just take it
from Boost" routine. In addition, a partial spec for vector<bool, alloc>
that just adds flip() would be absolutely fine.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_302_26895907.1369762369500
Content-Type: text/html; charset=ISO-8859-1
There is boost::dynamic_bitset, and we could pull the usual "Just take it from Boost" routine. In addition, a partial spec for vector<bool, alloc> that just adds flip() would be absolutely fine.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_302_26895907.1369762369500--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 28 May 2013 13:52:27 -0400
Raw View
On Tue, May 28, 2013 at 1:32 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> In addition, a partial spec for vector<bool, alloc>
> that just adds flip() would be absolutely fine.
template <typename = typename enable_if<is_same<T, bool>::value>::type>
void flip noexcept;
Same to `clear()`. Of course, a wording wants description, not
implementation.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 May 2013 13:00:05 -0700 (PDT)
Raw View
------=_Part_860_17531738.1369771205667
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 9:33:07 AM UTC-7, DeadMG wrote:
>
> I don't believe it could break users- as far as I'm aware, the
> vector<bool> specialization offers strictly less functionality than a real
> vector<bool>.
Ignoring the space optimization issue (and `flip`), there is one place
where vector<bool> has substantive differences from vector<T>:
`vector<bool>::reference` and `vector<bool>::const_reference`.
For any other type `T`, `vector<T>::const_reference` is *required* to be a
`const T&`. However, the standard requires `vector<bool>::const_reference`
to be a `bool`, not a `const bool &`.
Of greater concern is the fact that `vector<bool>::reference` is *required*to be a specific inner class of `vector<bool>`, with specific behavior like
a `flip` member function. If someone relies on being able to do this:
std::vector<bool> bvec{ ... };
bvec[2].flip();
That could be a problem. Especially since this is not an unreasonable use
of the `vector<bool>` interface as it currently stands.
Personally, I agree with Howard; we should add a class that has all of this
functionality (presumably with some degree of required sizing) that would
be a drop-in replacement for those who need the sizing features of
vector<bool>. But the question remains: even with a drop-in replacement,
how much code will be *broken* because of this?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_860_17531738.1369771205667
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 9:33:07 AM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I don't believe it could break users- as far as=
I'm aware, the vector<bool> specialization offers strictly less func=
tionality than a real vector<bool>.</blockquote><div><br>Ignoring the=
space optimization issue (and `flip`), there is one place where vector<=
bool> has substantive differences from vector<T>: `vector<bool&=
gt;::reference` and `vector<bool>::const_reference`.<br><br>For any o=
ther type `T`, `vector<T>::const_reference` is <i>required</i> to be =
a `const T&`. However, the standard requires `vector<bool>::const=
_reference` to be a `bool`, not a `const bool &`.<br><br>Of greater con=
cern is the fact that `vector<bool>::reference` is <i>required</i> to=
be a specific inner class of `vector<bool>`, with specific behavior =
like a `flip` member function. If someone relies on being able to do this:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify"><bool></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> bvec</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>bvec</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">].</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">flip</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span></div></code></di=
v><br>That could be a problem. Especially since this is not an unreasonable=
use of the `vector<bool>` interface as it currently stands.<br><br>P=
ersonally, I agree with Howard; we should add a class that has all of this =
functionality (presumably with some degree of required sizing) that would b=
e a drop-in replacement for those who need the sizing features of vector<=
;bool>. But the question remains: even with a drop-in replacement, how m=
uch code will be <i>broken</i> because of this?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_860_17531738.1369771205667--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 28 May 2013 16:12:21 -0400
Raw View
On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Personally, I agree with Howard; we should add a class that has all of th=
is functionality (presumably with some degree of required sizing) that woul=
d be a drop-in replacement for those who need the sizing features of vector=
<bool>. But the question remains: even with a drop-in replacement, how much=
code will be broken because of this?
Model this after the auto_ptr -> unique_ptr transition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool> =
specialization. /Somehow/ motivate people to migrate.
Step 2: Not to be done for at least 5-10 years after Step 1, remove the ve=
ctor<bool> specialization.
> how much code will be broken because of this?
After Step 1, none.
After Step 2, as much code as there is that:
A. Failed to migrate during the lengthy period that vector<bool> is dep=
recated, and
B. As much code that actually cares that vector<bool> was specialized.
Hopefully, little code will be broken. While I wouldn't dream of removing =
auto_ptr today, I have the impression that the auto_ptr -> unique_ptr migra=
tion is going well, thanks to the added sweetener unique_ptr has. Removing=
auto_ptr for C++17 is a possibility. If not then, then maybe C++2x.
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 28 May 2013 15:12:59 -0500
Raw View
--047d7bdc94eeac5f4604ddcce69e
Content-Type: text/plain; charset=ISO-8859-1
On 28 May 2013 15:00, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Personally, I agree with Howard; we should add a class that has all of
> this functionality (presumably with some degree of required sizing) that
> would be a drop-in replacement for those who need the sizing features of
> vector<bool>. But the question remains: even with a drop-in replacement,
> how much code will be *broken* because of this?
>
There is never any real way to know, but it's been around a long time
The problems with just pulling it are:
1. Silent changes really annoy users.
2. It makes migration harder, as you are required to change your code in a
backwards-incompatible way just to get it working under C++17.
For C++17 I think we can deprecate the vector<bool> specialization at the
same time (in favor of no specialization for the subsequent release), but I
don't see just removing it as something that has any chance of passing the
committee.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7bdc94eeac5f4604ddcce69e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 28 May 2013 15:00, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div>Personally, I agree with Howard; we should add a class that has al=
l of this functionality (presumably with some degree of required sizing) th=
at would be a drop-in replacement for those who need the sizing features of=
vector<bool>. But the question remains: even with a drop-in replacem=
ent, how much code will be <i>broken</i> because of this?<br clear=3D"all">
</div></blockquote><div><br>There is never any real way to know, but it'=
;s been around a long time<br><br>The problems with just pulling it are:<br=
><br>1.=A0 Silent changes really annoy users.<br>2.=A0 It makes migration h=
arder, as you are required to change your code in a backwards-incompatible =
way just to get it working under C++17.<br>
<br></div></div>For C++17 I think we can deprecate the vector<bool> s=
pecialization at the same time (in favor of no specialization for the subse=
quent release), but I don't see just removing it as something that has =
any chance of passing the committee.<br>
-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847=
) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bdc94eeac5f4604ddcce69e--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 28 May 2013 22:16:45 +0200
Raw View
2013/5/28 Howard Hinnant <howard.hinnant@gmail.com>:
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Personally, I agree with Howard; we should add a class that has all of t=
his functionality (presumably with some degree of required sizing) that wou=
ld be a drop-in replacement for those who need the sizing features of vecto=
r<bool>. But the question remains: even with a drop-in replacement, how muc=
h code will be broken because of this?
>
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool=
> specialization. /Somehow/ motivate people to migrate.
>
> Step 2: Not to be done for at least 5-10 years after Step 1, remove the =
vector<bool> specialization.
>
>> how much code will be broken because of this?
>
> After Step 1, none.
>
> After Step 2, as much code as there is that:
>
> A. Failed to migrate during the lengthy period that vector<bool> is d=
eprecated, and
> B. As much code that actually cares that vector<bool> was specialized=
..
>
> Hopefully, little code will be broken. While I wouldn't dream of removin=
g auto_ptr today, I have the impression that the auto_ptr -> unique_ptr mig=
ration is going well, thanks to the added sweetener unique_ptr has. Removi=
ng auto_ptr for C++17 is a possibility. If not then, then maybe C++2x.
>
I completely agree with that approach. Removing std::auto_ptr seems
realistic now (from the pov of the standard). Existing library
implementations will decide individually how long they will conserve
the definition, depending on their customers.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 28 May 2013 15:19:02 -0500
Raw View
--001a11c1e2d24ab88f04ddccfcc2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 28 May 2013 15:16, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> I completely agree with that approach. Removing std::auto_ptr seems
> realistic now (from the pov of the standard). Existing library
> implementations will decide individually how long they will conserve
> the definition, depending on their customers.
>
Note: vector<bool> is different in one regard, as (I assume) we are
proposing a change in behavior and not just removal of a deprecated library=
..
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--001a11c1e2d24ab88f04ddccfcc2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 28 May 2013 15:16, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=3D"mai=
lto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com<=
/a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
I completely agree with that approach. Removing std::auto_ptr seems<br>
realistic now (from the pov of the standard). Existing library<br>
implementations will decide individually how long they will conserve<br>
the definition, depending on their customers.<br></blockquote><div><br>Note=
:=A0 vector<bool> is different in one regard, as (I assume) we are pr=
oposing a change in behavior and not just removal of a deprecated library.<=
br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c1e2d24ab88f04ddccfcc2--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 28 May 2013 16:28:06 -0400
Raw View
On Tue, May 28, 2013 at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> std::vector<bool> bvec{ ... };
> bvec[2].flip();
I noticed that. It's OK to be fixed within `vector<T>`.
> Personally, I agree with Howard; we should add a class that has all of this
> functionality (presumably with some degree of required sizing) that would be
> a drop-in replacement for those who need the sizing features of
> vector<bool>. But the question remains: even with a drop-in replacement, how
> much code will be broken because of this?
I like the idea of providing a replacement, but I don't think a 'drop-in
replacement' is a requirement. `vector<bool>` still works, and users
can rewrite their code if they want.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 28 May 2013 18:29:24 -0400
Raw View
--14dae9473ae321f93304ddcecc53
Content-Type: text/plain; charset=ISO-8859-1
On Tue, May 28, 2013 at 4:12 PM, Howard Hinnant <howard.hinnant@gmail.com>wrote:
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> > Personally, I agree with Howard; we should add a class that has all of
> this functionality (presumably with some degree of required sizing) that
> would be a drop-in replacement for those who need the sizing features of
> vector<bool>. But the question remains: even with a drop-in replacement,
> how much code will be broken because of this?
>
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool>
> specialization. /Somehow/ motivate people to migrate.
>
> Step 2: Not to be done for at least 5-10 years after Step 1, remove the
> vector<bool> specialization.
>
> > how much code will be broken because of this?
>
> After Step 1, none.
>
> After Step 2, as much code as there is that:
>
> A. Failed to migrate during the lengthy period that vector<bool> is
> deprecated, and
> B. As much code that actually cares that vector<bool> was specialized.
>
> Hopefully, little code will be broken. While I wouldn't dream of removing
> auto_ptr today, I have the impression that the auto_ptr -> unique_ptr
> migration is going well, thanks to the added sweetener unique_ptr has.
> Removing auto_ptr for C++17 is a possibility. If not then, then maybe
> C++2x.
>
> Howard
>
>
I think (and maybe this was implied) we should also NOT add flip() to the
otherwise-non-specialized future vector<bool>. ie we give users bit_vector
with flip(), and do NOT try to help keep their current uses of vector<bool>
compiling. It would be better for their code to stop compiling until they
switch to bit_vector.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--14dae9473ae321f93304ddcecc53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 28, 2013 at 4:12 PM, Howard Hinnant <span dir=3D"ltr">&=
lt;<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hin=
nant@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On May 28, 2013, at 4:00 P=
M, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.c=
om</a>> wrote:<br>
<br>
> Personally, I agree with Howard; we should add a class that has all of=
this functionality (presumably with some degree of required sizing) that w=
ould be a drop-in replacement for those who need the sizing features of vec=
tor<bool>. But the question remains: even with a drop-in replacement,=
how much code will be broken because of this?<br>
<br>
</div>Model this after the auto_ptr -> unique_ptr transition:<br>
<br>
Step 1: =A0Introduce bit_vector (or whatever) and deprecate the vector<b=
ool> specialization. =A0/Somehow/ motivate people to migrate.<br>
<br>
Step 2: =A0Not to be done for at least 5-10 years after Step 1, remove the =
vector<bool> specialization.<br>
<div class=3D"im"><br>
> how much code will be broken because of this?<br>
<br>
</div>After Step 1, none.<br>
<br>
After Step 2, as much code as there is that:<br>
<br>
=A0 =A0A. =A0Failed to migrate during the lengthy period that vector<boo=
l> is deprecated, and<br>
=A0 =A0B. =A0As much code that actually cares that vector<bool> was s=
pecialized.<br>
<br>
Hopefully, little code will be broken. =A0While I wouldn't dream of rem=
oving auto_ptr today, I have the impression that the auto_ptr -> unique_=
ptr migration is going well, thanks to the added sweetener unique_ptr has. =
=A0Removing auto_ptr for C++17 is a possibility. =A0If not then, then maybe=
C++2x.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Howard<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blo=
ckquote><div><br><br></div><div>I think (and maybe this was implied) we sho=
uld also NOT add flip() to the otherwise-non-specialized future vector<b=
ool>.=A0 ie we give users bit_vector with flip(), and do NOT try to help=
keep their current uses of vector<bool> compiling.=A0 It would be be=
tter for their code to stop compiling until they switch to bit_vector.<br>
<br></div><div>Tony<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9473ae321f93304ddcecc53--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 May 2013 15:31:06 -0700 (PDT)
Raw View
------=_Part_4216_19179901.1369780266502
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 1:12:59 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 28 May 2013 15:00, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> Personally, I agree with Howard; we should add a class that has all of
>> this functionality (presumably with some degree of required sizing) that
>> would be a drop-in replacement for those who need the sizing features of
>> vector<bool>. But the question remains: even with a drop-in replacement,
>> how much code will be *broken* because of this?
>>
>
> There is never any real way to know, but it's been around a long time
>
> The problems with just pulling it are:
>
> 1. Silent changes really annoy users.
> 2. It makes migration harder, as you are required to change your code in
> a backwards-incompatible way just to get it working under C++17.
>
> For C++17 I think we can deprecate the vector<bool> specialization at the
> same time (in favor of no specialization for the subsequent release), but I
> don't see just removing it as something that has any chance of passing the
> committee.
This isn't like the auto_ptr->unique_ptr thing; there, the idea there was
to get people using a new class with a new interface and new behavior (as
an aside, I see no point in removing auto_ptr; it does no harm sitting
there, since everyone already knows to use unique_ptr where available).
The point of this exercise is not to get a class that does exactly what
`vector<bool>` does. The point of this exercise is to be able to actually
create a real, legitimate `vector` that contains actual `bool`s. Getting
users of `vector<bool>` to use a new class is merely the *means* to that
end.
So a plan that could, *maybe* get us back `vector<bool>` around 2020 isn't
particularly useful. I would much rather find a plan that gets us back
`vector<bool>` in fewer than 3 standard revisions.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_4216_19179901.1369780266502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, May 28, 2013 1:12:59 PM UTC-7, Nevin ":-)" Liber wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 28 May 2013 15:00, Nicol Bo=
las <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"mVXkqKDqWWoJ">jmck...@gmail.com</a>></span> wrote:<br>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div>Personally, I agree with Howard; we should add a class that has al=
l of this functionality (presumably with some degree of required sizing) th=
at would be a drop-in replacement for those who need the sizing features of=
vector<bool>. But the question remains: even with a drop-in replacem=
ent, how much code will be <i>broken</i> because of this?<br clear=3D"all">
</div></blockquote><div><br>There is never any real way to know, but it's b=
een around a long time<br><br>The problems with just pulling it are:<br><br=
>1. Silent changes really annoy users.<br>2. It makes migration=
harder, as you are required to change your code in a backwards-incompatibl=
e way just to get it working under C++17.<br>
<br></div></div>For C++17 I think we can deprecate the vector<bool> s=
pecialization at the same time (in favor of no specialization for the subse=
quent release), but I don't see just removing it as something that has any =
chance of passing the committee.</blockquote><div><br>This isn't like the a=
uto_ptr->unique_ptr thing; there, the idea there
was to get people using a new class with a new interface and new=20
behavior (as an aside, I see no point in removing auto_ptr; it does no harm=
sitting there, since everyone already knows to use unique_ptr where availa=
ble).<br><br>The point of this exercise is not to get a class that does exa=
ctly what `vector<bool>` does. The point of this exercise is to be ab=
le to actually create a real, legitimate `vector` that contains actual `boo=
l`s. Getting users of `vector<bool>` to use a new class is merely the=
<i>means</i> to that end.<br><br>So a plan that could, <i>maybe</i> get us=
back `vector<bool>` around 2020 isn't particularly useful. I would m=
uch rather find a plan that gets us back `vector<bool>` in fewer than=
3 standard revisions.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4216_19179901.1369780266502--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 May 2013 15:32:57 -0700 (PDT)
Raw View
------=_Part_3797_8794.1369780377766
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 1:28:06 PM UTC-7, Zhihao Yuan wrote:
>
> On Tue, May 28, 2013 at 4:00 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > std::vector<bool> bvec{ ... };
> > bvec[2].flip();
>
> I noticed that. It's OK to be fixed within `vector<T>`.
>
> > Personally, I agree with Howard; we should add a class that has all of
> this
> > functionality (presumably with some degree of required sizing) that
> would be
> > a drop-in replacement for those who need the sizing features of
> > vector<bool>. But the question remains: even with a drop-in replacement,
> how
> > much code will be broken because of this?
>
> I like the idea of providing a replacement, but I don't think a 'drop-in
> replacement' is a requirement. `vector<bool>` still works, and users
> can rewrite their code if they want.
>
When breaking people's code, it is generally advisable to minimize the
disruption. And it'd be a lot easier to get through the committee if you
can show them that the breaking changes will be noisy *and* that the
changes can be easily repaired.
A drop-in replacement would cover the latter.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_3797_8794.1369780377766
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 1:28:06 PM UTC-7, Zhihao Yuan wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">On Tue, May 28, 2013 at 4:00 PM, Nicol Bolas=
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"stP=
5-UdPG4IJ">jmck...@gmail.com</a>> wrote:
<br>> std::vector<bool> bvec{ ... };
<br>> bvec[2].flip();
<br>
<br>I noticed that. It's OK to be fixed within `vector<T>`.
<br>
<br>> Personally, I agree with Howard; we should add a class that has al=
l of this
<br>> functionality (presumably with some degree of required sizing) tha=
t would be
<br>> a drop-in replacement for those who need the sizing features of
<br>> vector<bool>. But the question remains: even with a drop-in =
replacement, how
<br>> much code will be broken because of this?
<br>
<br>I like the idea of providing a replacement, but I don't think a 'drop-i=
n
<br>replacement' is a requirement. `vector<bool>` still works, =
and users
<br>can rewrite their code if they want.
<br></blockquote><div><br>When breaking people's code, it is generally advi=
sable to minimize the disruption. And it'd be a lot easier to get through t=
he committee if you can show them that the breaking changes will be noisy <=
i>and</i> that the changes can be easily repaired.<br><br>A drop-in replace=
ment would cover the latter.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3797_8794.1369780377766--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 28 May 2013 15:43:53 -0700
Raw View
On Tuesday, May 28, 2013 1:28:06 PM UTC-7, Zhihao Yuan wrote:
> I like the idea of providing a replacement, but I don't think a
> 'drop-in replacement' is a requirement. `vector<bool>` still
> works, and users can rewrite their code if they want.
It is sometimes difficult to rewrite code. First, the code base
may be very large. Source code bases in excess of 20 million lines
are common. Expect much code bases to exist. Second, sometimes
that code is part of binary libraries. To get a change you need
to go back to the library vendor, request the change, hope they
have time to deal with your legacy platform, and you get the idea.
Third, the author of the code may be long gone. So, a rewrite would
require a programmer to understand the subtleties of that particular
use, which takes time. Now multiply by the code base size.
On 5/28/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> When breaking people's code, it is generally advisable to minimize
> the disruption. And it'd be a lot easier to get through the
> committee if you can show them that the breaking changes will be
> noisy *and* that the changes can be easily repaired.
>
> A drop-in replacement would cover the latter.
Agreed. A breaking change should have a migration plan.
For C++11, I argued that we could drop support for the old use of
the auto keyword because we had a simple migration plan.
= Remove all uses of the auto keyword in the code base.
= You now have a program that is both C++98 and C++11 conformant.
= Add the new use of auto when desired.
It certainly helped the argument that two thirds of the uses of auto
I found on code.google.com were in compiler conformance test suites.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: cornedbee@google.com
Date: Wed, 29 May 2013 03:16:57 -0700 (PDT)
Raw View
------=_Part_4771_13115204.1369822617243
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 6:43:36 PM UTC+2, Howard Hinnant wrote:
>
>
> I will oppose deprecating vector<bool> until we put in place something for
> clients of vector<bool> to migrate to. That something should have much the
> same API as vector<bool> to ease said migration. I.e. clients of
> vector<bool> should have to do little more than change the name of the
> container.
>
> Additionally we could add sweetener to encourage the migration. For
> example we could mandate that bit_vector<Allocator> (or whatever the new
> name is) is hyper efficient when used with std::algorithms such as:
>
>
And we should add an interface that allows 3rd-party or user-defined
algorithms to exploit the packed representation of bit_vector. It's all
nice for standard algorithms to be optimized for vector<bool>, but as a
user of the library, I can't optimize my own algorithms without reaching
into the implementation details, such as __bit_reference. So not only would
I have to optimize my algorithm for packed bits, I'd have to do it for many
different standard libraries.
Sebastian
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_4771_13115204.1369822617243
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, May 28, 2013 6:43:36 PM UTC+2, Howard Hinnant wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br>I will oppose deprecating vec=
tor<bool> until we put in place something for clients of vector<bo=
ol> to migrate to. That something should have much the same API as=
vector<bool> to ease said migration. I.e. clients of vector<=
;bool> should have to do little more than change the name of the contain=
er.
<br>
<br>Additionally we could add sweetener to encourage the migration. F=
or example we could mandate that bit_vector<Allocator> (or whatever t=
he new name is) is hyper efficient when used with std::algorithms such as:
<br><br></blockquote><div><br></div><div>And we should add an interface tha=
t allows 3rd-party or user-defined algorithms to exploit the packed represe=
ntation of bit_vector. It's all nice for standard algorithms to be optimize=
d for vector<bool>, but as a user of the library, I can't optimize my=
own algorithms without reaching into the implementation details, such as _=
_bit_reference. So not only would I have to optimize my algorithm for packe=
d bits, I'd have to do it for many different standard libraries.</div><div>=
<br></div><div>Sebastian </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4771_13115204.1369822617243--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Wed, 29 May 2013 10:32:27 -0400
Raw View
On May 29, 2013, at 6:16 AM, cornedbee@google.com wrote:
>=20
>=20
> On Tuesday, May 28, 2013 6:43:36 PM UTC+2, Howard Hinnant wrote:
>=20
>> I will oppose deprecating vector<bool> until we put in place something f=
or clients of vector<bool> to migrate to. That something should have much =
the same API as vector<bool> to ease said migration. I.e. clients of vecto=
r<bool> should have to do little more than change the name of the container=
..=20
>>=20
>> Additionally we could add sweetener to encourage the migration. For exa=
mple we could mandate that bit_vector<Allocator> (or whatever the new name =
is) is hyper efficient when used with std::algorithms such as:=20
>>=20
>=20
> And we should add an interface that allows 3rd-party or user-defined algo=
rithms to exploit the packed representation of bit_vector. It's all nice fo=
r standard algorithms to be optimized for vector<bool>, but as a user of th=
e library, I can't optimize my own algorithms without reaching into the imp=
lementation details, such as __bit_reference. So not only would I have to o=
ptimize my algorithm for packed bits, I'd have to do it for many different =
standard libraries.
I like this direction. And standardizing count-lead/trailing-zero-bits and=
population-count algorithms would help in this department too.
http://en.wikipedia.org/wiki/Count_leading_zeros#Hardware_support
http://en.wikipedia.org/wiki/Hamming_weight#Processor_support
C started out as a "portable assembly", but except for the recent atomic ad=
ditions, hasn't kept up with additions to the popular set of machine instru=
ctions. Instead non-portable compiler intrinsics have risen to fill the ga=
p. C++ should give us portable access to those compiler intrinsics.
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Wed, 29 May 2013 09:41:43 -0500
Raw View
Howard Hinnant <howard.hinnant@gmail.com> writes:
[...]
| C++ should give us portable access to those compiler intrinsics.
+1.
Brownie points if you make them constexpr (as appropriate).
-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 29 May 2013 19:20:15 +0200
Raw View
This is a multi-part message in MIME format.
--------------080303080600050001080508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 28/05/13 22:12, Howard Hinnant a =E9crit :
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Personally, I agree with Howard; we should add a class that has all of t=
his functionality (presumably with some degree of required sizing) that wou=
ld be a drop-in replacement for those who need the sizing features of vecto=
r<bool>. But the question remains: even with a drop-in replacement, how muc=
h code will be broken because of this?
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool=
> specialization. /Somehow/ motivate people to migrate.
I think that we will need also to add a std::*new_*vector<T> that=20
behaves like std::vector<T> but doesn't have the bool specialization and=20
*deprecate* std::vector :->
The name of the class and the namespace could have their importance.=20
Maybe if we had a multi-vector that was as efficient as a vector the=20
name could be multi_vector<T>. Just an idea.
>
> Step 2: Not to be done for at least 5-10 years after Step 1, remove the =
vector<bool> specialization.
Remove the std::vector<T> from the standard.
>> how much code will be broken because of this?
> After Step 1, none.
>
> After Step 2, as much code as there is that:
>
> A. Failed to migrate during the lengthy period that vector<bool> is =
deprecated, and
> B. As much code that actually cares that vector<bool> was specialize=
d.
Maybe a lot of, but, not silently.
> Hopefully, little code will be broken. While I wouldn't dream of removin=
g auto_ptr today, I have the impression that the auto_ptr -> unique_ptr mig=
ration is going well, thanks to the added sweetener unique_ptr has. Removi=
ng auto_ptr for C++17 is a possibility. If not then, then maybe C++2x.
>
> Howard
>
Yes, this could seem heretical, but this is the only path I see that=20
could allow a smooth migration and a non silent drop of the unwanted=20
std::vector<bool>.
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--------------080303080600050001080508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 28/05/13 22:12, Howard Hinnant a
écrit :<br>
</div>
<blockquote
cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
type=3D"cite">
<pre wrap=3D"">On May 28, 2013, at 4:00 PM, Nicol Bolas <a class=3D"m=
oz-txt-link-rfc2396E" href=3D"mailto:jmckesson@gmail.com"><jmckesson@gma=
il.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Personally, I agree with Howard; we should add a cla=
ss that has all of this functionality (presumably with some degree of requi=
red sizing) that would be a drop-in replacement for those who need the sizi=
ng features of vector<bool>. But the question remains: even with a dr=
op-in replacement, how much code will be broken because of this?
</pre>
</blockquote>
<pre wrap=3D"">
Model this after the auto_ptr -> unique_ptr transition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote>
I think that we will need also to add a std::<b>new_</b>vector<T>
that behaves like std::vector<T> but doesn't have the bool
specialization and <b>deprecate</b> std::vector :-><br>
The name of the class and the namespace could have their importance.
Maybe if we had a multi-vector that was as efficient as a vector
the name could be multi_vector<T>. Just an idea. <br>
<blockquote
cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
type=3D"cite">
<pre wrap=3D"">
Step 2: Not to be done for at least 5-10 years after Step 1, remove the ve=
ctor<bool> specialization.
</pre>
</blockquote>
Remove the std::vector<T> from the standard.<br>
<blockquote
cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">how much code will be broken because of this?
</pre>
</blockquote>
<pre wrap=3D"">
After Step 1, none.
After Step 2, as much code as there is that:
A. Failed to migrate during the lengthy period that vector<bool> =
is deprecated, and
B. As much code that actually cares that vector<bool> was special=
ized.
</pre>
</blockquote>
Maybe a lot of, but, not silently.<br>
<blockquote
cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
type=3D"cite">
<pre wrap=3D"">
Hopefully, little code will be broken. While I wouldn't dream of removing =
auto_ptr today, I have the impression that the auto_ptr -> unique_ptr mi=
gration is going well, thanks to the added sweetener unique_ptr has. Remov=
ing auto_ptr for C++17 is a possibility. If not then, then maybe C++2x.
Howard
</pre>
</blockquote>
Yes, this could seem heretical, but this is the only path I see that
could allow a smooth migration and a non silent drop of the unwanted
std::vector<bool>.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------080303080600050001080508--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 12:37:19 -0500
Raw View
--14dae9d70f8cc1401504ddded7fb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 12:20, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>wr=
ote:
> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
>
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> <jmckesson=
@gmail.com> wrote:
>
>
> Personally, I agree with Howard; we should add a class that has all of t=
his functionality (presumably with some degree of required sizing) that wou=
ld be a drop-in replacement for those who need the sizing features of vecto=
r<bool>. But the question remains: even with a drop-in replacement, how muc=
h code will be broken because of this?
>
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool=
> specialization. /Somehow/ motivate people to migrate.
>
> I think that we will need also to add a std::*new_*vector<T> that
> behaves like std::vector<T> but doesn't have the bool specialization and =
*
> deprecate* std::vector :->
>
-100.
* Annoying 99% of all C++ users is a horrible, horrible idea.
* I'd hate to use a code base that had two different, unrelated types for
doing the exact same thing, since ultimately these things end up
interfaces. Actually, I already have that, as people are trying to migrate
from Boost over to std (such as shared_ptr), and it is anything but easy
(because we are dependent on libraries developed for/by other groups, and
changing those interfaces is a scheduling nightmare).
I like Howard's plan, as we not only don't leave current users of
vector<bool> out in the cold but we give them incentive to move, as well as
"fixing up" vector (although I'd still like to see some actual use cases
for the non-specialized vector<bool>).
The part I disagree with is the timeframe; we only have to wait one
standard cycle of having the current vector<bool> deprecated before
removing the specialization. The only promise we make to users about
deprecated features is in n3690 Dp2: "These are deprecated features, where
deprecated is defined as: Normative for the current edition of the
Standard, but having been identified as a candidate for removal from future
revisions." Of course, getting the Committee to actually remove deprecated
libraries is a whole different issue...
(And auto_ptr needs to go, even if library vendors decide to keep it around
forever, because it appears in other interfaces in the Standard.)
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--14dae9d70f8cc1401504ddded7fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 12:20, Vicente J. Botet Escriba <span dir=3D"ltr"><<a hre=
f=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanad=
oo.fr</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/05/13 22:12, Howard Hinnant a
=E9crit=A0:<br>
</div><div class=3D"im">
<blockquote type=3D"cite">
<pre>On May 28, 2013, at 4:00 PM, Nicol Bolas <a href=3D"mailto:jmcke=
sson@gmail.com" target=3D"_blank"><jmckesson@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>Personally, I agree with Howard; we should add a class that ha=
s all of this functionality (presumably with some degree of required sizing=
) that would be a drop-in replacement for those who need the sizing feature=
s of vector<bool>. But the question remains: even with a drop-in repl=
acement, how much code will be broken because of this?
</pre>
</blockquote>
<pre>Model this after the auto_ptr -> unique_ptr transition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote></div>
I think that we will need also to add a std::<b>new_</b>vector<T>
that behaves like std::vector<T> but doesn't have the bool
specialization and <b>deprecate</b> std::vector :-><br></div></block=
quote><div><br>-100.<br><br>* Annoying 99% of all C++ users is a horrible, =
horrible idea.<br><br>* I'd hate to use a code base that had two differ=
ent, unrelated types for doing the exact same thing, since ultimately these=
things end up interfaces.=A0 Actually, I already have that, as people are =
trying to migrate from Boost over to std (such as shared_ptr), and it is an=
ything but easy (because we are dependent on libraries developed for/by oth=
er groups, and changing those interfaces is a scheduling nightmare).<br>
<br>I like Howard's plan, as we not only don't leave current users =
of vector<bool> out in the cold but we give them incentive to move, a=
s well as "fixing up" vector (although I'd still like to see =
some actual use cases for the non-specialized vector<bool>).<br>
<br>The part I disagree with is the timeframe; we only have to wait one sta=
ndard cycle of having the current vector<bool> deprecated before remo=
ving the specialization.=A0 The only promise we make to users about depreca=
ted features is in n3690 Dp2: "These are deprecated features, where de=
precated is defined as: Normative for the current edition of the Standard, =
but having been identified as a candidate for removal from future revisions=
.."=A0 Of course, getting the Committee to actually remove deprecated l=
ibraries is a whole different issue...<br>
<br>(And auto_ptr needs to go, even if library vendors decide to keep it ar=
ound forever, because it appears in other interfaces in the Standard.)<br c=
lear=3D"all"></div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae9d70f8cc1401504ddded7fb--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 29 May 2013 10:42:57 -0700 (PDT)
Raw View
------=_Part_4630_25315416.1369849377363
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 8:50:23 AM UTC-7, Zhihao Yuan wrote:
>
> I saw Herb's paper:
>
> http://www.gotw.ca/publications/N1185.pdf
>
> But it's not adopted.
>
> Anyway, vector<bool> sucks, and we know it. How about to entirely
> remove it?
>
I think I may have a solution to this problem. The goal is to have a
`vector` class that contains actual `bool`s, right? Well, who says that it
actually *needs* to be called "vector<bool>"?
We simply add another specialization to `vector` called
"vector<std::real_bool, Allocator>". If you create a `vector` with the
`std::real_bool` type, then you get exactly what you would have gotten if
`vector<bool>` weren't a specialization: an actual `vector` that contains
actual `bool`s. The `value_type` of `vector<std::real_bool>` would be
`bool`, and so forth.
We don't have to get rid of `vector<bool>` to get what we want. We just
have to call it something else. And since this `std::real_bool` type can't
be used in existing code (defining new things in the `std` namespace is
undefined behavior), it can't conflict with anything now.
The downside is that a template function that takes a `vector<T>`, where
`T` is some type, may assume that `T` is the `value_type` of the `vector`,
which it would not be in the case of `std::real_bool`.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_4630_25315416.1369849377363
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 8:50:23 AM UTC-7, Zhihao Yuan wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">I saw Herb's paper:
<br>
<br> <a href=3D"http://www.gotw.ca/publications/N1185.pdf" target=3D"=
_blank">http://www.gotw.ca/<wbr>publications/N1185.pdf</a>
<br>
<br>But it's not adopted.
<br>
<br>Anyway, vector<bool> sucks, and we know it. How about to en=
tirely
<br>remove it?
<br></blockquote><div><br>I think I may have a solution to this problem. Th=
e goal is to have a `vector` class that contains actual `bool`s, right? Wel=
l, who says that it actually <i>needs</i> to be called "vector<bool>"=
?<br><br>We simply add another specialization to `vector` called "vector<=
;std::real_bool, Allocator>". If you create a `vector` with the `std::re=
al_bool` type, then you get exactly what you would have gotten if `vector&l=
t;bool>` weren't a specialization: an actual `vector` that contains actu=
al `bool`s. The `value_type` of `vector<std::real_bool>` would be `bo=
ol`, and so forth.<br><br>We don't have to get rid of `vector<bool>` =
to get what we want. We just have to call it something else. And since this=
`std::real_bool` type can't be used in existing code (defining new things =
in the `std` namespace is undefined behavior), it can't conflict with anyth=
ing now.<br><br>The downside is that a template function that takes a `vect=
or<T>`, where `T` is some type, may assume that `T` is the `value_typ=
e` of the `vector`, which it would not be in the case of `std::real_bool`.<=
br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4630_25315416.1369849377363--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 29 May 2013 10:44:47 -0700 (PDT)
Raw View
------=_Part_4655_16229991.1369849487788
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, May 29, 2013 10:20:15 AM UTC-7, Vicente J. Botet Escriba=20
wrote:
>
> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
> =20
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmck...@gmail.com> <javascript:=
> wrote:
>
>
> Personally, I agree with Howard; we should add a class that has all of t=
his functionality (presumably with some degree of required sizing) that wou=
ld be a drop-in replacement for those who need the sizing features of vecto=
r<bool>. But the question remains: even with a drop-in replacement, how muc=
h code will be broken because of this?
>
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<bool=
> specialization. /Somehow/ motivate people to migrate.
>
> I think that we will need also to add a std::*new_*vector<T> that=20
> behaves like std::vector<T> but doesn't have the bool specialization and =
*
> deprecate* std::vector :->
>
So your solution to this significant-yet-relatively-minor-problem... is to=
=20
rip out the entire class?
I'm going to go with "no" on that.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
------=_Part_4655_16229991.1369849487788
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, May 29, 2013 10:20:15 AM UTC-7, Vicente J. Botet Escr=
iba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/05/13 22:12, Howard Hinnant a
=E9crit :<br>
</div>
<blockquote type=3D"cite">
<pre>On May 28, 2013, at 4:00 PM, Nicol Bolas <a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"Zt-gPy6b1mMJ"><jmck...@gmail=
..com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>Personally, I agree with Howard; we should add a class that ha=
s all of this functionality (presumably with some degree of required sizing=
) that would be a drop-in replacement for those who need the sizing feature=
s of vector<bool>. But the question remains: even with a drop-in repl=
acement, how much code will be broken because of this?
</pre>
</blockquote>
<pre>Model this after the auto_ptr -> unique_ptr transition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote>
I think that we will need also to add a std::<b>new_</b>vector<T>
that behaves like std::vector<T> but doesn't have the bool
specialization and <b>deprecate</b> std::vector :-><br></div></block=
quote><div><br>So your solution to this significant-yet-relatively-minor-pr=
oblem... is to rip out the entire class?<br><br>I'm going to go with "no" o=
n that.</div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4655_16229991.1369849487788--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 12:51:42 -0500
Raw View
--001a11c2b55c343cfb04dddf0be8
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 12:42, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> http://www.gotw.ca/publications/N1185.pdf
>>
>> But it's not adopted.
>>
>> Anyway, vector<bool> sucks, and we know it. How about to entirely
>> remove it?
>>
>
>
>
> We simply add another specialization to `vector` called
> "vector<std::real_bool, Allocator>". If you create a `vector` with the
> `std::real_bool` type, then you get exactly what you would have gotten if
> `vector<bool>` weren't a specialization: an actual `vector` that contains
> actual `bool`s. The `value_type` of `vector<std::real_bool>` would be
> `bool`, and so forth.
>
> We don't have to get rid of `vector<bool>` to get what we want. We just
> have to call it something else. And since this `std::real_bool` type can't
> be used in existing code (defining new things in the `std` namespace is
> undefined behavior), it can't conflict with anything now.
>
> The downside is that a template function that takes a `vector<T>`, where
> `T` is some type, may assume that `T` is the `value_type` of the `vector`,
> which it would not be in the case of `std::real_bool`.
>
-1.
The primary argument (so far) for removing the vector<bool> specialization
is uniformity with the rest of vector. As you point out, your solution
still doesn't achieve it.
While the standard strives for high levels of backwards compatibility, it
need not be 100% (heck, C++11 vector is not 100% backwards compatible with
C++03 vector), and we shouldn't be adding more warts. The standard is the
right place to fix this, and we should fix it and not just put a band aid
on it.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c2b55c343cfb04dddf0be8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 12:42, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">=A0 <a href=
=3D"http://www.gotw.ca/publications/N1185.pdf" target=3D"_blank">http://www=
..gotw.ca/publications/N1185.pdf</a>
<br>
<br>But it's not adopted.
<br>
<br>Anyway, vector<bool> sucks, and we know it. =A0How about to entir=
ely
<br>remove it?
<br></blockquote></div><div><br><br><br>We simply add another specializatio=
n to `vector` called "vector<std::real_bool, Allocator>". I=
f you create a `vector` with the `std::real_bool` type, then you get exactl=
y what you would have gotten if `vector<bool>` weren't a speciali=
zation: an actual `vector` that contains actual `bool`s. The `value_type` o=
f `vector<std::real_bool>` would be `bool`, and so forth.<br>
<br>We don't have to get rid of `vector<bool>` to get what we wan=
t. We just have to call it something else. And since this `std::real_bool` =
type can't be used in existing code (defining new things in the `std` n=
amespace is undefined behavior), it can't conflict with anything now.<b=
r>
<br>The downside is that a template function that takes a `vector<T>`=
, where `T` is some type, may assume that `T` is the `value_type` of the `v=
ector`, which it would not be in the case of `std::real_bool`.<br></div>
</blockquote><div><br>-1.<br><br>The primary argument (so far) for removing=
the vector<bool> specialization is uniformity with the rest of vecto=
r.=A0 As you point out, your solution still doesn't achieve it.<br><br>
While the standard strives for high levels of backwards compatibility, it n=
eed not be 100% (heck, C++11 vector is not 100% backwards compatible with C=
++03 vector), and we shouldn't be adding more warts.=A0 The standard is=
the right place to fix this, and we should fix it and not just put a band =
aid on it.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c2b55c343cfb04dddf0be8--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 29 May 2013 12:20:17 -0700
Raw View
On 5/29/13, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> Howard Hinnant <howard.hinnant@gmail.com> writes:
>
> [...]
> | C++ should give us portable access to those compiler intrinsics.
>
> +1.
> Brownie points if you make them constexpr (as appropriate).
Some discussion has happened in SG6, but not enough.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 29 May 2013 12:21:25 -0700 (PDT)
Raw View
------=_Part_1954_14671050.1369855285276
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, May 29, 2013 10:51:42 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 29 May 2013 12:42, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> http://www.gotw.ca/publications/N1185.pdf
>>>
>>> But it's not adopted.
>>>
>>> Anyway, vector<bool> sucks, and we know it. How about to entirely
>>> remove it?
>>>
>>
>>
>>
>> We simply add another specialization to `vector` called
>> "vector<std::real_bool, Allocator>". If you create a `vector` with the
>> `std::real_bool` type, then you get exactly what you would have gotten if
>> `vector<bool>` weren't a specialization: an actual `vector` that contains
>> actual `bool`s. The `value_type` of `vector<std::real_bool>` would be
>> `bool`, and so forth.
>>
>> We don't have to get rid of `vector<bool>` to get what we want. We just
>> have to call it something else. And since this `std::real_bool` type can't
>> be used in existing code (defining new things in the `std` namespace is
>> undefined behavior), it can't conflict with anything now.
>>
>> The downside is that a template function that takes a `vector<T>`, where
>> `T` is some type, may assume that `T` is the `value_type` of the `vector`,
>> which it would not be in the case of `std::real_bool`.
>>
>
> -1.
>
> The primary argument (so far) for removing the vector<bool> specialization
> is uniformity with the rest of vector.
>
I thought the primary argument was to be able to create a `vector` of
`bool`s. I don't care about "uniformity"; what I care about is making a
`vector` that actually contains `bool`s.
As you point out, your solution still doesn't achieve it.
>
> While the standard strives for high levels of backwards compatibility, it
> need not be 100% (heck, C++11 vector is not 100% backwards compatible with
> C++03 vector), and we shouldn't be adding more warts. The standard is the
> right place to fix this, and we should fix it and not just put a band aid
> on it.
>
And how long will that take? C++14 is closed for new stuff, and the whole
"deprecation/removal" process will require at least 2 revisions. So it
would be C++20 *at least* before we can finally create a real `vector` of
real `bool`s.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
------=_Part_1954_14671050.1369855285276
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, May 29, 2013 10:51:42 AM UTC-7, Nevin ":-)" Liber wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 29 May 2013 12:42, Nicol Bolas <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"kVPNKppxaKIJ">jmck...@gmail.com</a>></span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"http://w=
ww.gotw.ca/publications/N1185.pdf" target=3D"_blank">http://www.gotw.ca/<wb=
r>publications/N1185.pdf</a>
<br>
<br>But it's not adopted.
<br>
<br>Anyway, vector<bool> sucks, and we know it. How about to en=
tirely
<br>remove it?
<br></blockquote></div><div><br><br><br>We simply add another specializatio=
n to `vector` called "vector<std::real_bool, Allocator>". If you crea=
te a `vector` with the `std::real_bool` type, then you get exactly what you=
would have gotten if `vector<bool>` weren't a specialization: an act=
ual `vector` that contains actual `bool`s. The `value_type` of `vector<s=
td::real_bool>` would be `bool`, and so forth.<br>
<br>We don't have to get rid of `vector<bool>` to get what we want. W=
e just have to call it something else. And since this `std::real_bool` type=
can't be used in existing code (defining new things in the `std` namespace=
is undefined behavior), it can't conflict with anything now.<br>
<br>The downside is that a template function that takes a `vector<T>`=
, where `T` is some type, may assume that `T` is the `value_type` of the `v=
ector`, which it would not be in the case of `std::real_bool`.<br></div>
</blockquote><div><br>-1.<br><br>The primary argument (so far) for removing=
the vector<bool> specialization is uniformity with the rest of vecto=
r.</div></div></blockquote><div><br>I thought the primary argument was to b=
e able to create a `vector` of `bool`s. I don't care about "uniformity"; wh=
at I care about is making a `vector` that actually contains `bool`s.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quo=
te"><div>As you point out, your solution still doesn't achieve it.<br><br>
While the standard strives for high levels of backwards compatibility, it n=
eed not be 100% (heck, C++11 vector is not 100% backwards compatible with C=
++03 vector), and we shouldn't be adding more warts. The standard is =
the right place to fix this, and we should fix it and not just put a band a=
id on it.</div></div></blockquote><div><br>And how long will that take? C++=
14 is closed for new stuff, and the whole "deprecation/removal" process wil=
l require at least 2 revisions. So it would be C++20 <i>at least</i> before=
we can finally create a real `vector` of real `bool`s.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1954_14671050.1369855285276--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 29 May 2013 15:33:43 -0400
Raw View
On Wed, May 29, 2013 at 3:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I thought the primary argument was to be able to create a `vector` of
> `bool`s. I don't care about "uniformity"; what I care about is making a
> `vector` that actually contains `bool`s.
I care about the interfaces, and how people think what the
interfaces mean.
> And how long will that take? C++14 is closed for new stuff, and the whole
> "deprecation/removal" process will require at least 2 revisions. So it would
> be C++20 at least before we can finally create a real `vector` of real
> `bool`s.
The "removal" touches no working interfaces -- very
important -- this is not a removal (from some degree).
I'm going to draft a simple proposal anyway, and see if it's OK
for a TS/C++17. Considering the implementation and adoption
period, the users (are there any?) should have enough time to
switch to a boost::dynamic_bitset, or even some replacement
we are going to provide in the standard.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 14:36:17 -0500
Raw View
--047d7bb0420443ed0804dde081d1
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 14:21, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> I thought the primary argument was to be able to create a `vector` of
> `bool`s. I don't care about "uniformity"; what I care about is making a
> `vector` that actually contains `bool`s.
>
Then why bother spelling it "vector<bool>", if not to be used in a generic
and uniform context? It is unlikely the committee is willing to swap one
specialization of vector<bool> for another. I am well aware that there are
other ways to hack in std::real_bool (such as by using a traits class), but
it's still a hack. If it is that important, propose a different class to
do this not spelled "vector<bool>".
> And how long will that take? C++14 is closed for new stuff, and the whole
> "deprecation/removal" process will require at least 2 revisions. So it
> would be C++20 *at least* before we can finally create a real `vector` of
> real `bool`s.
>
For better or worse, that is the process.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7bb0420443ed0804dde081d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 14:21, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div>I thought the primary argument was to be able to create a `vector`=
of `bool`s. I don't care about "uniformity"; what I care abo=
ut is making a `vector` that actually contains `bool`s.<br></div></blockquo=
te>
<div><br>Then why bother spelling it "vector<bool>", if not=
to be used in a generic and uniform context?=A0 It is unlikely the committ=
ee is willing to swap one specialization of vector<bool> for another.=
=A0 I am well aware that there are other ways to hack in std::real_bool (su=
ch as by using a traits class), but it's still a hack.=A0 If it is that=
important, propose a different class to do this not spelled "vector&l=
t;bool>".<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And how long will t=
hat take? C++14 is closed for new stuff, and the whole "deprecation/re=
moval" process will require at least 2 revisions. So it would be C++20=
<i>at least</i> before we can finally create a real `vector` of real `bool=
`s.<br>
</div></blockquote><div><br>For better or worse, that is the process.<br></=
div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bb0420443ed0804dde081d1--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 May 2013 22:39:02 +0300
Raw View
--001a11c3c426b0bb6904dde08822
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 22:36, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 29 May 2013 14:21, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>> I thought the primary argument was to be able to create a `vector` of
>> `bool`s. I don't care about "uniformity"; what I care about is making a
>> `vector` that actually contains `bool`s.
>>
>
> Then why bother spelling it "vector<bool>", if not to be used in a generic
> and uniform context? It is unlikely the committee is willing to swap one
> specialization of vector<bool> for another. I am well aware that there are
> other ways to hack in std::real_bool (such as by using a traits class), but
> it's still a hack. If it is that important, propose a different class to
> do this not spelled "vector<bool>".
>
>
>
Well, I suppose it would be a different type of hack, but those who care
about having a vector of bools
could just write a bool-wrapping struct and put that into a vector.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c3c426b0bb6904dde08822
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 May 2013 22:36, Nevin Liber <span dir=3D"ltr"><<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 29 May 2013 14:21, Nico=
l Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br><div>I thought the primary argument was to be able to create a `vector`=
of `bool`s. I don't care about "uniformity"; what I care abo=
ut is making a `vector` that actually contains `bool`s.<br></div></blockquo=
te>
</div><div><br>Then why bother spelling it "vector<bool>", =
if not to be used in a generic and uniform context?=A0 It is unlikely the c=
ommittee is willing to swap one specialization of vector<bool> for an=
other.=A0 I am well aware that there are other ways to hack in std::real_bo=
ol (such as by using a traits class), but it's still a hack.=A0 If it i=
s that important, propose a different class to do this not spelled "ve=
ctor<bool>".<br>
</div><div class=3D"im"><div><br><br></div></div></div></blockquote><div><b=
r></div><div>Well, I suppose it would be a different type of hack, but thos=
e who care about having a vector of bools<br></div><div>could just write a =
bool-wrapping struct and put that into a vector. <br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c3c426b0bb6904dde08822--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Wed, 29 May 2013 21:42:19 +0200
Raw View
On 29/05/2013 21:39, Ville Voutilainen wrote:
> Well, I suppose it would be a different type of hack, but those who
> care about having a vector of bools could just write a bool-wrapping
> struct and put that into a vector.
Separation of concern. Container contains, values "value". I like this
approach
Then we can have a packed_bool stuff int he standard, but that's
basically having
the contrapose of the real_bool idea.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 29 May 2013 13:03:40 -0700
Raw View
On 5/29/13, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 29 May 2013 22:36, Nevin Liber <nevin@eviloverlord.com> wrote:
> > On 29 May 2013 14:21, Nicol Bolas <jmckesson@gmail.com> wrote:
> > > I thought the primary argument was to be able to create a
> > > `vector` of `bool`s. I don't care about "uniformity"; what I
> > > care about is making a `vector` that actually contains `bool`s.
> >
> > Then why bother spelling it "vector<bool>", if not to be
> > used in a generic and uniform context? It is unlikely the
> > committee is willing to swap one specialization of vector<bool>
> > for another. I am well aware that there are other ways to hack
> > in std::real_bool (such as by using a traits class), but it's
> > still a hack. If it is that important, propose a different
> > class to do this not spelled "vector<bool>".
>
> Well, I suppose it would be a different type of hack, but those
> who care about having a vector of bools could just write a
> bool-wrapping struct and put that into a vector.
I don't think that works because v[i] has a different type and
selects different overload sets and instantiations.
--
Lawrence Crowl
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 15:17:25 -0500
Raw View
--20cf3010ede756e00904dde114cb
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 14:33, Zhihao Yuan <lichray@gmail.com> wrote:
>
> > And how long will that take? C++14 is closed for new stuff, and the whole
> > "deprecation/removal" process will require at least 2 revisions. So it
> would
> > be C++20 at least before we can finally create a real `vector` of real
> > `bool`s.
>
> The "removal" touches no working interfaces -- very
> important -- this is not a removal (from some degree).
>
> I'm going to draft a simple proposal anyway, and see if it's OK
> for a TS/C++17.
Until it is a proposal, it's your time to waste, but so far every committee
member who has spoken in this thread is against just removing it from C++17
on the technicality that the space optimization is not required by the
standard. I'm pretty sure such a proposal will not take up much committee
time.
> Considering the implementation and adoption
> period, the users (are there any?) should have enough time to
> switch to a boost::dynamic_bitset, or even some replacement
> we are going to provide in the standard.
>
Removing useful functionality that users depend on without providing a
suitable replacement is very unlikely to pass. (And much as I like Boost,
pointing users to Boost is not an acceptable substitute.)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--20cf3010ede756e00904dde114cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 14:33, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:l=
ichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class=3D"im">
> And how long will that take? C++14 is closed for new stuff, and the wh=
ole<br>
> "deprecation/removal" process will require at least 2 revisi=
ons. So it would<br>
> be C++20 at least before we can finally create a real `vector` of real=
<br>
> `bool`s.<br>
<br>
</div>The "removal" touches no working interfaces -- very<br>
important -- this is not a removal (from some degree).<br>
<br>
I'm going to draft a simple proposal anyway, and see if it's OK<br>
for a TS/C++17.</blockquote><div><br>Until it is a proposal, it's your =
time to waste, but so far every committee member who has spoken in this thr=
ead is against just removing it from C++17 on the technicality that the spa=
ce optimization is not required by the standard.=A0 I'm pretty sure suc=
h a proposal will not take up much committee time.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"> =A0Considering the implementation =
and adoption<br>
period, the users (are there any?) should have enough time to<br>
switch to a boost::dynamic_bitset, or even some replacement<br>
we are going to provide in the standard.<br></blockquote><div><br>Removing =
useful functionality that users depend on without providing a suitable repl=
acement is very unlikely to pass. (And much as I like Boost, pointing users=
to Boost is not an acceptable substitute.)<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--20cf3010ede756e00904dde114cb--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 29 May 2013 22:39:09 +0200
Raw View
This is a multi-part message in MIME format.
--------------040305050602000905010207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/05/13 19:44, Nicol Bolas a =E9crit :
>
>
> On Wednesday, May 29, 2013 10:20:15 AM UTC-7, Vicente J. Botet Escriba=20
> wrote:
>
> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
>> On May 28, 2013, at 4:00 PM, Nicol Bolas<jmck...@gmail.com> <javasc=
ript:> wrote:
>>
>>> Personally, I agree with Howard; we should add a class that has all=
of this functionality (presumably with some degree of required sizing) tha=
t would be a drop-in replacement for those who need the sizing features of =
vector<bool>. But the question remains: even with a drop-in replacement, ho=
w much code will be broken because of this?
>> Model this after the auto_ptr -> unique_ptr transition:
>>
>> Step 1: Introduce bit_vector (or whatever) and deprecate the vector=
<bool> specialization. /Somehow/ motivate people to migrate.
> I think that we will need also to add a std::*new_*vector<T> that
> behaves like std::vector<T> but doesn't have the bool
> specialization and *deprecate* std::vector :->
>
>
> So your solution to this significant-yet-relatively-minor-problem...=20
> is to rip out the entire class?
Yes, the suggestion was not only heretical but unrealistic. vector<T> is=20
one of the most used containers.
>
> I'm going to go with "no" on that.
>
>
I understand. Not deprecating vector<T> at all could surely help.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--------------040305050602000905010207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 29/05/13 19:44, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite=3D"mid:e9303d5e-f51d-433f-8557-fb993611223d@isocpp.org"
type=3D"cite"><br>
<br>
On Wednesday, May 29, 2013 10:20:15 AM UTC-7, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/05/13 22:12, Howard Hinnant a écrit :<br>
</div>
<blockquote type=3D"cite">
<pre>On May 28, 2013, at 4:00 PM, Nicol Bolas <a moz-do-not-sen=
d=3D"true" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Zt-gPy6b1mMJ"><jmck...@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>Personally, I agree with Howard; we should add a class t=
hat has all of this functionality (presumably with some degree of required =
sizing) that would be a drop-in replacement for those who need the sizing f=
eatures of vector<bool>. But the question remains: even with a drop-i=
n replacement, how much code will be broken because of this?
</pre>
</blockquote>
<pre>Model this after the auto_ptr -> unique_ptr transition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote>
I think that we will need also to add a std::<b>new_</b>vector<=
;T>
that behaves like std::vector<T> but doesn't have the
bool specialization and <b>deprecate</b> std::vector :-><br>
</div>
</blockquote>
<div><br>
So your solution to this
significant-yet-relatively-minor-problem... is to rip out the
entire class?<br>
</div>
</blockquote>
Yes, the suggestion was not only heretical but unrealistic.
vector<T> is one of the most used containers. <br>
<blockquote
cite=3D"mid:e9303d5e-f51d-433f-8557-fb993611223d@isocpp.org"
type=3D"cite">
<div><br>
I'm going to go with "no" on that.</div>
<br>
<br>
</blockquote>
I understand. Not deprecating vector<T> at all could surely
help.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------040305050602000905010207--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 May 2013 23:51:51 +0300
Raw View
--047d7bea3948170f7204dde18d6a
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 23:03, Lawrence Crowl <crowl@googlers.com> wrote:
> >
> > Well, I suppose it would be a different type of hack, but those
> > who care about having a vector of bools could just write a
> > bool-wrapping struct and put that into a vector.
>
> I don't think that works because v[i] has a different type and
> selects different overload sets and instantiations.
>
>
>
Correct. That's a downside of every case of a wrapper type. Whether that is
a concern
is left as an exercise for the designer. :)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7bea3948170f7204dde18d6a
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 May 2013 23:03, Lawrence Crowl <span dir="ltr"><<a href="mailto:crowl@googlers.com" target="_blank">crowl@googlers.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">><br>
> Well, I suppose it would be a different type of hack, but those<br>
> who care about having a vector of bools could just write a<br>
> bool-wrapping struct and put that into a vector.<br>
<br>
</div></div>I don't think that works because v[i] has a different type and<br>
selects different overload sets and instantiations.<br>
<span class="HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>Correct. That's a downside of every case of a wrapper type. Whether that is a concern<br></div><div>is left as an exercise for the designer. :) <br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--047d7bea3948170f7204dde18d6a--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 29 May 2013 23:58:20 +0300
Raw View
--001a11c2927443af5b04dde1a42b
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 23:17, Nevin Liber <nevin@eviloverlord.com> wrote:
> The "removal" touches no working interfaces -- very
>
>> important -- this is not a removal (from some degree).
>>
>> I'm going to draft a simple proposal anyway, and see if it's OK
>> for a TS/C++17.
>
>
> Until it is a proposal, it's your time to waste, but so far every
> committee member who has spoken in this thread is against just removing it
> from C++17 on the technicality that the space optimization is not required
> by the standard. I'm pretty sure such a proposal will not take up much
> committee time.
>
I am fairly sure I'm opposed to just removing vector<bool>. Having a
superior type to migrate to and deprecating vector<bool>
would be much preferred. I have no preference between that solution and
leaving vector<bool> alone.
>
> Removing useful functionality that users depend on without providing a
> suitable replacement is very unlikely to pass. (And much as I like Boost,
> pointing users to Boost is not an acceptable substitute.)
>
>
>
Agreed on both counts.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--001a11c2927443af5b04dde1a42b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 May 2013 23:17, Nevin Liber <span dir=3D"ltr"><<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The "removal" touches no working i=
nterfaces -- very<br><div class=3D"gmail_quote"><div class=3D"im"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
important -- this is not a removal (from some degree).<br>
<br>
I'm going to draft a simple proposal anyway, and see if it's OK<br>
for a TS/C++17.</blockquote></div><div><br>Until it is a proposal, it's=
your time to waste, but so far every committee member who has spoken in th=
is thread is against just removing it from C++17 on the technicality that t=
he space optimization is not required by the standard.=A0 I'm pretty su=
re such a proposal will not take up much committee time.<br>
</div></div></blockquote><div><br></div><div>I am fairly sure I'm oppos=
ed to just removing vector<bool>. Having a superior type to migrate t=
o and deprecating vector<bool><br></div><div>would be much preferred.=
I have no preference between that solution and leaving vector<bool> =
alone.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><br>=
<div>Removing useful functionality that users depend on without providing a=
suitable replacement is very unlikely to pass. (And much as I like Boost, =
pointing users to Boost is not an acceptable substitute.)<br>
</div></div><div class=3D"im"><br><br></div></blockquote><div><br></div><di=
v>Agreed on both counts.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c2927443af5b04dde1a42b--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 29 May 2013 23:19:24 +0200
Raw View
This is a multi-part message in MIME format.
--------------030901000709050908050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/05/13 19:37, Nevin Liber a =E9crit :
> On 29 May 2013 12:20, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
>> On May 28, 2013, at 4:00 PM, Nicol Bolas<jmckesson@gmail.com> <mail=
to:jmckesson@gmail.com> wrote:
>>
>>> Personally, I agree with Howard; we should add a class that has all=
of this functionality (presumably with some degree of required sizing) tha=
t would be a drop-in replacement for those who need the sizing features of =
vector<bool>. But the question remains: even with a drop-in replacement, ho=
w much code will be broken because of this?
>> Model this after the auto_ptr -> unique_ptr transition:
>>
>> Step 1: Introduce bit_vector (or whatever) and deprecate the vector=
<bool> specialization. /Somehow/ motivate people to migrate.
> I think that we will need also to add a std::*new_*vector<T> that
> behaves like std::vector<T> but doesn't have the bool
> specialization and *deprecate* std::vector :->
>
>
> -100.
>
> * Annoying 99% of all C++ users is a horrible, horrible idea.
Right. Forget the last sentence.
>
> * I'd hate to use a code base that had two different, unrelated types=20
> for doing the exact same thing, since ultimately these things end up=20
> interfaces. Actually, I already have that, as people are trying to=20
> migrate from Boost over to std (such as shared_ptr), and it is=20
> anything but easy (because we are dependent on libraries developed=20
> for/by other groups, and changing those interfaces is a scheduling=20
> nightmare).
You are right. What we would need is 'single' type that behaves as the=20
current vector<T> except for bool and that behaves as vector<bool> if=20
vector was not specialized. I don't know if we can specialize an alias=20
and if the following is correct
template <typename T, typename Allocator>
class new_vector { the same definition as vector<T, Allocator> now };
template <typename T, typename Allocator>
alias vector=3D new_vector<T, Allocator> ;
template < typename Allocator>
class vector<bool, Allocator> { the same definition as now } ;
If this is correct, users of vector would get the same behavior. Users=20
of new_vector would get the behavior without the bool specialization.
Any function expecting a vector<T> work with new_vector<T> except for=20
bool. The same is valid for function expecting new_vector<T> you can use=20
it with vector<T> except for bool.
Of course we need a bit_vector class that replace the vector<bool>=20
specialization as Howard suggested.
After the deprecation period, new_vector and vector would have the same=20
behavior and new_vector could be deprecated at his turn.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--------------030901000709050908050009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 29/05/13 19:37, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite=3D"mid:CAGg_6+OS21ww71D-94NO0f0pLUDo6fGUULdZ6KkVc0aypwf_uw@mail.gmail.=
com"
type=3D"cite">On 29 May 2013 12:20, Vicente J. Botet Escriba <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicent=
e.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/05/13 22:12, Howard Hinnant a écrit :<br=
>
</div>
<div class=3D"im">
<blockquote type=3D"cite">
<pre>On May 28, 2013, at 4:00 PM, Nicol Bolas <a moz-do-not=
-send=3D"true" href=3D"mailto:jmckesson@gmail.com" target=3D"_blank"><jm=
ckesson@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>Personally, I agree with Howard; we should add a cla=
ss that has all of this functionality (presumably with some degree of requi=
red sizing) that would be a drop-in replacement for those who need the sizi=
ng features of vector<bool>. But the question remains: even with a dr=
op-in replacement, how much code will be broken because of this?
</pre>
</blockquote>
<pre>Model this after the auto_ptr -> unique_ptr transit=
ion:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote>
</div>
I think that we will need also to add a std::<b>new_</b>vector&=
lt;T>
that behaves like std::vector<T> but doesn't have the
bool specialization and <b>deprecate</b> std::vector :-><br>
</div>
</blockquote>
<div><br>
-100.<br>
<br>
* Annoying 99% of all C++ users is a horrible, horrible idea.<br>
</div>
</div>
</blockquote>
Right. Forget the last sentence.<br>
<blockquote
cite=3D"mid:CAGg_6+OS21ww71D-94NO0f0pLUDo6fGUULdZ6KkVc0aypwf_uw@mail.gmail.=
com"
type=3D"cite">
<div class=3D"gmail_quote">
<div><br>
* I'd hate to use a code base that had two different,
unrelated types for doing the exact same thing, since
ultimately these things end up interfaces. Actually, I
already have that, as people are trying to migrate from Boost
over to std (such as shared_ptr), and it is anything but easy
(because we are dependent on libraries developed for/by other
groups, and changing those interfaces is a scheduling
nightmare).<br>
</div>
</div>
</blockquote>
You are right. What we would need is 'single' type that behaves as
the current vector<T> except for bool and that behaves as
vector<bool> if vector was not specialized. I don't know if we
can specialize an alias and if the following is correct<br>
<br>
template <typename T, typename Allocator><br>
class new_vector { the same definition as vector<T, Allocator>
now };<br>
<br>
template <typename T, typename Allocator><br>
alias vector=3D new_vector<T, Allocator> ;<br>
<br>
template < typename Allocator><br>
class vector<bool, Allocator> { the same definition as now } ;<br=
>
<br>
If this is correct, users of vector would get the same behavior.
Users of new_vector would get the behavior without the bool
specialization.<br>
Any function expecting a vector<T> work with
new_vector<T> except for bool. The same is valid for function
expecting new_vector<T> you can use it with vector<T>
except for bool.<br>
<br>
Of course we need a bit_vector class that replace the
vector<bool> specialization as Howard suggested.<br>
After the deprecation period, new_vector and vector would have the
same behavior and new_vector could be deprecated at his turn. <br>
<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------030901000709050908050009--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 29 May 2013 17:21:25 -0400
Raw View
On Wed, May 29, 2013 at 4:17 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Until it is a proposal, it's your time to waste, but so far every committee
> member who has spoken in this thread is against just removing it from C++17
> on the technicality that the space optimization is not required by the
> standard. I'm pretty sure such a proposal will not take up much committee
> time.
What I don't understand it, what is the difference between removing
the optimization words and removing the specialization +
supporting vector<bool>'s extra interfaces in vector<T> when T == bool.
The interfaces of the standard are reminded the same, exactly
the same.
>> Considering the implementation and adoption
>> period, the users (are there any?) should have enough time to
>> switch to a boost::dynamic_bitset, or even some replacement
>> we are going to provide in the standard.
>
>
> Removing useful functionality that users depend on without providing a
> suitable replacement is very unlikely to pass. (And much as I like Boost,
> pointing users to Boost is not an acceptable substitute.)
Removing the performance words also makes vector<bool>
not functional, what's the differences?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 16:47:45 -0500
Raw View
--047d7bb042046ea9b704dde257e0
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 16:21, Zhihao Yuan <lichray@gmail.com> wrote:
>
> What I don't understand it, what is the difference between removing
> the optimization words and removing the specialization +
> supporting vector<bool>'s extra interfaces in vector<T> when T == bool.
>
Because real users, and in all likelihood the majority of current users of
vector<bool>, count on the space optimization even though it isn't
normative, since that was most certainly the intent of the specialization.
We don't live in an ivory tower.
IMO, the correct "fix" is (1) address current users who need the space
optimization that vector<bool> provides, and (2) vector (and generic code
using vector) should neither know nor care that it is being instantiated
with a bool. If that isn't where we are heading, I see no reason to mess
with either vector or vector<bool>.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7bb042046ea9b704dde257e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 16:21, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:l=
ichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
</div>What I don't understand it, what is the difference between removi=
ng<br>
the optimization words and removing the specialization +<br>
supporting vector<bool>'s extra interfaces in vector<T> whe=
n T =3D=3D bool.<br></blockquote><div><br>Because real users, and in all li=
kelihood the majority of current users of vector<bool>, count on the =
space optimization even though it isn't normative, since that was most =
certainly the intent of the specialization.=A0 We don't live in an ivor=
y tower.<br>
<br>IMO, the correct "fix" is (1) address current users who need =
the space optimization that vector<bool> provides, and (2) vector (an=
d generic code using vector) should neither know nor care that it is being =
instantiated with a bool.=A0 If that isn't where we are heading, I see =
no reason to mess with either vector or vector<bool>.<br clear=3D"all=
">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bb042046ea9b704dde257e0--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 29 May 2013 18:07:08 -0400
Raw View
On Wed, May 29, 2013 at 5:47 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Because real users, and in all likelihood the majority of current users of
> vector<bool>, count on the space optimization even though it isn't
> normative, since that was most certainly the intent of the specialization.
> We don't live in an ivory tower.
When I say "optimization words" I mean the words those break the
container natural to allow the optimization. If you remove the those words,
the optimization is disabled. The real users can longer count on it.
> IMO, the correct "fix" is (1) address current users who need the space
> optimization that vector<bool> provides, and (2) vector (and generic code
> using vector) should neither know nor care that it is being instantiated
> with a bool. If that isn't where we are heading, I see no reason to mess
> with either vector or vector<bool>.
That's my initial thought. I don't like to bother vector<T>, either (
although it does not pollute the actual interfaces). But the problem
is, how to address the "current users"?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 29 May 2013 17:15:48 -0500
Raw View
--047d7bd6acf4b5dc4d04dde2bbe1
Content-Type: text/plain; charset=ISO-8859-1
On 29 May 2013 17:07, Zhihao Yuan <lichray@gmail.com> wrote:
>
> When I say "optimization words" I mean the words those break the
> container natural to allow the optimization. If you remove the those
> words,
> the optimization is disabled. The real users can longer count on it.
>
If this breaks users of C++14 vector<bool>, then it is a non-starter for
C++17.
> That's my initial thought. I don't like to bother vector<T>, either (
> although it does not pollute the actual interfaces). But the problem
> is, how to address the "current users"?
>
With a new class that has the optimizations Howard talked about, as well as
a transition period of (at least) one standard cycle where the old behavior
of vector<bool> is deprecated but doesn't change.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
--047d7bd6acf4b5dc4d04dde2bbe1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 May 2013 17:07, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"mailto:l=
ichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
</div>When I say "optimization words" I mean the words those brea=
k the<br>
container natural to allow the optimization. =A0If you remove the those wor=
ds,<br>
the optimization is disabled. =A0The real users can longer count on it.<br>=
</blockquote><div><br>If this breaks users of C++14 vector<bool>, the=
n it is a non-starter for C++17.<br>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div class=3D"im">That's my initial thought. =A0I don't like to bot=
her vector<T>, either (<br></div>
although it does not pollute the actual interfaces). =A0But the problem<br>
is, how to address the "current users"?<br></blockquote><div><br>=
With a new class that has the optimizations Howard talked about, as well as=
a transition period of (at least) one standard cycle where the old behavio=
r of vector<bool> is deprecated but doesn't change. <br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bd6acf4b5dc4d04dde2bbe1--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 29 May 2013 19:03:08 -0400
Raw View
On Wed, May 29, 2013 at 6:15 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> When I say "optimization words" I mean the words those break the
>> container natural to allow the optimization. If you remove the those
>> words,
>> the optimization is disabled. The real users can longer count on it.
>
>
> If this breaks users of C++14 vector<bool>, then it is a non-starter for
> C++17.
If the non-mandatory optimization is required to be kept, then I'm
pretty sure we can make no useful changes to C++14 vector<bool>.
> With a new class that has the optimizations Howard talked about, as well as
> a transition period of (at least) one standard cycle where the old behavior
> of vector<bool> is deprecated but doesn't change.
TS: std::bit_vector
C++17: deprecation
C++2x: removal (completely)
You mean this? OMG...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 29 May 2013 22:23:54 -0400
Raw View
On Wed, May 29, 2013 at 7:03 PM, Zhihao Yuan <lichray@gmail.com> wrote:
>> With a new class that has the optimizations Howard talked about, as well as
>> a transition period of (at least) one standard cycle where the old behavior
>> of vector<bool> is deprecated but doesn't change.
>
> TS: std::bit_vector
> C++17: deprecation
> C++2x: removal (completely)
After some thoughts, I tend to agree with this approach. The final result
looks more clean, and it gives the proposers more time to refine the
essential std::bit_vector proposal (the addition can happens at the same
time as the deprecation, in C++17), and bothers no people.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 30 May 2013 08:06:55 +0200
Raw View
This is a multi-part message in MIME format.
--------------040209080501090604030800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/05/13 23:19, Vicente J. Botet Escriba a =E9crit :
> Le 29/05/13 19:37, Nevin Liber a =E9crit :
>> On 29 May 2013 12:20, Vicente J. Botet Escriba=20
>> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>>
>> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
>>> On May 28, 2013, at 4:00 PM, Nicol Bolas<jmckesson@gmail.com> <mai=
lto:jmckesson@gmail.com> wrote:
>>>
>>>> Personally, I agree with Howard; we should add a class that has al=
l of this functionality (presumably with some degree of required sizing) th=
at would be a drop-in replacement for those who need the sizing features of=
vector<bool>. But the question remains: even with a drop-in replacement, h=
ow much code will be broken because of this?
>>> Model this after the auto_ptr -> unique_ptr transition:
>>>
>>> Step 1: Introduce bit_vector (or whatever) and deprecate the vecto=
r<bool> specialization. /Somehow/ motivate people to migrate.
>> I think that we will need also to add a std::*new_*vector<T> that
>> behaves like std::vector<T> but doesn't have the bool
>> specialization and
>>
>>
>> * I'd hate to use a code base that had two different, unrelated types=20
>> for doing the exact same thing, since ultimately these things end up=20
>> interfaces. Actually, I already have that, as people are trying to=20
>> migrate from Boost over to std (such as shared_ptr), and it is=20
>> anything but easy (because we are dependent on libraries developed=20
>> for/by other groups, and changing those interfaces is a scheduling=20
>> nightmare).
> You are right. What we would need is 'single' type that behaves as the=20
> current vector<T> except for bool and that behaves as vector<bool> if=20
> vector was not specialized. I don't know if we can specialize an alias=20
> and if the following is correct
>
> template <typename T, typename Allocator>
> class new_vector { the same definition as vector<T, Allocator> now };
>
> template <typename T, typename Allocator>
> alias vector=3D new_vector<T, Allocator> ;
>
> template < typename Allocator>
> class vector<bool, Allocator> { the same definition as now } ;
>
> If this is correct,=20
Hrr, It seems that we can not specialize alias templates.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
--------------040209080501090604030800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 29/05/13 23:19, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite=3D"mid:51A670DC.2010102@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 29/05/13 19:37, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite=3D"mid:CAGg_6+OS21ww71D-94NO0f0pLUDo6fGUULdZ6KkVc0aypwf_uw@mail.gmail.=
com"
type=3D"cite">On 29 May 2013 12:20, Vicente J. Botet Escriba <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>Le 28/05/13 22:12, Howard Hinnant a écrit :<=
br>
</div>
<div class=3D"im">
<blockquote type=3D"cite">
<pre>On May 28, 2013, at 4:00 PM, Nicol Bolas <a moz-do-n=
ot-send=3D"true" href=3D"mailto:jmckesson@gmail.com" target=3D"_blank"><=
jmckesson@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>Personally, I agree with Howard; we should add a c=
lass that has all of this functionality (presumably with some degree of req=
uired sizing) that would be a drop-in replacement for those who need the si=
zing features of vector<bool>. But the question remains: even with a =
drop-in replacement, how much code will be broken because of this?
</pre>
</blockquote>
<pre>Model this after the auto_ptr -> unique_ptr trans=
ition:
Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l> specialization. /Somehow/ motivate people to migrate.</pre>
</blockquote>
</div>
I think that we will need also to add a std::<b>new_</b>vecto=
r<T>
that behaves like std::vector<T> but doesn't have
the bool specialization and<br>
</div>
</blockquote>
</div>
</blockquote>
<blockquote
cite=3D"mid:CAGg_6+OS21ww71D-94NO0f0pLUDo6fGUULdZ6KkVc0aypwf_uw@mail.gmail.=
com"
type=3D"cite">
<div class=3D"gmail_quote">
<div><br>
* I'd hate to use a code base that had two different,
unrelated types for doing the exact same thing, since
ultimately these things end up interfaces. Actually, I
already have that, as people are trying to migrate from
Boost over to std (such as shared_ptr), and it is anything
but easy (because we are dependent on libraries developed
for/by other groups, and changing those interfaces is a
scheduling nightmare).<br>
</div>
</div>
</blockquote>
You are right. What we would need is 'single' type that behaves as
the current vector<T> except for bool and that behaves as
vector<bool> if vector was not specialized. I don't know if
we can specialize an alias and if the following is correct<br>
<br>
template <typename T, typename Allocator><br>
class new_vector { the same definition as vector<T,
Allocator> now };<br>
<br>
template <typename T, typename Allocator><br>
alias vector=3D new_vector<T, Allocator> ;<br>
<br>
template < typename Allocator><br>
class vector<bool, Allocator> { the same definition as now }
;<br>
<br>
If this is correct, </blockquote>
<br>
Hrr, It seems that we can not specialize alias templates.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--------------040209080501090604030800--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 30 May 2013 08:11:38 +0200
Raw View
2013/5/30 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
> Le 29/05/13 23:19, Vicente J. Botet Escriba a =E9crit :
>
> Le 29/05/13 19:37, Nevin Liber a =E9crit :
>
> On 29 May 2013 12:20, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
> wrote:
>>
>> Le 28/05/13 22:12, Howard Hinnant a =E9crit :
>>
>> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> Personally, I agree with Howard; we should add a class that has all of
>> this functionality (presumably with some degree of required sizing) that
>> would be a drop-in replacement for those who need the sizing features of
>> vector<bool>. But the question remains: even with a drop-in replacement,=
how
>> much code will be broken because of this?
>>
>> Model this after the auto_ptr -> unique_ptr transition:
>>
>> Step 1: Introduce bit_vector (or whatever) and deprecate the vector<boo=
l>
>> specialization. /Somehow/ motivate people to migrate.
>>
>> I think that we will need also to add a std::new_vector<T> that behaves
>> like std::vector<T> but doesn't have the bool specialization and
>
>
> * I'd hate to use a code base that had two different, unrelated types for
> doing the exact same thing, since ultimately these things end up interfac=
es.
> Actually, I already have that, as people are trying to migrate from Boost
> over to std (such as shared_ptr), and it is anything but easy (because we
> are dependent on libraries developed for/by other groups, and changing th=
ose
> interfaces is a scheduling nightmare).
>
> You are right. What we would need is 'single' type that behaves as the
> current vector<T> except for bool and that behaves as vector<bool> if vec=
tor
> was not specialized. I don't know if we can specialize an alias and if th=
e
> following is correct
>
> template <typename T, typename Allocator>
> class new_vector { the same definition as vector<T, Allocator> now };
>
> template <typename T, typename Allocator>
> alias vector=3D new_vector<T, Allocator> ;
>
> template < typename Allocator>
> class vector<bool, Allocator> { the same definition as now } ;
>
> If this is correct,
>
> Hrr, It seems that we can not specialize alias templates.
This is by design. If you need that feature, use a class template to
realize that and use an alias to refer to the class template.
- Daniel
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/?hl=3Den.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sun, 25 Aug 2013 14:28:42 -0700 (PDT)
Raw View
------=_Part_62_22613202.1377466122666
Content-Type: text/plain; charset=ISO-8859-1
I remember in pre-standard days when I started out with C++ that the STL
implementation we used had a special bit_vector container on the side from
vector<bool> which was not in any way specialized. Now that the standard is
there and has been set for long it is in my opinion far to late to revert
the specialization, although introducing it was probably not so smart in
the first place.
Going back to the original paper we are discussing here I noticed that the
objectives for the suggested removal of the vector<bool> specialization was
mostly due to formalistic reasons. The exception is the well known problems
with tryinging to create a pointer to a bit and some performance issues.
Here are my comments:
- The pointer creation problem is not such an important issue as it is
immediately flagged as an error by the compiler. For example VS2012 gives
an "illegal indirection" error, as you can't take the address of the by
value return of &. It would of course be good if the diagnostic was easier
to understand but I don't see that it is significantly worse than other
error messages.
- The performance of the iterator, and its dereference operator etc. may be
better or worse than for instance for a vector<char>, which would be the
logical "benchmark". With today's computer hardware the CPU itself is
usually much faster than memory accesses so the reduced number of cache
misses (by a factor of 8 or more) would seem likely to outweigh the cost of
more bitwise operations, at least for larger vectors.
- Thanks to the vector<bool> iterators being special classes it should be
possible for the caring library implementer to specialize select algortihms
such as find. As bool itself has a very limited set of values there is a
reasonably small subset of the standard algorithms that make sense anyway.
To make this possible a "wordwise" access possibility must be added to
vector<bool>::iterator, as well as an accessor for the bit offset within
the current word. This API can be defined by each library implementer
(possibly using friend declarations to the algorithm specializations) or it
could be standardized so that new user defined algorithms working on
vector<bool> can use them in a well defined and portable way.
Thus, I would suggest to:
- Run a couple of benchmarks for regular usage to verify if the concerns
about undue slowness of the iterator operations is a big problem, a small
problem or not a problem.
- Define that vector<bool>::iterator has an API to access more than one bit
at a time, a quick sketch would be:
class iterator {
...
typedef X word_type;
static const int bits_per_word = sizeof(word_type) * 8;
size_t bit_now() const; // bit within the word that the
iterator points at now*
word_type& word_now(); // reference would be const for a
const_iterator
};
- Specialize some algorithms using the above API (this would be at the
discretion of library implementors I guess, but a reference implementation
would hint at attainable performance gain levels). Most important
algorithms from <algorithm> would be:
find
count
search
search_n
copy
swap_ranges
reverse
rotate
Most other algorithms, for instance replace, is meaningless for bool values
(the only thing you can do with replace is to make all values 0 or 1!).
By the way I can't remember having used vector<bool> despite now about 20
years of C++ so this issue is maybe not extremely important. If I were to
use it, however, I would think that inserting/removing bits in the middle
in a high performance way would be a very desirable feature in many
applications. I say this because the use case when you don't is relatively
easy to roll your own, but as soon as you start moving the bits around you
want someone else to iron out the wrinkles for you, and that's exactly what
we have a standard library for!
* A problem here is that many implementations (all?) use a bit mask to make
iterator accesses faster. Converting this bit to a number is costly on most
processors. Maybe the API would be better off if it returned the bit mask
instead, as it is less costly to convert from bit number to bit mask
(1<<bit_no).
Den tisdagen den 28:e maj 2013 kl. 17:50:23 UTC+2 skrev Zhihao Yuan:
>
> I saw Herb's paper:
>
> http://www.gotw.ca/publications/N1185.pdf
>
> But it's not adopted.
>
> Anyway, vector<bool> sucks, and we know it. How about to entirely
> remove it?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_62_22613202.1377466122666
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I remember in pre-standard days when I started out wi=
th C++ that the STL implementation we used had a special bit_vector contain=
er on the side from vector<bool> which was not in any way specialized=
.. Now that the standard is there and has been set for long it is in my opin=
ion far to late to revert the specialization, although introducing it was p=
robably not so smart in the first place.</div><div><br></div>Going back to =
the original paper we are discussing here I noticed that the objectives for=
the suggested removal of the vector<bool> specialization was mostly =
due to formalistic reasons. The exception is the well known problems with t=
ryinging to create a pointer to a bit and some performance issues. He=
re are my comments:<div><br></div><div>- The pointer creation problem is no=
t such an important issue as it is immediately flagged as an error by the c=
ompiler. For example VS2012 gives an "illegal indirection" error, as you ca=
n't take the address of the by value return of &. It would of course be=
good if the diagnostic was easier to understand but I don't see that it is=
significantly worse than other error messages. </div><div><br></div><=
div>- The performance of the iterator, and its dereference operator etc. ma=
y be better or worse than for instance for a vector<char>, which woul=
d be the logical "benchmark". With today's computer hardware the CPU itself=
is usually much faster than memory accesses so the reduced number of cache=
misses (by a factor of 8 or more) would seem likely to outweigh the cost o=
f more bitwise operations, at least for larger vectors.</div><div><br></div=
><div>- Thanks to the vector<bool> iterators being special classes it=
should be possible for the caring library implementer to specialize select=
algortihms such as find. As bool itself has a very limited set of values t=
here is a reasonably small subset of the standard algorithms that make sens=
e anyway. To make this possible a "wordwise" access possibility must be add=
ed to vector<bool>::iterator, as well as an accessor for the bit offs=
et within the current word. This API can be defined by each library impleme=
nter (possibly using friend declarations to the algorithm specializations) =
or it could be standardized so that new user defined algorithms working on =
vector<bool> can use them in a well defined and portable way.</div><d=
iv><br></div><div>Thus, I would suggest to:</div><div><br></div><div>- Run =
a couple of benchmarks for regular usage to verify if the concerns about un=
due slowness of the iterator operations is a big problem, a small problem o=
r not a problem.</div><div><br></div><div>- Define that vector<bool>:=
:iterator has an API to access more than one bit at a time, a quick sketch =
would be:</div><div><br></div><div> class iterator {</div><div=
> ...</div><div> type=
def X word_type;</div><div> static const int bit=
s_per_word =3D sizeof(word_type) * 8;</div><div> =
</div><div> size_t bit_now() const; =
// bit within the word that the iterator points at now=
*</div><div> word_type& word_now(); /=
/ reference would be const for a const_iterator</div><div> };<=
/div><div><br></div><div>- Specialize some algorithms using the above API (=
this would be at the discretion of library implementors I guess, but a refe=
rence implementation would hint at attainable performance gain levels). Mos=
t important algorithms from <algorithm> would be:</div><div><br></div=
><div>find</div><div>count</div><div>search</div><div>search_n</div><div>co=
py</div><div>swap_ranges</div><div>reverse</div><div>rotate</div><div><br><=
/div><div>Most other algorithms, for instance replace, is meaningless for b=
ool values (the only thing you can do with replace is to make all values 0 =
or 1!).</div><div><br></div><div>By the way I can't remember having used ve=
ctor<bool> despite now about 20 years of C++ so this issue is maybe n=
ot extremely important. If I were to use it, however, I would think that in=
serting/removing bits in the middle in a high performance way would be a ve=
ry desirable feature in many applications. I say this because the use case =
when you don't is relatively easy to roll your own, but as soon as you star=
t moving the bits around you want someone else to iron out the wrinkles for=
you, and that's exactly what we have a standard library for!<br><br>* A pr=
oblem here is that many implementations (all?) use a bit mask to make itera=
tor accesses faster. Converting this bit to a number is costly on most proc=
essors. Maybe the API would be better off if it returned the bit mask inste=
ad, as it is less costly to convert from bit number to bit mask (1<<b=
it_no).</div><div><br>Den tisdagen den 28:e maj 2013 kl. 17:50:23 UTC+2 skr=
ev Zhihao Yuan:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I saw Herb's pa=
per:
<br>
<br> <a href=3D"http://www.gotw.ca/publications/N1185.pdf" target=3D"=
_blank">http://www.gotw.ca/<wbr>publications/N1185.pdf</a>
<br>
<br>But it's not adopted.
<br>
<br>Anyway, vector<bool> sucks, and we know it. How about to en=
tirely
<br>remove it?
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_62_22613202.1377466122666--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 25 Aug 2013 17:04:24 -0500
Raw View
--047d7b33d790f7763004e4ccd484
Content-Type: text/plain; charset=ISO-8859-1
On 25 August 2013 16:28, Bengt Gustafsson <bengt.gustafsson@beamways.com>wrote:
>
> - Define that vector<bool>::iterator has an API to access more than one
> bit at a time,
>
I do not believe the solution to the vector<bool> issue is to make it even
more special and different. -1.
If you really think this functionality is needed in the standard, (a)
create a different class with that functionality, (b) get a lot of real
world usage experience with that class and (c) then propose such a class
for standardization.
Just my humble opinion,
--
>
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--047d7b33d790f7763004e4ccd484
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 25 August 2013 16:28, Bengt =
Gustafsson <span dir=3D"ltr"><<a href=3D"mailto:bengt.gustafsson@beamway=
s.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>></span> wrote=
:<br><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>- Defin=
e that vector<bool>::iterator has an API to access more than one bit =
at a time,<br>
</div></div></blockquote><div><br></div><div>I do not believe the solution =
to the vector<bool> issue is to make it even more special and differe=
nt. =A0-1.</div><div><br></div><div>If you really think this functionality =
is needed in the standard, (a) create a different class with that functiona=
lity, (b) get a lot of real world usage experience with that class and (c) =
then propose such a class for standardization.</div>
<div><br></div><div>Just my humble opinion,</div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>--=A0<br></div></div></blockquote=
></div>
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1=
404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b33d790f7763004e4ccd484--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Mon, 26 Aug 2013 09:46:26 +0200
Raw View
This is a multi-part message in MIME format.
--------------010404030202090303070601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
I was just trying to be pragmatic about solving the actual problems we=20
are discussing, which should be problems that are of interest to real=20
programmer's use of the language. I freely admit that the vector<bool>=20
specialization is a wart but I don't see that this actually creates a=20
lot of problems in the real world. Could anyone exemplify a reasonable=20
usage that fails in a hard to detect way?
The real problems I could detect with vector<bool> were that the=20
performance of algorithms like count() is significantly less than it=20
could be. I suggested how this could be solved in a way that is totally=20
invisible to the programmer. I also suggested that the API required=20
could be standardized to allow user-defined algorithms to take advantage=20
of the speedup.
From a practical programmer's standpoint I think it is very neat that=20
vector<bool> hides the fact that there is a special implementation=20
underneath. If another very similar but different class is introduced I=20
can't see that this would make the language easier to understand or use.
If bit_vector is introduced all template code that uses vector<T> and=20
would benefit from a packed structure would need to be specialized for=20
bool. Is that really better?
In short I think that the formal drawbacks of vector<bool> such as "it=20
not being a proper sequence" has very little practical consequence. The=20
advantages of the packed storage is large in some applications, many of=20
which have already been written assuming that storage use will be on par=20
with a packed implementation.
I must also correct myself, I was too quick when testing the error=20
message. There is no error message if you do &* on a=20
vector<bool>::iterator. This is a real practical problem that can puzzle=20
a programmer, although doing things that would fail like size_t length =3D=
=20
&*vec.end() - &*vec.begin() seems rather odd... Most other uses of the=20
pointer actually work as the reference class is intended to mimic what a=20
bool does.
Overloading vector<bool>::reference::operator&() to do a=20
static_assert(false) could be a solution. Of course there will be a few=20
programs out there that correctly use this operator, but my guess is=20
that such a overload would discover 10 times more bugs than it will=20
break existing, meaningful code. A regular method could be added to do=20
the work of the unoverloaded operator:
class reference {
....
reference* operator&() { static_assert(false, "you can no longer=20
take the address of a vector<bool>::reference, instead use=20
make_pointer()"); }
reference* make_pointer() { return this; }
};
An alternative solution would be to let operator& return an iterator=20
again. This could be confusing as the main use of &* on an iterator is=20
to convert it to a plain pointer, so personally I would prefer to outlaw=20
operator&, if anything really must be changed.
Nevin Liber skrev 2013-08-26 00:04:
> On 25 August 2013 16:28, Bengt Gustafsson=20
> <bengt.gustafsson@beamways.com <mailto:bengt.gustafsson@beamways.com>>=20
> wrote:
>
>
> - Define that vector<bool>::iterator has an API to access more
> than one bit at a time,
>
>
> I do not believe the solution to the vector<bool> issue is to make it=20
> even more special and different. -1.
>
> If you really think this functionality is needed in the standard, (a)=20
> create a different class with that functionality, (b) get a lot of=20
> real world usage experience with that class and (c) then propose such=20
> a class for standardization.
>
> Just my humble opinion,
>
> --=20
>
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com=20
> <mailto:nevin@eviloverlord.com>> (847) 691-1404
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/.
--------------010404030202090303070601
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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?<br>
<br>
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.<br>
<br>
From a practical programmer's standpoint I think it is very neat
that vector<bool> hides the fact that there is a special
implementation underneath. If another very similar but different
class is introduced I can't see that this would make the language
easier to understand or use.<br>
<br>
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?<br>
<br>
In short I think that the formal drawbacks of vector<bool>
such as "it not being a proper sequence" has very little practical
consequence. The advantages of the packed storage is large in some
applications, many of which have already been written assuming that
storage use will be on par with a packed implementation.<br>
<br>
I must also correct myself, I was too quick when testing the error
message. There is no error message if you do &* on a
vector<bool>::iterator. This is a real practical problem that
can puzzle a programmer, although doing things that would fail like
size_t length = &*vec.end() - &*vec.begin() seems rather
odd... Most other uses of the pointer actually work as the reference
class is intended to mimic what a bool does.<br>
<br>
Overloading vector<bool>::reference::operator&() to do a
static_assert(false) could be a solution. Of course there will be a
few programs out there that correctly use this operator, but my
guess is that such a overload would discover 10 times more bugs than
it will break existing, meaningful code. A regular method could be
added to do the work of the unoverloaded operator: <br>
<br>
class reference {<br>
....<br>
reference* operator&() { static_assert(false, "you can no
longer take the address of a vector<bool>::reference, instead
use make_pointer()"); }<br>
reference* make_pointer() { return this; }<br>
};<br>
<br>
An alternative solution would be to let operator& return an
iterator again. This could be confusing as the main use of &* on
an iterator is to convert it to a plain pointer, so personally I
would prefer to outlaw operator&, if anything really must be
changed.<br>
<br>
<div class="moz-cite-prefix">Nevin Liber skrev 2013-08-26 00:04:<br>
</div>
<blockquote
cite="mid:CAGg_6+O_d85CBjT+cTV6vQqepUTXVvUMV_QUioS6ELpQCav6GQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">On 25 August 2013 16:28, Bengt
Gustafsson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bengt.gustafsson@beamways.com"
target="_blank">bengt.gustafsson@beamways.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>- Define that vector<bool>::iterator has an
API to access more than one bit at a time,<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I do not believe the solution to the vector<bool>
issue is to make it even more special and different. -1.</div>
<div><br>
</div>
<div>If you really think this functionality is needed in the
standard, (a) create a different class with that
functionality, (b) get a lot of real world usage
experience with that class and (c) then propose such a
class for standardization.</div>
<div><br>
</div>
<div>Just my humble opinion,</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>-- <br>
</div>
</div>
</blockquote>
</div>
Nevin ":-)" Liber <mailto:<a moz-do-not-send="true"
href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>>
(847) 691-1404
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Linköping, Sweden
+46 13 465 10 85
<a class="moz-txt-link-abbreviated" href="http://www.beamways.com">www.beamways.com</a>
</pre>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------010404030202090303070601--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 26 Aug 2013 06:22:00 -0700 (PDT)
Raw View
------=_Part_64_15372834.1377523320745
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 12:46:26 AM UTC-7, Bengt Gustafsson wrote:
>
> 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 to detect" way. Generally speaking, when
vector<bool> fails to act like a `vector` of `bool`s, it's pretty noisy
about it. The problem is that, silent or not, if you really needed an
honest-to-God `vector` that contains `bool`s, you *can't get one*.
> 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 neat that
> vector<bool> hides the fact that there is a special implementation
> underneath.
>
If it actually hid the fact, that might be true. But it doesn't. Consider
the following:
void OperateOnBoolArray(const bool *array, size_t count);
vector<bool> stuff = {...};
OperateOnBoolArray(stuff.data(), stuff.size());
If the types here were anything *besides* `bool`, this would be perfectly
legitimate code. But it's not..
Nothing is being hidden here; `vector<bool>` is not a `vector`. It doesn't
provide the interface for a vector. And if you think this is too
theoretical, consider some template code:
template<class T>
void Proc()
{
vector<T> arr = {...};
OperateOnArray(arr.data(), arr.size());
}
By all rights, this code *ought* to work with any type T. But it doesn't;
if you stick `bool` in there, the compiler will fail, since `vector<bool>`
doesn't have a `data` member. Because `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.
>
>
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 provides us a
pathway whereby we can *get rid of `vector<bool>`*. That'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-replace on "vector<bool>" with
"bit_vector", and their code should immediately 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, we will have what we should have had 20 years
before: a real `vector` that can contain real `bool`s, and a type that is a
space-optimized pseudo-container that has `bool`-like stuff in it. We can
even add new interfaces to that container, the way boost::dynamic_bitset
has some useful functions on it.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_64_15372834.1377523320745
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 26, 2013 12:46:26 AM UTC-7, Bengt Gustaf=
sson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
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?<br></div></blockquote><div><br>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 <i>can't get one</i>.<br> </div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=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.</div></blockquote><div><br> </di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolo=
r=3D"#FFFFFF">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.</div></blockquote><div><br>If it actually hi=
d the fact, that might be true. But it doesn't. Consider the following:<br>=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">OperateOnBoolArray</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">array</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> size_t count</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br>vector</span><span style=3D"color: #080;" class=3D"styled-by-prettify">=
<bool></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> stuff </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{...};</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">OperateOnBoolArray</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">stuff</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> stuff</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">size</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">());</span></div></code></div><br>If the types here were anything <i>besi=
des</i> `bool`, this would be perfectly legitimate code. But it's not..<br>=
<br>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:<br><br><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Proc</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> vector</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> arr </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{...};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ope=
rateOnArray</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">arr</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> arr</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">size</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">());</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>By all rights, this code <i>ought</i> 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.<br> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#F=
FFFFF">If another very similar but different
class is introduced I can't see that this would make the language
easier to understand or use.<br></div></blockquote><blockquote style=3D=
"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padd=
ing-left: 1ex;" class=3D"gmail_quote"><div> </div></blockquote><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFF=
FFF">
=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?<br></div></blockquot=
e><div><br>No, it's not. The only way "bit_vector" is better is that it pro=
vides us a pathway whereby we can <i>get rid of `vector<bool>`</i>. T=
hat's the <i>only</i> 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>`.<br><br>That way, C++17 can deprecate the `=
vector<bool>` specialization, and C++20 can <i>remove</i> 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.=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000=
" bgcolor=3D"#FFFFFF">
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_64_15372834.1377523320745--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 10:21:04 -0400
Raw View
On Mon, Aug 26, 2013 at 9:22 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> They can do a find-replace on "vector<bool>" with
> "bit_vector", and their code should immediately work as before. It needs to
> be a drop-in replacement so that they can stop using `vector<bool>`.
What I don't understand is why all of you think a drop-in replacement
of `vector<bool>` is possible. `vector<bool>` is already proven to
be wrong. Its iterator does not even meet the ForwardIterator
requirement. Change the whole iterator categories just to unblock
proxy iterator? Dave already tried -- not accepted. `vector<bool>`
is just a mistake, a drop-in replacement of an mistake is also wrong.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 26 Aug 2013 16:23:05 +0200
Raw View
2013/8/26 Zhihao Yuan <zy@miator.net>:
>`vector<bool>` is already proven to
> be wrong. Its iterator does not even meet the ForwardIterator
> requirement. Change the whole iterator categories just to unblock
> proxy iterator? Dave already tried -- not accepted.
IMO the only reasonable choice is to retry that step - the current
iterator categories *are* broken.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 10:38:20 -0400
Raw View
On Mon, Aug 26, 2013 at 10:23 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> IMO the only reasonable choice is to retry that step - the current
> iterator categories *are* broken.
Then the next problem comes. After the iterator requirements are
fixed, bit iterators are still slow. Yes, we can specialized known
STL algorithms for the bit iterators, like what libc++ did. But --
user can not create their own algorithms to benefit from those.
Then Bengt comes and says, we need to open the APIs for
bit iterators...
Worth? Maybe it's just "easier" to let all C++ books criticize
`vector<bool>` years after years.
I prefer to use `std::basic_string`'s approach: index-based
operations as member functions -- without iterators -- just
make the things possible into things working.
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 26 Aug 2013 16:10:03 -0700 (PDT)
Raw View
------=_Part_33_10759160.1377558603575
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 7:21:04 AM UTC-7, Zhihao Yuan wrote:
>
> On Mon, Aug 26, 2013 at 9:22 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > They can do a find-replace on "vector<bool>" with
> > "bit_vector", and their code should immediately work as before. It needs
> to
> > be a drop-in replacement so that they can stop using `vector<bool>`.
>
> What I don't understand is why all of you think a drop-in replacement
> of `vector<bool>` is possible. `vector<bool>` is already proven to
> be wrong. Its iterator does not even meet the ForwardIterator
> requirement. Change the whole iterator categories just to unblock
> proxy iterator? Dave already tried -- not accepted. `vector<bool>`
> is just a mistake, a drop-in replacement of an mistake is also wrong.
>
But it is possible. The problem with `vector<bool>` is that it's called a *
vector*, and therefore is expected to actually produce iterators that
follow the iterator concepts and so forth.
`bit_vector` can do whatever it wants, because it's not a real vector. It
can spit out "pseudo-iterators". It can do whatever. It can have the
interface it has, and nobody has any explicit expectations that this
interface matches that of the containers as defined by chapter 23.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_33_10759160.1377558603575
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 26, 2013 7:21:04 AM UTC-7, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Aug 26, 2=
013 at 9:22 AM, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"PWtlBeY1oNoJ">jmck...@gmail.com</a>> wrote:
<br>> They can do a find-replace on "vector<bool>" with
<br>> "bit_vector", and their code should immediately work as before. It=
needs to
<br>> be a drop-in replacement so that they can stop using `vector<bo=
ol>`.
<br>
<br>What I don't understand is why all of you think a drop-in replacement
<br>of `vector<bool>` is possible. `vector<bool>` is alre=
ady proven to
<br>be wrong. Its iterator does not even meet the ForwardIterator
<br>requirement. Change the whole iterator categories just to unblock
<br>proxy iterator? Dave already tried -- not accepted. `vector=
<bool>`
<br>is just a mistake, a drop-in replacement of an mistake is also wrong.<b=
r></blockquote><div><br>But it is possible. The problem with `vector<boo=
l>` is that it's called a <i>vector</i>, and therefore is expected to ac=
tually produce iterators that follow the iterator concepts and so forth.<br=
><br>`bit_vector` can do whatever it wants, because it's not a real vector.=
It can spit out "pseudo-iterators". It can do whatever. It can have the in=
terface it has, and nobody has any explicit expectations that this interfac=
e matches that of the containers as defined by chapter 23.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_33_10759160.1377558603575--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 19:18:07 -0400
Raw View
On Mon, Aug 26, 2013 at 7:10 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> `bit_vector` can do whatever it wants, because it's not a real vector. It
> can spit out "pseudo-iterators". It can do whatever. It can have the
> interface it has, and nobody has any explicit expectations that this
> interface matches that of the containers as defined by chapter 23.
So you mean it's Okey for bitvector's begin() to produce an
object which can be used in any STL algorithms but such an object
fits into no iterator categories? Don't you think that's an anti-pattern
of STL design?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 26 Aug 2013 19:22:51 -0400
Raw View
On Aug 26, 2013, at 7:18 PM, Zhihao Yuan <zy@miator.net> wrote:
> So you mean it's Okey for bitvector's begin() to produce an
> object which can be used in any STL algorithms but such an object
> fits into no iterator categories? Don't you think that's an anti-pattern
> of STL design?
Question for Zhihao:
Why does forward iterator's operator*() have to return a value_type& ?
I'm well aware that this is what C++98/03/11 requires. That's not what I'm asking. I'm asking what is the benefit of this requirement in the C++1y context? What problem does this requirement solve?
Howard
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 19:57:53 -0400
Raw View
On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> Question for Zhihao:
>
> Why does forward iterator's operator*() have to return a value_type& ?
>
> I'm well aware that this is what C++98/03/11 requires. That's not what I'm asking. I'm asking what is the benefit of this requirement in the C++1y context? What problem does this requirement solve?
Afaics, it makes the pointed object modifiable. And move_iterator
significantly benefits from it. (Here is something I'm not sure:
move_iterator requires only InputIterator, while dereferencing an
InputIterator may return anything convertible to T -- is there anything
broken here?)
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 26 Aug 2013 20:09:45 -0400
Raw View
On Aug 26, 2013, at 7:57 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>> Question for Zhihao:
>>
>> Why does forward iterator's operator*() have to return a value_type& ?
>>
>> I'm well aware that this is what C++98/03/11 requires. That's not what I'm asking. I'm asking what is the benefit of this requirement in the C++1y context? What problem does this requirement solve?
>
> Afaics, it makes the pointed object modifiable.
But today, I can do:
std::vector<boo> v(1);
*v.begin() = true;
And yet vector<bool>::iterator::operator*() isn't returning a bool&. But I am still modifying the referenced object.
> And move_iterator
> significantly benefits from it. (Here is something I'm not sure:
> move_iterator requires only InputIterator, while dereferencing an
> InputIterator may return anything convertible to T -- is there anything
> broken here?)
Yes.
http://cplusplus.github.io/LWG/lwg-active.html#2106
Howard
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Geoffrey Romer <gromer@google.com>
Date: Mon, 26 Aug 2013 17:16:55 -0700
Raw View
--047d7bd6afda561e4a04e4e2ca5f
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Aug 26, 2013 at 4:22 PM, Howard Hinnant <howard.hinnant@gmail.com>wrote:
>
> On Aug 26, 2013, at 7:18 PM, Zhihao Yuan <zy@miator.net> wrote:
>
> > So you mean it's Okey for bitvector's begin() to produce an
> > object which can be used in any STL algorithms but such an object
> > fits into no iterator categories? Don't you think that's an anti-pattern
> > of STL design?
>
> Question for Zhihao:
>
> Why does forward iterator's operator*() have to return a value_type& ?
> I'm well aware that this is what C++98/03/11 requires. That's not what
> I'm asking. I'm asking what is the benefit of this requirement in the
> C++1y context? What problem does this requirement solve?
>
I'm not Zhihao, but...
One problem this solves is that code like this is guaranteed to work:
template <typename iter_t>
value_type& GetValue(iter_t iter) {
return *iter;
}
If operator* can return a proxy with an implicit conversion to value_type,
GetValue is at serious risk of undefined behavior. I've seen multiple real
bugs in the wild arising from this problem, and they are truly heinous to
diagnose (they've led to a concerted effort to purge Boost.ptr_container, a
repeat offender in this respect, from our codebase).
This is not a knock-down objection, but it's an important cost to bear in
mind.
> Howard
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email 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/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--047d7bd6afda561e4a04e4e2ca5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Mon, Aug 26, 2013 at 4:22 PM, Howard Hinnant <span dir=3D"ltr"><<a hr=
ef=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnant@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><br>
On Aug 26, 2013, at 7:18 PM, Zhihao Yuan <<a href=3D"mailto:zy@miator.ne=
t">zy@miator.net</a>> wrote:<br>
<br>
> So you mean it's Okey for bitvector's begin() to produce an<br=
>
> object which can be used in any STL algorithms but such an object<br>
> fits into no iterator categories? =A0Don't you think that's an=
anti-pattern<br>
> of STL design?<br>
<br>
</div>Question for Zhihao:<br>
<br>
Why does forward iterator's operator*() have to return a value_type&=
; ?</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">
<br>
I'm well aware that this is what C++98/03/11 requires. =A0That's no=
t what I'm asking. =A0I'm asking what is the benefit of this requir=
ement in the C++1y context? =A0What problem does this requirement solve?<br=
>
</blockquote><div><br></div><div><div><br class=3D"">I'm not=A0Zhihao, =
but...</div><div><br></div><div>One problem this solves is that code like t=
his is guaranteed to work:</div><div><br></div><div>template <typename i=
ter_t></div>
<div>value_type& GetValue(iter_t iter) {</div><div>=A0 return *iter;</d=
iv><div>}</div><div><br></div><div>If operator* can return a proxy with an =
implicit conversion to value_type, GetValue is at serious risk of undefined=
behavior. I've seen multiple real bugs in the wild arising from this p=
roblem, and they are truly heinous to diagnose (they've led to a concer=
ted effort to purge Boost.ptr_container, a repeat offender in this respect,=
from our codebase).</div>
<div><br></div><div>This is not a knock-down objection, but it's an imp=
ortant cost to bear in mind.</div><div><br></div></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=3D""><font color=3D"#888888"><br>
Howard<br>
</font></span><div class=3D""><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd6afda561e4a04e4e2ca5f--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 20:28:00 -0400
Raw View
On Mon, Aug 26, 2013 at 8:16 PM, Geoffrey Romer <gromer@google.com> wrote:
> template <typename iter_t>
> value_type& GetValue(iter_t iter) {
> return *iter;
> }
I think this can be "corrected" by just replacing the return type
with `auto` :(
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 26 Aug 2013 20:36:11 -0400
Raw View
On Aug 26, 2013, at 8:28 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Mon, Aug 26, 2013 at 8:16 PM, Geoffrey Romer <gromer@google.com> wrote=
:
>> template <typename iter_t>
>> value_type& GetValue(iter_t iter) {
>> return *iter;
>> }
>=20
> I think this can be "corrected" by just replacing the return type
> with `auto` :(
I was going to suggest:
typename std::iterator_traits<iter_t>::reference
but I like Zhihao's suggestion a lot better. Unless you need the iterator_=
traits dance for SFINAE purposes.
Bottom line: All we have to do is stop assuming that *iter returns a value=
_type&. We already can not assume that for input iterators, do this does n=
ot seem like a big stretch. And we already can not assume it for output it=
erators, even though we can use output iterators to modify values.
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 26 Aug 2013 20:56:45 -0400
Raw View
On Aug 26, 2013, at 8:16 PM, Geoffrey Romer <gromer@google.com> wrote:
> One problem this solves is that code like this is guaranteed to work:
>
> template <typename iter_t>
> value_type& GetValue(iter_t iter) {
> return *iter;
> }
Oops, I just realized this code is pretty dangerous even neglecting proxy iterators:
There's no enforced connection between iter_t and value_type. So what happens when value_type is const int and:
double d;
double* dp = &d;
const int& cr = GetValue(dp);
You've got a dangling reference. And I didn't even have to use proxies to crash this one. To make this safer one could (use auto, or):
template <typename iter_t>
typename std::iterator_traits<iter_t>::value_type&
GetValue(iter_t iter)
{
return *iter;
}
But by the time you've gone this far...
template <typename iter_t>
typename std::iterator_traits<iter_t>::reference
GetValue(iter_t iter)
{
return *iter;
}
Howard
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 20:58:34 -0400
Raw View
On Mon, Aug 26, 2013 at 8:36 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> Bottom line: All we have to do is stop assuming that *iter returns a value_type&.
Conceptually agree. And Stepanov's "Elements of Programming" 9.1
has the same thought: Writability as an assignment to _sink_(x), while
_sink_(x) is not necessarily a "real" reference to `x`.
Ah, I see... We should be able to specialize iterator_traits to unblock
proxy iterators...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 26 Aug 2013 21:06:37 -0400
Raw View
On Aug 26, 2013, at 8:58 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Mon, Aug 26, 2013 at 8:36 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>> Bottom line: All we have to do is stop assuming that *iter returns a va=
lue_type&.
>=20
> Conceptually agree. And Stepanov's "Elements of Programming" 9.1
> has the same thought: Writability as an assignment to _sink_(x), while
> _sink_(x) is not necessarily a "real" reference to `x`.
>=20
> Ah, I see... We should be able to specialize iterator_traits to unblock
> proxy iterators...
And actually we already have done this for input iterators and output itera=
tors. We just have this legacy requirement hanging around that forward ite=
rators (and bi and rand) must return a value_type& from operator*() (const =
value_type& for non-mutable variants). The T& return from forward iterator=
operator*() is kind of like dandelions. It kind of looks pretty. And it =
is very hard to get rid of. :-) But I think we should make an effort to do=
so.
libc++ is a working implementation where vector<bool>::[const_]iterator wor=
ks with everything in <algorithm>; some, but not enough of the algorithms a=
t greatly increased performance. I.e. there is shipping implementation pra=
ctice to back up all of my hot air. And we still need to deal with the fac=
t that vector<bool> has a terrible name.
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 26 Aug 2013 18:54:48 -0700 (PDT)
Raw View
------=_Part_61_9520664.1377568488583
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 27, 2013 9:06:37 AM UTC+8, Howard Hinnant wrote:
>
>
> On Aug 26, 2013, at 8:58 PM, Zhihao Yuan <z...@miator.net <javascript:>>
> wrote:
>
> > Ah, I see... We should be able to specialize iterator_traits to unblock
> > proxy iterators...
>
> And actually we already have done this for input iterators and output
> iterators. We just have this legacy requirement hanging around that
> forward iterators (and bi and rand) must return a value_type& from
> operator*() (const value_type& for non-mutable variants). The T& return
> from forward iterator operator*() is kind of like dandelions. It kind of
> looks pretty. And it is very hard to get rid of. :-) But I think we
> should make an effort to do so.
>
Amen brother. Fleshing out the generic semantics will clean a mess that
trying to scrub out details will only worsen. And progress forward rather
than trip over trying to run backwards.
But the cleanup should extend into allocators as well. The allocator
supplies the mapping (Allocator::address) from Iterator::reference to
Iterator::pointer.
Conceptually, packing bits is an optimization of allocation. Aside from
special functions like vector<bool>::flip, vector<bool> shouldn't need to
be a specialization at all. With appropriately generic address arithmetic,
and concepts to enable the special members, std::vector<bool> could be the
generic instantiation of std::vector< bool, bitpacking_allocator >. Then
std::deque could benefit from the same optimized algorithms, because its
node and iterator classes would have internal bit-pointers.
The default allocator type argument of std::vector would be an alias
template to select either std::allocator<T> or std::bitpacking_allocator.
Users who want the non-packed functionality would explicitly specify
std::allocator<T>. Migration would be reduced to deprecating that alias
template.
Properly generic iterators/allocators should also allow range access to
files, or if you prefer, user-space virtual memory. Interleaved arrays
would be another application. I think we're missing out on a lot.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_61_9520664.1377568488583
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 9:06:37 AM UTC+8, Howa=
rd Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On Aug 26, 2013, at 8:58 PM, Zhihao Yuan <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"8FOovpnGUh0J">z...@miator.net</a>&=
gt; wrote:
<br>
<br>> Ah, I see... We should be able to specialize iterator_traits to un=
block
<br>> proxy iterators...
<br>
<br>And actually we already have done this for input iterators and output i=
terators. We just have this legacy requirement hanging around that fo=
rward iterators (and bi and rand) must return a value_type& from operat=
or*() (const value_type& for non-mutable variants). The T& re=
turn from forward iterator operator*() is kind of like dandelions. It=
kind of looks pretty. And it is very hard to get rid of. :-) B=
ut I think we should make an effort to do so.
<br></blockquote><div><br>Amen brother. Fleshing out the generic semantics =
will clean a mess that trying to scrub out details will only worsen. And pr=
ogress forward rather than trip over trying to run backwards.<br><br>But th=
e cleanup should extend into allocators as well. The allocator supplies the=
mapping (Allocator::address) from Iterator::reference to Iterator::pointer=
..<br><br>Conceptually, packing bits is an optimization of allocation. Aside=
from special functions like vector<bool>::flip, vector<bool> s=
houldn't need to be a specialization at all. With appropriately generic add=
ress arithmetic, and concepts to enable the special members, std::vector<=
;bool> could be the generic instantiation of std::vector< bool, bitpa=
cking_allocator >. Then std::deque could benefit from the same optimized=
algorithms, because its node and iterator classes would have internal bit-=
pointers.<br><br>The default allocator type argument of std::vector would b=
e an alias template to select either std::allocator<T> or std::bitpac=
king_allocator. Users who want the non-packed functionality would explicitl=
y specify std::allocator<T>. Migration would be reduced to deprecatin=
g that alias template.<br><br>Properly generic iterators/allocators should =
also allow range access to files, or if you prefer, user-space virtual memo=
ry. Interleaved arrays would be another application. I think we're missing =
out on a lot.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_61_9520664.1377568488583--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 26 Aug 2013 23:38:31 -0700 (PDT)
Raw View
------=_Part_261_22711007.1377585511598
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 4:18:07 PM UTC-7, Zhihao Yuan wrote:
>
> On Mon, Aug 26, 2013 at 7:10 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > `bit_vector` can do whatever it wants, because it's not a real vector.
> It
> > can spit out "pseudo-iterators". It can do whatever. It can have the
> > interface it has, and nobody has any explicit expectations that this
> > interface matches that of the containers as defined by chapter 23.
>
> So you mean it's Okey for bitvector's begin() to produce an
> object which can be used in any STL algorithms but such an object
> fits into no iterator categories? Don't you think that's an anti-pattern
> of STL design?
>
No. Because it is not defined in accord with the requirements of the
container concepts, it can do whatever it wants. Including look enough like
a container to pass as one. Sometimes.
If you want to go through and change the iterator concepts to make it
actually be a legitimate container, fine. But that shouldn't be a *
requirement* for starting us the process of getting a real `vector<bool>`
that's a real `vector` of real `bool`. And that process requires us to
provide a drop-in replacement of the current class.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_261_22711007.1377585511598
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 26, 2013 4:18:07 PM UTC-7, Zhihao Yuan w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Aug 26, 2013 at 7=
:10 PM, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"5sw8y2aNJI0J">jmck...@gmail.com</a>> wrote:
<br>> `bit_vector` can do whatever it wants, because it's not a real vec=
tor. It
<br>> can spit out "pseudo-iterators". It can do whatever. It can have t=
he
<br>> interface it has, and nobody has any explicit expectations that th=
is
<br>> interface matches that of the containers as defined by chapter 23.
<br>
<br>So you mean it's Okey for bitvector's begin() to produce an
<br>object which can be used in any STL algorithms but such an object
<br>fits into no iterator categories? Don't you think that's an anti-=
pattern
<br>of STL design?<br></blockquote><div><br>No. Because it is not defined i=
n accord with the requirements of the container concepts, it can do whateve=
r it wants. Including look enough like a container to pass as one. Sometime=
s.<br><br>If you want to go through and change the iterator concepts to mak=
e it actually be a legitimate container, fine. But that shouldn't be a <i>r=
equirement</i> for starting us the process of getting a real `vector<boo=
l>` that's a real `vector` of real `bool`. And that process requires us =
to provide a drop-in replacement of the current class.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_261_22711007.1377585511598--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 27 Aug 2013 11:43:33 +0200
Raw View
Zhihao Yuan skrev 2013-08-27 01:57:
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>> Question for Zhihao:
>>
>> Why does forward iterator's operator*() have to return a value_type& ?
>>
>> I'm well aware that this is what C++98/03/11 requires. That's not what I'm asking. I'm asking what is the benefit of this requirement in the C++1y context? What problem does this requirement solve?
> Afaics, it makes the pointed object modifiable. And move_iterator
> significantly benefits from it. (Here is something I'm not sure:
> move_iterator requires only InputIterator, while dereferencing an
> InputIterator may return anything convertible to T -- is there anything
> broken here?)
>
No, he must be refering to something else, as the return value of
vector<bool>::iterator::operator* does indeed make the pointed object
modifiable.
I don't like when people speak in riddles to make other people feel like
idiots! Please instead try to explain the issue at hand as clearly as
you can.
The prime example I have been given of the badness of the vector<bool>
specialization is that it does not have a .data() method. So be it, but
in what case is using .data() preferred to using iterators?
The other problem was that some stl algorithms are very slow when the
input iterators are for vector<bool>, but when I suggest a simple
solution that would instead make them faster than their counterparts it
is immediately shot down for not being orthogonal enough.
I don't really see the relevance of the argument that "anyone who needs
a denser vector<bool> than the unspecialized one can always use
bit_vector". This ASSUMES that programmers that make very simple use of
a vector of bits aware of this new, later added class. At the same time
the reason for getting rid of the specialized vector<bool> seems to be
that we CAN'T ASSUME that programmers who are doing rather more complex
programming know that vector<bool> is special, even though this is
already pointed out in current textbooks.
I do think that the specialization was a mistake from the beginning, but
I think that we should move on with an apology and concentrate on making
it perform as expected from a packed representation, which requires the
API I mentioned before. Also I think that the suggestion to remove it
would never pass the committe scrutinization.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 27 Aug 2013 10:12:41 -0500
Raw View
--047d7b5daca056621404e4ef5097
Content-Type: text/plain; charset=ISO-8859-1
On 27 August 2013 04:43, Bengt Gustafsson <bengt.gustafsson@beamways.com>wrote:
>
>
> I do think that the specialization was a mistake from the beginning, but I
> think that we should move on with an apology and concentrate on making it
> perform as expected from a packed representation, which requires the API I
> mentioned before. Also I think that the suggestion to remove it would never
> pass the committe scrutinization.
Looking at the people involved in this discussion, it seems more likely to
me that the committee would be willing to remove it in the future than
expand the incompatibility. Note: we are all individuals, and while some
of us are on the committee, none of us speak for the committee.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--047d7b5daca056621404e4ef5097
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 27 August 2013 04:43, Bengt =
Gustafsson <span dir=3D"ltr"><<a href=3D"mailto:bengt.gustafsson@beamway=
s.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>></span> wrote=
:<br><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>
I do think that the specialization was a mistake from the beginning, but I =
think that we should move on with an apology and concentrate on making it p=
erform as expected from a packed representation, which requires the API I m=
entioned before. Also I think that the suggestion to remove it would never =
pass the committe scrutinization.</blockquote>
<div><br></div><div>Looking at the people involved in this discussion, it s=
eems more likely to me that the committee would be willing to remove it in =
the future than expand the incompatibility. =A0Note: =A0we are all individu=
als, and while some of us are on the committee, none of us speak for the co=
mmittee.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5daca056621404e4ef5097--
.
Author: Geoffrey Romer <gromer@google.com>
Date: Tue, 27 Aug 2013 09:12:16 -0700
Raw View
--047d7b60457ced179c04e4f02263
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Aug 26, 2013 at 5:36 PM, Howard Hinnant <howard.hinnant@gmail.com>wrote:
> On Aug 26, 2013, at 8:28 PM, Zhihao Yuan <zy@miator.net> wrote:
>
> > On Mon, Aug 26, 2013 at 8:16 PM, Geoffrey Romer <gromer@google.com>
> wrote:
> >> template <typename iter_t>
> >> value_type& GetValue(iter_t iter) {
> >> return *iter;
> >> }
> >
> > I think this can be "corrected" by just replacing the return type
> > with `auto` :(
>
> I was going to suggest:
>
> typename std::iterator_traits<iter_t>::reference
>
> but I like Zhihao's suggestion a lot better. Unless you need the
> iterator_traits dance for SFINAE purposes.
>
> Bottom line: All we have to do is stop assuming that *iter returns a
> value_type&. We already can not assume that for input iterators, do this
> does not seem like a big stretch. And we already can not assume it for
> output iterators, even though we can use output iterators to modify values.
>
Yes, it's _possible_ to rewrite that code so that it works with a proxy.
I'm just saying that it's _harder_ to write correct code against a proxying
iterator than against a non-proxying one. It's true that "all we have to do
is stop assuming that *iter returns a value_type&", but the "we" here
refers to all C++ programmers, so this is not a small thing, and undefined
behavior is a pretty harsh punishment for those who fail to update
themselves appropriately.
Now, sometimes you need a proxying iterator, because returning value_type&
just isn't possible. That being the case, it's certainly preferable for
such iterators to be a supported part of the iterator framework, and it's
certainly desirable for them to be able to describe themselves accurately
(e.g. vector<bool>::iterator supports random access, but can't return a
value_type&), so I am wholly in favor of decomposing the iterator
categories to describe value-access separately from traversal (along the
lines of n1640), and relaxing the iterator requirements of the standard
algorithms as much as possible.
What I don't want is for the STL container requirements to allow proxying
iterators or, still worse, for the standard iterator concepts to permit
proxying unconditionally. This would render some existing code incorrect,
and worse, it would be incorrect in a subtle way that would probably work
most of the time, because in practice the STL containers are unlikely to
use proxying, so there may be a long lag between when the bug is written
and when it is discovered.
>
> Howard
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email 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/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--047d7b60457ced179c04e4f02263
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Mon, Aug 26, 2013 at 5:36 PM, Howard Hinnant <span dir=3D"ltr"><<a hr=
ef=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnant@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Aug 26, 2013, at 8:28 PM, Zhihao Yuan=
<<a href=3D"mailto:zy@miator.net">zy@miator.net</a>> wrote:<br>
<br>
> On Mon, Aug 26, 2013 at 8:16 PM, Geoffrey Romer <<a href=3D"mailto:=
gromer@google.com">gromer@google.com</a>> wrote:<br>
>> template <typename iter_t><br>
>> value_type& GetValue(iter_t iter) {<br>
>> =A0return *iter;<br>
>> }<br>
><br>
> I think this can be "corrected" by just replacing the return=
type<br>
> with `auto` :(<br>
<br>
</div>I was going to suggest:<br>
<br>
typename std::iterator_traits<iter_t>::reference<br>
<br>
but I like Zhihao's suggestion a lot better. =A0Unless you need the ite=
rator_traits dance for SFINAE purposes.<br>
<br>
Bottom line: =A0All we have to do is stop assuming that *iter returns a val=
ue_type&. =A0We already can not assume that for input iterators, do thi=
s does not seem like a big stretch. =A0And we already can not assume it for=
output iterators, even though we can use output iterators to modify values=
..<br>
</blockquote><div><br></div><div>Yes, it's _possible_ to rewrite that c=
ode so that it works with a proxy. I'm just saying that it's _harde=
r_ to write correct code against a proxying iterator than against a non-pro=
xying one. It's true that "all we have to do is stop assuming that=
*iter returns a value_type&", but the "we" here refers =
to all C++ programmers, so this is not a small thing, and undefined behavio=
r is a pretty harsh punishment for those who fail to update themselves appr=
opriately.</div>
<div><br></div><div>Now, sometimes you need a proxying iterator, because re=
turning value_type& just isn't possible. That being the case, it=
9;s certainly preferable for such iterators to be a supported part of the i=
terator framework, and it's certainly desirable for them to be able to =
describe themselves accurately (e.g. vector<bool>::iterator supports =
random access, but can't return a value_type&), so I am wholly in f=
avor of decomposing the iterator categories to describe value-access separa=
tely from traversal (along the lines of n1640), and relaxing the iterator r=
equirements of the standard algorithms as much as possible.</div>
<div><br></div><div>What I don't want is for the STL container requirem=
ents to allow proxying iterators or, still worse, for the standard iterator=
concepts to permit proxying unconditionally. This would render some existi=
ng code incorrect, and worse, it would be incorrect in a subtle way that wo=
uld probably work most of the time, because in practice the STL containers =
are unlikely to use proxying, so there may be a long lag between when the b=
ug is written and when it is discovered.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<span class=3D""><font color=3D"#888888"><br>
Howard<br>
</font></span><div class=3D""><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b60457ced179c04e4f02263--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 27 Aug 2013 16:17:25 -0700 (PDT)
Raw View
------=_Part_14_24552669.1377645445978
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson wrote:
>
>
> Zhihao Yuan skrev 2013-08-27 01:57:
> > On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> > <howard....@gmail.com <javascript:>> wrote:
> >> Question for Zhihao:
> >>
> >> Why does forward iterator's operator*() have to return a value_type& ?
> >>
> >> I'm well aware that this is what C++98/03/11 requires. That's not what
> I'm asking. I'm asking what is the benefit of this requirement in the
> C++1y context? What problem does this requirement solve?
> > Afaics, it makes the pointed object modifiable. And move_iterator
> > significantly benefits from it. (Here is something I'm not sure:
> > move_iterator requires only InputIterator, while dereferencing an
> > InputIterator may return anything convertible to T -- is there anything
> > broken here?)
> >
> No, he must be refering to something else, as the return value of
> vector<bool>::iterator::operator* does indeed make the pointed object
> modifiable.
>
> I don't like when people speak in riddles to make other people feel like
> idiots! Please instead try to explain the issue at hand as clearly as
> you can.
>
> The prime example I have been given of the badness of the vector<bool>
> specialization is that it does not have a .data() method. So be it, but
> in what case is using .data() preferred to using iterators?
>
Because it's part of std::vector's interface. std::vector *requires* that
this code works:
vector<T> t{...};
T* tp = &t[0];
tp += 3;
*tp == t[3];
And that will work for all T... so long as T is not `bool`.
It is not for you to decide whether this is good code or not. That's the
interface that `vector` provides by the standard, and that is the interface
that we should expect to have. And we do... as long as T is not `bool`.
There is no reason why this should be the case. A space-optimized object
can be used separately.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_14_24552669.1377645445978
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Beng=
t Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Zhihao Yuan skrev 2013-08-27 01:57:
<br>> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
<br>> <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Mz1mbb_j3g8J">howard....@gmail.com</a>> wrote:
<br>>> Question for Zhihao:
<br>>>
<br>>> Why does forward iterator's operator*() have to return a value=
_type& ?
<br>>>
<br>>> I'm well aware that this is what C++98/03/11 requires. T=
hat's not what I'm asking. I'm asking what is the benefit of this req=
uirement in the C++1y context? What problem does this requirement sol=
ve?
<br>> Afaics, it makes the pointed object modifiable. And move_ite=
rator
<br>> significantly benefits from it. (Here is something I'm not s=
ure:
<br>> move_iterator requires only InputIterator, while dereferencing an
<br>> InputIterator may return anything convertible to T -- is there any=
thing
<br>> broken here?)
<br>>
<br>No, he must be refering to something else, as the return value of=20
<br>vector<bool>::iterator::<wbr>operator* does indeed make the point=
ed object=20
<br>modifiable.
<br>
<br>I don't like when people speak in riddles to make other people feel lik=
e=20
<br>idiots! Please instead try to explain the issue at hand as clearly as=
=20
<br>you can.
<br>
<br>The prime example I have been given of the badness of the vector<boo=
l>=20
<br>specialization is that it does not have a .data() method. So be it, but=
=20
<br>in what case is using .data() preferred to using iterators?<br></blockq=
uote><div><br>Because it's part of std::vector's interface. std::vector *re=
quires* that this code works:<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> tp </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">];<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>tp </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">tp </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">];</span></div></code>=
</div><br>And that will work for all T... so long as T is not `bool`.<br><b=
r>It is not for you to decide whether this is good code or not. That's the =
interface that `vector` provides by the standard, and that is the interface=
that we should expect to have. And we do... as long as T is not `bool`.<br=
><br>There is no reason why this should be the case. A space-optimized obje=
ct can be used separately.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_14_24552669.1377645445978--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 27 Aug 2013 20:15:59 -0500
Raw View
--047d7b5daca0cd4e7504e4f7bd9f
Content-Type: text/plain; charset=ISO-8859-1
On 27 August 2013 18:17, Nicol Bolas <jmckesson@gmail.com> wrote:
> Because it's part of std::vector's interface. std::vector *requires* that
> this code works:
>
> vector<T> t{...};
> T* tp = &t[0];
> tp += 3;
> *tp == t[3];
>
> And that will work for all T... so long as T is not `bool`.
>
> It is not for you to decide whether this is good code or not.
>
And even of people don't like that code, surely the following is reasonable:
void DoSomething(bool& flag) { /* ... */ }
DoSomething(t[3]);
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--047d7b5daca0cd4e7504e4f7bd9f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 27 August 2013 18:17, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailt=
o:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Because it's part of std::vector=
9;s interface. std::vector *requires* that this code works:<br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word">
<code><div><span style>vector</span><span style=3D"color:#660"><</span><=
span style>T</span><span style=3D"color:#660">></span><span style> t</sp=
an><span style=3D"color:#660">{...};</span><span style><br>T</span><span st=
yle=3D"color:#660">*</span><span style> tp </span><span style=3D"color:#660=
">=3D</span><span style> </span><span style=3D"color:#660">&</span><spa=
n style>t</span><span style=3D"color:#660">[</span><span style=3D"color:#06=
6">0</span><span style=3D"color:#660">];</span><span style><br>
tp </span><span style=3D"color:#660">+=3D</span><span style> </span><span s=
tyle=3D"color:#066">3</span><span style=3D"color:#660">;</span><span style>=
<br></span><span style=3D"color:#660">*</span><span style>tp </span><span s=
tyle=3D"color:#660">=3D=3D</span><span style> t</span><span style=3D"color:=
#660">[</span><span style=3D"color:#066">3</span><span style=3D"color:#660"=
>];</span></div>
</code></div><br>And that will work for all T... so long as T is not `bool`=
..<br><br>It is not for you to decide whether this is good code or not. </di=
v></blockquote><div><br></div><div>And even of people don't like that c=
ode, surely the following is reasonable:</div>
<div><br></div><div>void DoSomething(bool& flag) { /* ... */ }</div><di=
v><br></div><div>DoSomething(t[3]);</div><div>--=A0<br></div></div>=A0Nevin=
":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5daca0cd4e7504e4f7bd9f--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 28 Aug 2013 09:27:38 +0200
Raw View
This is a multi-part message in MIME format.
--------------090301070808090304050208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Nicol Bolas skrev 2013-08-28 01:17:
>
>
> On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson wrote:
>
>
> Zhihao Yuan skrev 2013-08-27 01:57:
> > On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
> > <howard....@gmail.com <javascript:>> wrote:
> >> Question for Zhihao:
> >>
> >> Why does forward iterator's operator*() have to return a
> value_type& ?
> >>
> >> I'm well aware that this is what C++98/03/11 requires. That's
> not what I'm asking. I'm asking what is the benefit of this
> requirement in the C++1y context? What problem does this
> requirement solve?
> > Afaics, it makes the pointed object modifiable. And move_iterator
> > significantly benefits from it. (Here is something I'm not sure:
> > move_iterator requires only InputIterator, while dereferencing an
> > InputIterator may return anything convertible to T -- is there
> anything
> > broken here?)
> >
> No, he must be refering to something else, as the return value of
> vector<bool>::iterator::operator* does indeed make the pointed object
> modifiable.
>
> I don't like when people speak in riddles to make other people
> feel like
> idiots! Please instead try to explain the issue at hand as clearly as
> you can.
>
> The prime example I have been given of the badness of the
> vector<bool>
> specialization is that it does not have a .data() method. So be
> it, but
> in what case is using .data() preferred to using iterators?
>
>
> Because it's part of std::vector's interface. std::vector *requires*=20
> that this code works:
>
> |
> vector<T>t{...};
> T*tp =3D&t[0];
> tp +=3D3;
> *tp =3D=3Dt[3];
> |
>
> And that will work for all T... so long as T is not `bool`.
>
> It is not for you to decide whether this is good code or not. That's=20
> the interface that `vector` provides by the standard, and that is the=20
> interface that we should expect to have. And we do... as long as T is=20
> not `bool`.
>
No, the standard says exactly what the standard says: The code above=20
should work for all T except bool. There is a special clause in the=20
standard detailing that vector<bool> is to be specialized to NOT work as=20
you claim. That's what we are discussing here, isn't it? You can claim=20
that we should change the standard because it is inconsistent or=20
confusing but can NOT claim that we should change the standard because=20
it contradicts itself!
Personally I am indifferent, as I don't use vector<bool>. But I don't=20
want the standard to be changed under the feet of people, and I dislike=20
that more than it being clumsy as it is. In addition I think that C++=20
should focus on being an outstanding performer, which is why I suggested=20
to include APIs to allow fast implementations of algorithms in a=20
portable way.
> There is no reason why this should be the case. A space-optimized=20
> object can be used separately.
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
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-proposa=
ls/.
--------------090301070808090304050208
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">Nicol Bolas skrev 2013-08-28 01:17:<br>
</div>
<blockquote
cite="mid:a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org"
type="cite">
<div dir="ltr"><br>
<br>
On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson
wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
Zhihao Yuan skrev 2013-08-27 01:57:
<br>
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
<br>
> <<a moz-do-not-send="true" href="javascript:"
target="_blank" gdf-obfuscated-mailto="Mz1mbb_j3g8J">howard....@gmail.com</a>>
wrote:
<br>
>> Question for Zhihao:
<br>
>>
<br>
>> Why does forward iterator's operator*() have to
return a value_type& ?
<br>
>>
<br>
>> I'm well aware that this is what C++98/03/11
requires. That's not what I'm asking. I'm asking what is the
benefit of this requirement in the C++1y context? What
problem does this requirement solve?
<br>
> Afaics, it makes the pointed object modifiable. And
move_iterator
<br>
> significantly benefits from it. (Here is something I'm
not sure:
<br>
> move_iterator requires only InputIterator, while
dereferencing an
<br>
> InputIterator may return anything convertible to T -- is
there anything
<br>
> broken here?)
<br>
>
<br>
No, he must be refering to something else, as the return value
of <br>
vector<bool>::iterator::<wbr>operator* does indeed make
the pointed object <br>
modifiable.
<br>
<br>
I don't like when people speak in riddles to make other people
feel like <br>
idiots! Please instead try to explain the issue at hand as
clearly as <br>
you can.
<br>
<br>
The prime example I have been given of the badness of the
vector<bool> <br>
specialization is that it does not have a .data() method. So
be it, but <br>
in what case is using .data() preferred to using iterators?<br>
</blockquote>
<div><br>
Because it's part of std::vector's interface. std::vector
*requires* that this code works:<br>
<br>
<div class="prettyprint" style="background-color: rgb(250,
250, 250); border-color: rgb(187, 187, 187); border-style:
solid; border-width: 1px; word-wrap: break-word;"><code
class="prettyprint">
<div class="subprettyprint"><span style="color: #000;"
class="styled-by-prettify">vector</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #000;" class="styled-by-prettify">T</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="color: #000;" class="styled-by-prettify"> t</span><span
style="color: #660;" class="styled-by-prettify">{...};</span><span
style="color: #000;" class="styled-by-prettify"><br>
T</span><span style="color: #660;"
class="styled-by-prettify">*</span><span style="color:
#000;" class="styled-by-prettify"> tp </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">&</span><span
style="color: #000;" class="styled-by-prettify">t</span><span
style="color: #660;" class="styled-by-prettify">[</span><span
style="color: #066;" class="styled-by-prettify">0</span><span
style="color: #660;" class="styled-by-prettify">];</span><span
style="color: #000;" class="styled-by-prettify"><br>
tp </span><span style="color: #660;"
class="styled-by-prettify">+=</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #066;" class="styled-by-prettify">3</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #660;"
class="styled-by-prettify">*</span><span style="color:
#000;" class="styled-by-prettify">tp </span><span
style="color: #660;" class="styled-by-prettify">==</span><span
style="color: #000;" class="styled-by-prettify"> t</span><span
style="color: #660;" class="styled-by-prettify">[</span><span
style="color: #066;" class="styled-by-prettify">3</span><span
style="color: #660;" class="styled-by-prettify">];</span></div>
</code></div>
<br>
And that will work for all T... so long as T is not `bool`.<br>
<br>
It is not for you to decide whether this is good code or not.
That's the interface that `vector` provides by the standard,
and that is the interface that we should expect to have. And
we do... as long as T is not `bool`.<br>
<br>
</div>
</div>
</blockquote>
No, the standard says exactly what the standard says: The code above
should work for all T except bool. There is a special clause in the
standard detailing that vector<bool> is to be specialized to
NOT work as you claim. That's what we are discussing here, isn't it?
You can claim that we should change the standard because it is
inconsistent or confusing but can NOT claim that we should change
the standard because it contradicts itself!<br>
<br>
Personally I am indifferent, as I don't use vector<bool>. But
I don't want the standard to be changed under the feet of people,
and I dislike that more than it being clumsy as it is. In addition I
think that C++ should focus on being an outstanding performer, which
is why I suggested to include APIs to allow fast implementations of
algorithms in a portable way.<br>
<br>
<blockquote
cite="mid:a65969ec-169a-474a-8770-318c57da6a2c@isocpp.org"
type="cite">
<div dir="ltr">
<div>There is no reason why this should be the case. A
space-optimized object can be used separately.<br>
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a class="moz-txt-link-abbreviated" href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Linköping, Sweden
+46 13 465 10 85
<a class="moz-txt-link-abbreviated" href="http://www.beamways.com">www.beamways.com</a>
</pre>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090301070808090304050208--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 28 Aug 2013 09:29:47 -0500
Raw View
--089e0149528ea62a3a04e502d4cd
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 02:27, Bengt Gustafsson <bengt.gustafsson@beamways.com>wrote:
>
>
> Personally I am indifferent, as I don't use vector<bool>. But I don't want
> the standard to be changed under the feet of people,
>
So we should never deprecate and remove *anything?* It isn't like it would
go away before C++20 (at least).
In addition I think that C++ should focus on being an outstanding
> performer, which is why I suggested to include APIs to allow fast
> implementations of algorithms in a portable way.
>
Even if you get your wish, there is still no need to make vector<bool>
diverge more than it already does from vector<T>. The even better
bit-packed data structure does not have to be called vector<bool>.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
--089e0149528ea62a3a04e502d4cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 28 August 2013 02:27, Bengt Gustafsson <span dir=3D"ltr=
"><<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">be=
ngt.gustafsson@beamways.com</a>></span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br><br>
Personally I am indifferent, as I don't use vector<bool>. But
I don't want the standard to be changed under the feet of people,</=
div></blockquote><div><br></div><div>So we should never deprecate and remov=
e <i>anything?</i>=A0 It isn't like it would go away before C++20 (at l=
east).<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=3D"=
#FFFFFF">=A0 In addition I
think that C++ should focus on being an outstanding performer, which
is why I suggested to include APIs to allow fast implementations of
algorithms in a portable way.</div></blockquote><div><br></div><div>Eve=
n if you get your wish, there is still no need to make vector<bool> d=
iverge more than it already does from vector<T>.=A0 The even better b=
it-packed data structure does not have to be called vector<bool>.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0149528ea62a3a04e502d4cd--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Aug 2013 15:32:17 -0700 (PDT)
Raw View
------=_Part_1586_16791137.1377729137499
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, August 28, 2013 12:27:38 AM UTC-7, Bengt Gustafsson wrote:
>
>
> Nicol Bolas skrev 2013-08-28 01:17:
>
>
>
> On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson wrote:
>>
>>
>> Zhihao Yuan skrev 2013-08-27 01:57:
>> > On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
>> > <howard....@gmail.com> wrote:
>> >> Question for Zhihao:
>> >>
>> >> Why does forward iterator's operator*() have to return a value_type& ?
>> >>
>> >> I'm well aware that this is what C++98/03/11 requires. That's not
>> what I'm asking. I'm asking what is the benefit of this requirement in the
>> C++1y context? What problem does this requirement solve?
>> > Afaics, it makes the pointed object modifiable. And move_iterator
>> > significantly benefits from it. (Here is something I'm not sure:
>> > move_iterator requires only InputIterator, while dereferencing an
>> > InputIterator may return anything convertible to T -- is there anything
>> > broken here?)
>> >
>> No, he must be refering to something else, as the return value of
>> vector<bool>::iterator::operator* does indeed make the pointed object
>> modifiable.
>>
>> I don't like when people speak in riddles to make other people feel like
>> idiots! Please instead try to explain the issue at hand as clearly as
>> you can.
>>
>> The prime example I have been given of the badness of the vector<bool>
>> specialization is that it does not have a .data() method. So be it, but
>> in what case is using .data() preferred to using iterators?
>>
>
> Because it's part of std::vector's interface. std::vector *requires* that
> this code works:
>
> vector<T> t{...};
> T* tp = &t[0];
> tp += 3;
> *tp == t[3];
>
> And that will work for all T... so long as T is not `bool`.
>
> It is not for you to decide whether this is good code or not. That's the
> interface that `vector` provides by the standard, and that is the interface
> that we should expect to have. And we do... as long as T is not `bool`.
>
> No, the standard says exactly what the standard says: The code above
> should work for all T except bool. There is a special clause in the
> standard detailing that vector<bool> is to be specialized to NOT work as
> you claim. That's what we are discussing here, isn't it? You can claim that
> we should change the standard because it is inconsistent or confusing but
> can NOT claim that we should change the standard because it contradicts
> itself!
>
Which is good because I never said *anything* about contradicting itself.
You asked for someone to "explain the issue at hand", and I did.
`vector<bool>` does not behave like a `vector` and it *should*. That's the
issue at hand.
Personally I am indifferent, as I don't use vector<bool>. But I don't want
> the standard to be changed under the feet of people, and I dislike that
> more than it being clumsy as it is.
>
Have you read anything in this thread? The plan for changing this is to add
a drop-in class that provides the same interface, so that people can simply
find/replace within their code. Then we deprecate the `vector<bool>`
specialization. It will still be there for at least one version alongside
the stand-alone class. That way, everyone has several years and version
releases to do that find/replace within their code to use the new class
rather than `vector<bool>`.
And then we cut out the `vector<bool>` specialization. Nobody is suggesting
that it be changed "under the feet of people".
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email 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/.
------=_Part_1586_16791137.1377729137499
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 28, 2013 12:27:38 AM UTC-7, B=
engt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<div>Nicol Bolas skrev 2013-08-28 01:17:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Tuesday, August 27, 2013 2:43:33 AM UTC-7, Bengt Gustafsson
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Zhihao Yuan skrev 2013-08-27 01:57:
<br>
> On Mon, Aug 26, 2013 at 7:22 PM, Howard Hinnant
<br>
> <<a>howard....@gmail.com</a>>
wrote:
<br>
>> Question for Zhihao:
<br>
>>
<br>
>> Why does forward iterator's operator*() have to
return a value_type& ?
<br>
>>
<br>
>> I'm well aware that this is what C++98/03/11
requires. That's not what I'm asking. I'm asking what=
is the
benefit of this requirement in the C++1y context? What
problem does this requirement solve?
<br>
> Afaics, it makes the pointed object modifiable. And
move_iterator
<br>
> significantly benefits from it. (Here is something I'm
not sure:
<br>
> move_iterator requires only InputIterator, while
dereferencing an
<br>
> InputIterator may return anything convertible to T -- is
there anything
<br>
> broken here?)
<br>
>
<br>
No, he must be refering to something else, as the return value
of <br>
vector<bool>::iterator::<wbr>operator* does indeed make
the pointed object <br>
modifiable.
<br>
<br>
I don't like when people speak in riddles to make other people
feel like <br>
idiots! Please instead try to explain the issue at hand as
clearly as <br>
you can.
<br>
<br>
The prime example I have been given of the badness of the
vector<bool> <br>
specialization is that it does not have a .data() method. So
be it, but <br>
in what case is using .data() preferred to using iterators?<br>
</blockquote>
<div><br>
Because it's part of std::vector's interface. std::vector
*requires* that this code works:<br>
<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e>
<div><span style=3D"color:#000">vector</span><span style=3D"c=
olor:#660"><</span><span style=3D"color:#000">T</span><span style=3D"col=
or:#660">></span><span style=3D"color:#000"> t</span><span style=3D"colo=
r:#660">{...};</span><span style=3D"color:#000"><br>
T</span><span style=3D"color:#660">*</span><span style=3D=
"color:#000"> tp </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">&</span><span style=3D"=
color:#000">t</span><span style=3D"color:#660">[</span><span style=3D"color=
:#066">0</span><span style=3D"color:#660">];</span><span style=3D"color:#00=
0"><br>
tp </span><span style=3D"color:#660">+=3D</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#066">3</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#660">*</span><span style=3D"co=
lor:#000">tp </span><span style=3D"color:#660">=3D=3D</span><span style=3D"=
color:#000"> t</span><span style=3D"color:#660">[</span><span style=3D"colo=
r:#066">3</span><span style=3D"color:#660">];</span></div>
</code></div>
<br>
And that will work for all T... so long as T is not `bool`.<br>
<br>
It is not for you to decide whether this is good code or not.
That's the interface that `vector` provides by the standard,
and that is the interface that we should expect to have. And
we do... as long as T is not `bool`.<br>
<br>
</div>
</div>
</blockquote>
No, the standard says exactly what the standard says: The code above
should work for all T except bool. There is a special clause in the
standard detailing that vector<bool> is to be specialized to
NOT work as you claim. That's what we are discussing here, isn't it?
You can claim that we should change the standard because it is
inconsistent or confusing but can NOT claim that we should change
the standard because it contradicts itself!<br></div></blockquote><div>=
<br>Which is good because I never said <i>anything</i> about contradicting =
itself. You asked for someone to "explain the issue at hand", and I did. `v=
ector<bool>` does not behave like a `vector` and it <i>should</i>. Th=
at's the issue at hand.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
Personally I am indifferent, as I don't use vector<bool>. But
I don't want the standard to be changed under the feet of people,
and I dislike that more than it being clumsy as it is.</div></blockquot=
e><div><br>Have you read anything in this thread? The plan for changing thi=
s is to add a drop-in class that provides the same interface, so that peopl=
e can simply find/replace within their code. Then we deprecate the `vector&=
lt;bool>` specialization. It will still be there for at least one versio=
n alongside the stand-alone class. That way, everyone has several years and=
version releases to do that find/replace within their code to use the new =
class rather than `vector<bool>`.<br><br>And then we cut out the `vec=
tor<bool>` specialization. Nobody is suggesting that it be changed "u=
nder the feet of people".
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bg=
color=3D"#FFFFFF">
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1586_16791137.1377729137499--
.