Topic: Could we start a transition to bit_vector (and a
Author: Daryle Walker <darylew@gmail.com>
Date: Mon, 14 Oct 2013 09:16:49 -0700 (PDT)
Raw View
------=_Part_197_4019452.1381767409428
Content-Type: text/plain; charset=ISO-8859-1
template <class Allocator = allocator<bool>>
using bit_vector = vector<bool, Allocator>;
That could be added to the next published work that allows new items, so
maybe it could come before C++17. It could go right into a header synopsis
block, and have no explanation in prose. But that would mean we would have
to provide an explanation out of the blue when we swap it out for a real
class (template) when discontinuing the vector<bool> specialization.
Too bad we can't do:
template <class Allocator = allocator<bool>>
using bool_vector = vector<underlying_type_t<bool>, Allocator>;
for the reverse transition, but underlying_type only works for enums, not
any of the secondary integer types (AFAIK). And the chosen type would be a
mismatch when using bool arguments, returns, or iterator dereference. (Just
like char, signed char, and unsigned char are incompatible in this way
although they're all "strong" typedefs of each other.)
It still could be defined conventionally, though, including a prose block.
(Maybe it can secretly inherit, or otherwise borrow, from the theoretical vector
instantiation given above. Maybe with aligned_storage<sizeof(bool),
alignof(bool)> as the element type.) Then we swap it for a vector<bool>alias after the transition (and remove the prose).
Daryle W.
--
---
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_197_4019452.1381767409428
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">template</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Allocator</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
llocator</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&l=
t;bool></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: #008;" class=3D"styled-by-prettify">using</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> bit_vector </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">bool</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: #606;" class=3D"=
styled-by-prettify">Allocator</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></div></code></div><div><br></div><div>That could =
be added to the next published work that allows new items, so maybe it coul=
d come before C++17. It could go right into a header synopsis block, and ha=
ve no explanation in prose. But that would mean we would have to provide an=
explanation out of the blue when we swap it out for a real class (template=
) when discontinuing the <font face=3D"courier new, monospace">vector<bo=
ol></font> specialization.</div><div><br></div><div>Too bad we can't do:=
</div><div><br></div><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</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: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Allocator</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> allocator</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
><bool></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> bool_vector <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">underlying_type_t</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify"><bool></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Allocator</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><div><br></d=
iv><div>for the reverse transition, but <font face=3D"courier new, monospac=
e">underlying_type</font> only works for enums, not any of the secondary in=
teger types (AFAIK). And the chosen type would be a mismatch when using <fo=
nt face=3D"courier new, monospace">bool </font>arguments, returns, or itera=
tor dereference. (Just like <font face=3D"courier new, monospace">char</fon=
t>, <font face=3D"courier new, monospace">signed char</font>, and <font fac=
e=3D"courier new, monospace">unsigned char</font> are incompatible in this =
way although they're all "strong" <font face=3D"courier new, monospace">typ=
edef</font>s of each other.)</div><div><br></div><div>It still could be def=
ined conventionally, though, including a prose block. (Maybe it can secretl=
y inherit, or otherwise borrow, from the theoretical <font face=3D"cou=
rier new, monospace">vector </font>instantiation given above. Maybe with <f=
ont face=3D"courier new, monospace">aligned_storage<sizeof(bool), aligno=
f(bool)></font> as the element type.) Then we swap it for a <font face=
=3D"courier new, monospace">vector<bool></font> alias after the trans=
ition (and remove the prose).</div><div><br></div><div>Daryle W.</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_197_4019452.1381767409428--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 14 Oct 2013 11:33:52 -0500
Raw View
--047d7bb03d0ef5bab404e8b60ad4
Content-Type: text/plain; charset=ISO-8859-1
On 14 October 2013 11:16, Daryle Walker <darylew@gmail.com> wrote:
> template <class Allocator = allocator<bool>>
> using bit_vector = vector<bool, Allocator>;
>
> That could be added to the next published work that allows new items, so
> maybe it could come before C++17.
>
I don't see the point. It is extremely unlikely for vector<bool> to go
anywhere until there is a replacement class, and if we have the replacement
class, we don't need this using declaration.
If we have the replacement class, we have a decent chance of getting
vector<bool> deprecated (but not removed) in C++17.
--
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/.
--047d7bb03d0ef5bab404e8b60ad4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 14 October 2013 11:16, Daryle Walker <span dir=3D"ltr">=
<<a href=3D"mailto:darylew@gmail.com" target=3D"_blank">darylew@gmail.co=
m</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div style=3D"background-color:rgb(250,250,250);border:1px=
solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"col=
or:#008">template</span><span style> </span><span style=3D"color:#660"><=
</span><span style=3D"color:#008">class</span><span style> </span><span sty=
le=3D"color:#606">Allocator</span><span style> </span><span style=3D"color:=
#660">=3D</span><span style> allocator</span><span style=3D"color:#080"><=
;bool></span><span style=3D"color:#660">></span><span style><br>
</span><span style=3D"color:#008">using</span><span style> bit_vector </spa=
n><span style=3D"color:#660">=3D</span><span style> vector</span><span styl=
e=3D"color:#660"><</span><span style=3D"color:#008">bool</span><span sty=
le=3D"color:#660">,</span><span style> </span><span style=3D"color:#606">Al=
locator</span><span style=3D"color:#660">>;</span><span style><br>
</span></div></code></div><div><br></div><div>That could be added to the ne=
xt published work that allows new items, so maybe it could come before C++1=
7.</div></div></blockquote><div><br></div><div>I don't see the point.=
=A0 It is extremely unlikely for vector<bool> to go anywhere until th=
ere is a replacement class, and if we have the replacement class, we don=
9;t need this using declaration.<br>
<br></div><div>If we have the replacement class, we have a decent chance of=
getting vector<bool> deprecated (but not removed) in C++17.<br></div=
></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailt=
o: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 />
--047d7bb03d0ef5bab404e8b60ad4--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 14 Oct 2013 12:47:18 -0400
Raw View
On Mon, Oct 14, 2013 at 12:33 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> I don't see the point. It is extremely unlikely for vector<bool> to go
> anywhere until there is a replacement class, and if we have the replacement
> class, we don't need this using declaration.
>
> If we have the replacement class, we have a decent chance of getting
> vector<bool> deprecated (but not removed) in C++17.
Currently I have the class
https://github.com/lichray/bitvector (missing some vector-compatible methods)
But blocked by the iterator catalog change (per Daniel's idea).
I currently don't know how to more forward (and don't have time
to, actually).
--
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: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 14 Oct 2013 13:02:38 -0500
Raw View
--001a11c2cd28727e8f04e8b7484c
Content-Type: text/plain; charset=ISO-8859-1
On 14 October 2013 11:47, Zhihao Yuan <zy@miator.net> wrote:
>
> Currently I have the class
>
> https://github.com/lichray/bitvector (missing some vector-compatible
> methods)
>
> But blocked by the iterator catalog change (per Daniel's idea).
>
My advice would be to add the vector<bool>-compatible methods and typedefs
(it really needs to be a drop in replacement for vector<bool>), not wait
for the iterator catalog change (unless it already happened for C++14) and
submit a paper for Issaquah. If you could add algorithm improvements that
take advantage of bitvector, that would make an even better selling point.
Hopefully you can find the time...
--
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/.
--001a11c2cd28727e8f04e8b7484c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 14 October 2013 11:47, Zhihao Yuan <span dir=3D"ltr">&l=
t;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>><=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div class=3D"im"><br>
</div>Currently I have the class<br>
<br>
=A0 <a href=3D"https://github.com/lichray/bitvector" target=3D"_blank">http=
s://github.com/lichray/bitvector</a> (missing some vector-compatible method=
s)<br>
<br>
But blocked by the iterator catalog change (per Daniel's idea).<br></bl=
ockquote><div><br></div><div>My advice would be to add the vector<bool&g=
t;-compatible methods and typedefs (it really needs to be a drop in replace=
ment for vector<bool>), not wait for the iterator catalog change (unl=
ess it already happened for C++14) and submit a paper for Issaquah. If you =
could add algorithm improvements that take advantage of bitvector, that wou=
ld make an even better selling point.<br>
<br></div><div>Hopefully you can find the time...<br></div></div>-- <br>=A0=
Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverl=
ord.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 />
--001a11c2cd28727e8f04e8b7484c--
.
Author: rhalbersma@gmail.com
Date: Mon, 14 Oct 2013 12:13:39 -0700 (PDT)
Raw View
------=_Part_439_15430599.1381778019166
Content-Type: text/plain; charset=ISO-8859-1
On Monday, October 14, 2013 8:02:38 PM UTC+2, Nevin ":-)" Liber wrote:
> On 14 October 2013 11:47, Zhihao Yuan <z...@miator.net <javascript:>>wrote:
>
>>
>> Currently I have the class
>>
>> https://github.com/lichray/bitvector (missing some vector-compatible
>> methods)
>>
>> But blocked by the iterator catalog change (per Daniel's idea).
>>
>
> My advice would be to add the vector<bool>-compatible methods and typedefs
> (it really needs to be a drop in replacement for vector<bool>), not wait
> for the iterator catalog change (unless it already happened for C++14) and
> submit a paper for Issaquah. If you could add algorithm improvements that
> take advantage of bitvector, that would make an even better selling point.
>
> Hopefully you can find the time...
>
These algorithm improvements have been in libc++ for about a year now, ever
since Howard Hinnant blogged about it
http://isocpp.org/blog/2012/11/on-vectorbool
--
---
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_439_15430599.1381778019166
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Monday, October 14, 20=
13 8:02:38 PM UTC+2, Nevin ":-)" Liber wrote:</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On 14 October 2013 11:47, Zhih=
ao Yuan <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"SjH-iM9tO0UJ">z...@miator.net</a>></span> wrote:<b=
r><div><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>
</div>Currently I have the class<br>
<br>
<a href=3D"https://github.com/lichray/bitvector" target=3D"_blank">h=
ttps://github.com/lichray/<wbr>bitvector</a> (missing some vector-compatibl=
e methods)<br>
<br>
But blocked by the iterator catalog change (per Daniel's idea).<br></blockq=
uote><div><br></div><div>My advice would be to add the vector<bool>-c=
ompatible methods and typedefs (it really needs to be a drop in replacement=
for vector<bool>), not wait for the iterator catalog change (unless =
it already happened for C++14) and submit a paper for Issaquah. If you coul=
d add algorithm improvements that take advantage of bitvector, that would m=
ake an even better selling point.<br>
<br></div><div>Hopefully you can find the time...</div></div></div></div></=
blockquote><div><span style=3D"font-size: 13px;"><br></span></div><div><spa=
n style=3D"font-size: 13px;">These algorithm improvements have been in libc=
++ for about a year now, ever since Howard Hinnant blogged about it </=
span><a href=3D"http://isocpp.org/blog/2012/11/on-vectorbool" style=3D"font=
-size: 13px;">http://isocpp.org/blog/2012/11/on-vectorbool</a><br></div><di=
v><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_439_15430599.1381778019166--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 14 Oct 2013 15:51:20 -0400
Raw View
On Mon, Oct 14, 2013 at 2:02 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> My advice would be to add the vector<bool>-compatible methods and typedefs
> (it really needs to be a drop in replacement for vector<bool>),
Will do. The result interface is very likely to have some controversial
part (in my eyes), but that's why LEWG is there.
> not wait for
> the iterator catalog change (unless it already happened for C++14)
I usually don't like to design a "wrong" thing. But, OK...
> and
> submit a paper for Issaquah. If you could add algorithm improvements that
> take advantage of bitvector, that would make an even better selling point.
libc++ already have those algorithms, but how to let user be able
to write those algorithms become another problem. On the other
hand, since we probably going to see a bitwise operations in the
future, another choice can be to overload those operations for both
bitset and bitvector. Either way, in the paper, I guess we don't need
to do anything...
> Hopefully you can find the time...
Thanks, but probably not for Issaquah; the string formatting stuff
has a higher priority to me. If someone just exceptionally love writing
papers, I can help :)
--
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: Daryle Walker <darylew@gmail.com>
Date: Mon, 14 Oct 2013 15:05:53 -0700 (PDT)
Raw View
------=_Part_3430_15803068.1381788353494
Content-Type: text/plain; charset=ISO-8859-1
On Monday, October 14, 2013 12:33:52 PM UTC-4, Nevin ":-)" Liber wrote:
> On 14 October 2013 11:16, Daryle Walker <dar...@gmail.com <javascript:>>wrote:
>
>> template <class Allocator = allocator<bool>>
>> using bit_vector = vector<bool, Allocator>;
>>
>> That could be added to the next published work that allows new items, so
>> maybe it could come before C++17.
>>
>
> I don't see the point. It is extremely unlikely for vector<bool> to go
> anywhere until there is a replacement class, and if we have the replacement
> class, we don't need this using declaration.
>
> If we have the replacement class, we have a decent chance of getting
> vector<bool> deprecated (but not removed) in C++17.
>
It's part of a transition plan:
1. Create the bit_vector alias template for vector<bool> and a bool_vector
class template for what vector<bool> should have been.
2. (Optional) Encourage everyone to stop using vector<bool> directly for
one of the two new templates.
3. Create an actual bit_vector class template, remove vector<bool> as a
specialization, and change bool_vector to an alias of the altered
vector<bool>.
If you have been using one of the new types, your code shouldn't have
needed anything besides a recompile. There's at least one Standard work
between [1] and [3].
Daryle W.
--
---
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_3430_15803068.1381788353494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 14, 2013 12:33:52 PM UTC-4, Nevin ":-)"=
Liber wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On 14 October 2013 11:16, Daryle Walker <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"cTAN6hTgPu4J">d=
ar...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div style=3D"background-color:rgb(250,250,250);border:1px=
solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"col=
or:#008">template</span><span> </span><span style=3D"color:#660"><</span=
><span style=3D"color:#008">class</span><span> </span><span style=3D"color:=
#606">Allocator</span><span> </span><span style=3D"color:#660">=3D</span><s=
pan> allocator</span><span style=3D"color:#080"><bool></span><span st=
yle=3D"color:#660">></span><span><br>
</span><span style=3D"color:#008">using</span><span> bit_vector </span><spa=
n style=3D"color:#660">=3D</span><span> vector</span><span style=3D"color:#=
660"><</span><span style=3D"color:#008">bool</span><span style=3D"color:=
#660">,</span><span> </span><span style=3D"color:#606">Allocator</span><spa=
n style=3D"color:#660">>;</span><span><br>
</span></div></code></div><div><br></div><div>That could be added to the ne=
xt published work that allows new items, so maybe it could come before C++1=
7.</div></div></blockquote><div><br></div><div>I don't see the point. =
It is extremely unlikely for vector<bool> to go anywhere until there=
is a replacement class, and if we have the replacement class, we don't nee=
d this using declaration.<br>
<br></div><div>If we have the replacement class, we have a decent chance of=
getting vector<bool> deprecated (but not removed) in C++17.<br></div=
></div></div></div></blockquote><div><br></div><div>It's part of a transiti=
on plan:</div><div><ol><li>Create the <font face=3D"courier new, monospace"=
>bit_vector </font>alias template for <font face=3D"courier new, monospace"=
>vector<bool></font> and a <font face=3D"courier new, monospace">bool=
_vector </font>class template for what <font face=3D"courier new, monospace=
">vector<bool></font> should have been.<br></li><li>(Optional) Encour=
age everyone to stop using <font face=3D"courier new, monospace">vector<=
bool> </font>directly for one of the two new templates.</li><li>Create a=
n actual <font face=3D"courier new, monospace">bit_vector </font>class temp=
late, remove <font face=3D"courier new, monospace">vector<bool><=
/font> as a specialization, and change <font face=3D"courier new, mono=
space">bool_vector </font>to an alias of the altered <font face=3D"courier =
new, monospace">vector<bool></font>.</li></ol><span style=3D"line-hei=
ght: 17px;">If you have been using one of the new types, your code shouldn'=
t have needed anything besides a recompile. There's at least one Stan=
dard work between [1] and [3].</span></div><div><span style=3D"line-height:=
17px;"><br></span></div><div><span style=3D"line-height: 17px;">Daryle W.<=
/span></div><div><span style=3D"line-height: 17px;"><br></span></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_3430_15803068.1381788353494--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 14 Oct 2013 16:12:22 -0700
Raw View
On segunda-feira, 14 de outubro de 2013 15:05:53, Daryle Walker wrote:
> It's part of a transition plan:
>
> 1. Create the bit_vector alias template for vector<bool> and a
> bool_vector class template for what vector<bool> should have been.
> 2. (Optional) Encourage everyone to stop using vector<bool> directly for
> one of the two new templates.
> 3. Create an actual bit_vector class template, remove vector<bool> as a
> specialization, and change bool_vector to an alias of the altered
> vector<bool>.
>
> If you have been using one of the new types, your code shouldn't have
> needed anything besides a recompile. There's at least one Standard work
> between [1] and [3].
You may want to review the API of bit_vector before step 1. By creating the
alias, you crystallise the current vector<bool> API, with no chance for
correcting mistakes in the future.
I also strongly advise against any implementation implementing bit_vector as
an alias or typedef. That would break ABI later when the actual class exists.
You may want to encourage the opposite instead:
1. create class bit_vector by copying the vector<bool> implementation
2. specialise vector<bool> by deriving from bit_vector:
template<> class [[deprecated]] vector<bool> : public bit_vector
{
public:
using bit_vector();
};
3. Later, in the future, remove the vector<bool> specialisation.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.