Topic: Views on a small_vector<T, N>?
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Sun, 3 Jan 2016 23:41:44 -0800 (PST)
Raw View
------=_Part_400_1558369814.1451893304266
Content-Type: multipart/alternative;
boundary="----=_Part_401_2136146707.1451893304266"
------=_Part_401_2136146707.1451893304266
Content-Type: text/plain; charset=UTF-8
*(tl;dr: We should have a vector which does the "small string
optimisation")*
*Overview*
It is sometimes the case that one needs to store items of a type T, where
the number of items will vary dynamically but it known that it will
(usually) be small. For example, consider an implementation of a sudoku
solver: the number of values which could possibly occupy a single square
will vary as the puzzle is solved, but in no case can it ever be more than
9. Or perhaps we have an algorithm which we know will usually require
temporary storage for 5 items, but in the worst case will require us to
store 99.
The standard library has two containers which could be used for such
purposes:
- std::array<T, N>
- std::vector<T>
Unfortunately, neither is perfectly suited to the task, for reasons given
below. What would be ideal is a hybrid container with the semantics of a
vector, but which preallocates a certain number of Ts on the stack, only
after which (if more elements are added) does it touch the heap -- in
essence, the small string optimisation for std::string, but applied to a
vector. Let's call such a container a small_vector<T, N>.
*Why not std::array?*
A std::array is a simple wrapper around a raw array. Its semantics are
quite different from those of a vector; it cannot grow, and its size is
fixed at compile time. There are many places where std::array is the right
choicel, but equally many places where it cannot be used.
*Why not std::vector?*
Unlike std::array, std::vector has the semantics we want -- that is, an
array with dynamic size. The downside is that in order to do this is needs
to use dynamic allocation. In some scenarios (for example creating and
destroying millions of tiny vectors) this can be extremely expensive. Where
the number of items will (usually) be small, we would much prefer to use
only the stack and not touch malloc().
*Okay, so why not std::vector with a stack allocator?*
With stateful allocators introduced C++11, it might be possible to store
some Ts inside the allocator itself, and overflow to a fallback allocator
once the local storage is exhausted. This would seem ideal, but
unfortunately there are two problems:
- It's not clear that this is permitted within the allocator rules as
they stand. I'm happy to defer to anyone with better knowledge, but my
understanding is that copies of allocators must compare equal, and this
does not seem to be possible if storage is embedded in the allocator
itself. Notably, Howard Hinnant's stack allocator uses a separate arena
which the user must provide.
- Embedding the preallocated array in the vector itself means that the
storage can overlap (i.e. in a union) with the standard three-pointer
implementation of a heap-allocated vector -- as is the case with the small
string optimisation for std::string. On the contrary, with a stack
allocator the array cannot overlap and will we always be using 3 words more
than necessary.
The latter point is particularly important as the speed of move operations
is be directly proportional to the sizeof the vector; using preallocated
storage will unavoidably make moves slower. We certainly don't want to make
the situation worse by making a vector 24 bytes larger than it needs to be.
*Implementations*
This is by no means a new idea. There are four implementations that I'm
aware of, all from major projects:
- SmallVec from LLVM
<http://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h>
- folly::small_vector from Facebook
<https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md>
- boost::container::small_vector
<http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html>
- fixed_vector from EASTL
<https://github.com/paulhodge/EASTL/blob/community/include/EASTL/fixed_vector.h> (with
template param bEnableOverflow = true)
So there is clearly "a market" for this optimisation. Would there be any
interest in proposing such a container for standardisation?
Feedback much appreciated,
Tristan
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_401_2136146707.1451893304266
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div><i>(tl;dr: We should have a vector whi=
ch does the "small string optimisation")</i></div><div><b><br></b=
></div><div><b>Overview</b><br></div><div><br></div><div>It is sometimes th=
e case that one needs to store items of a type T, where the number of items=
will vary dynamically but it known that it will (usually) be small. For ex=
ample, consider an implementation of a sudoku solver: the number of values =
which could possibly occupy a single square will vary as the puzzle is solv=
ed, but in no case can it ever be more than 9. Or perhaps we have an algori=
thm which we know will usually require temporary storage for 5 items, but i=
n the worst case will require us to store 99.</div><div><br></div><div>The =
standard library has two containers which could be used for such purposes:<=
br></div><div><ul><li>std::array<T, N><br></li><li>std::vector<T&g=
t;<br></li></ul><div>Unfortunately, neither is perfectly suited to the task=
, for reasons given below. What would be ideal is a hybrid container with t=
he semantics of a vector, but which preallocates a certain number of Ts on =
the stack, only after which (if more elements are added) does it touch the =
heap -- in essence, the small string optimisation for std::string, but appl=
ied to a vector. Let's call such a container a small_vector<T, N>=
..</div></div><div><br></div><div><b>Why not std::array?</b></div><div><b><b=
r></b></div><div>A std::array is a simple wrapper around a raw array. Its s=
emantics are quite different from those of a vector; it cannot grow, and it=
s size is fixed at compile time. There are many places where std::array is =
the right choicel, but equally many places where it cannot be used.</div><d=
iv><br></div><div><div><b>Why not std::vector?</b></div><div><br></div><div=
>Unlike std::array, std::vector has the semantics we want -- that is, an ar=
ray with dynamic size. The downside is that in order to do this is needs to=
use dynamic allocation. In some scenarios (for example creating and destro=
ying millions of tiny vectors) this can be extremely expensive. Where the n=
umber of items will (usually) be small, we would much prefer to use only th=
e stack and not touch malloc().</div></div><div><br></div><div><b>Okay, so =
why not std::vector with a stack allocator?</b></div><div><br></div><div>Wi=
th stateful allocators introduced C++11, it might be possible to store some=
Ts inside the allocator itself, and overflow to a fallback allocator once =
the local storage is exhausted. This would seem ideal, but unfortunately th=
ere are two problems:</div><div><ul><li>It's not clear that this is per=
mitted within the allocator rules as they stand. I'm happy to defer to =
anyone with better knowledge, but my understanding is that copies of alloca=
tors must compare equal, and this does not seem to be possible if storage i=
s embedded in the allocator itself. Notably, Howard Hinnant's stack all=
ocator uses a separate arena which the user must provide.</li><li>Embedding=
the preallocated array in the vector itself means that the storage can ove=
rlap (i.e. in a union) with the standard three-pointer implementation of a =
heap-allocated vector -- as is the case with the small string optimisation =
for std::string. On the contrary, with a stack allocator the array cannot o=
verlap and will we always be using 3 words more than necessary.</li></ul></=
div><div>The latter point is particularly important as the speed of move op=
erations is be directly proportional to the sizeof the vector; using preall=
ocated storage will unavoidably make moves slower. We certainly don't w=
ant to make the situation worse by making a vector 24 bytes larger than it =
needs to be.=C2=A0</div><div><br></div><div><div><b>Implementations</b><br>=
</div><div>=C2=A0=C2=A0</div><div>This is by no means a new idea. There are=
four implementations that I'm aware of, all from major projects:</div>=
<div><ul><li><font size=3D"2"><a href=3D"http://llvm.org/docs/ProgrammersMa=
nual.html#llvm-adt-smallvector-h">SmallVec from LLVM</a><br></font></li><li=
><font size=3D"2"><a href=3D"https://github.com/facebook/folly/blob/master/=
folly/docs/small_vector.md">folly::small_vector from Facebook</a><br></font=
></li><li><font size=3D"2"><a href=3D"http://www.boost.org/doc/libs/1_60_0/=
doc/html/boost/container/small_vector.html">boost::container::small_vector<=
/a><br></font></li><li><font size=3D"2"><a href=3D"https://github.com/paulh=
odge/EASTL/blob/community/include/EASTL/fixed_vector.h">fixed_vector from E=
ASTL</a>=C2=A0(with template param bEnableOverflow =3D true)</font></li></u=
l><div><br></div></div></div><div>So there is clearly "a market" =
for this optimisation. Would there be any interest in proposing such a cont=
ainer for standardisation?</div><div><br></div><div>Feedback much appreciat=
ed,</div><div><br></div><div><br></div><div>Tristan</div><div><br></div><di=
v><br></div><div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_401_2136146707.1451893304266--
------=_Part_400_1558369814.1451893304266--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 04 Jan 2016 09:56:21 -0200
Raw View
On Sunday 03 January 2016 23:41:44 Tristan Brindle wrote:
> This is by no means a new idea. There are four implementations that I'm
> aware of, all from major projects:
>
> - SmallVec from LLVM
> <http://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h>
> - folly::small_vector from Facebook
> <https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md
> > - boost::container::small_vector
> <http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vect
> or.html> - fixed_vector from EASTL
> <https://github.com/paulhodge/EASTL/blob/community/include/EASTL/fixed_ve
> ctor.h> (with template param bEnableOverflow = true)
You can add QVarLengthArray to that list too.
--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jan 2016 09:11:55 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">On your list of things to consider, note that vector has non-th=
rowing move and swap, whereas a smallvec won't (unless T is non throwing).&=
nbsp;</div><div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D=
"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-s=
erif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-=
color: rgb(255, 255, 255);">Doesn't mean I don't want it, but it can be an =
important difference. </div> =
=
<div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);"><br style=3D"display:in=
itial"></div> =
=
<div style=3D"fon=
t-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;=
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 2=
55, 255);">Sent from my BlackBerry portable Babbag=
e Device</div> =
=
<table width=3D"100%" style=
=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"=
2" style=3D"font-size: initial; text-align: initial; background-color: rgb(=
255, 255, 255);"> <div style=3D"border-style: sol=
id none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; =
padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; fo=
nt-size: 10pt;"> <div><b>From: </b>Tristan Brindle</div><div><b>Sent: </b>=
Monday, January 4, 2016 2:41 AM</div><div><b>To: </b>ISO C++ Standard - Fut=
ure Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div=
><b>Subject: </b>[std-proposals] Views on a small_vector<T, N>?</div>=
</div></td></tr></tbody></table><div style=3D"border-style: solid none none=
; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: i=
nitial; text-align: initial; background-color: rgb(255, 255, 255);"></div><=
br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr"><div><br></div>=
<div><i>(tl;dr: We should have a vector which does the "small string optimi=
sation")</i></div><div><b><br></b></div><div><b>Overview</b><br></div><div>=
<br></div><div>It is sometimes the case that one needs to store items of a =
type T, where the number of items will vary dynamically but it known that i=
t will (usually) be small. For example, consider an implementation of a sud=
oku solver: the number of values which could possibly occupy a single squar=
e will vary as the puzzle is solved, but in no case can it ever be more tha=
n 9. Or perhaps we have an algorithm which we know will usually require tem=
porary storage for 5 items, but in the worst case will require us to store =
99.</div><div><br></div><div>The standard library has two containers which =
could be used for such purposes:<br></div><div><ul><li>std::array<T, N&g=
t;<br></li><li>std::vector<T><br></li></ul><div>Unfortunately, neithe=
r is perfectly suited to the task, for reasons given below. What would be i=
deal is a hybrid container with the semantics of a vector, but which preall=
ocates a certain number of Ts on the stack, only after which (if more eleme=
nts are added) does it touch the heap -- in essence, the small string optim=
isation for std::string, but applied to a vector. Let's call such a contain=
er a small_vector<T, N>.</div></div><div><br></div><div><b>Why not st=
d::array?</b></div><div><b><br></b></div><div>A std::array is a simple wrap=
per around a raw array. Its semantics are quite different from those of a v=
ector; it cannot grow, and its size is fixed at compile time. There are man=
y places where std::array is the right choicel, but equally many places whe=
re it cannot be used.</div><div><br></div><div><div><b>Why not std::vector?=
</b></div><div><br></div><div>Unlike std::array, std::vector has the semant=
ics we want -- that is, an array with dynamic size. The downside is that in=
order to do this is needs to use dynamic allocation. In some scenarios (fo=
r example creating and destroying millions of tiny vectors) this can be ext=
remely expensive. Where the number of items will (usually) be small, we wou=
ld much prefer to use only the stack and not touch malloc().</div></div><di=
v><br></div><div><b>Okay, so why not std::vector with a stack allocator?</b=
></div><div><br></div><div>With stateful allocators introduced C++11, it mi=
ght be possible to store some Ts inside the allocator itself, and overflow =
to a fallback allocator once the local storage is exhausted. This would see=
m ideal, but unfortunately there are two problems:</div><div><ul><li>It's n=
ot clear that this is permitted within the allocator rules as they stand. I=
'm happy to defer to anyone with better knowledge, but my understanding is =
that copies of allocators must compare equal, and this does not seem to be =
possible if storage is embedded in the allocator itself. Notably, Howard Hi=
nnant's stack allocator uses a separate arena which the user must provide.<=
/li><li>Embedding the preallocated array in the vector itself means that th=
e storage can overlap (i.e. in a union) with the standard three-pointer imp=
lementation of a heap-allocated vector -- as is the case with the small str=
ing optimisation for std::string. On the contrary, with a stack allocator t=
he array cannot overlap and will we always be using 3 words more than neces=
sary.</li></ul></div><div>The latter point is particularly important as the=
speed of move operations is be directly proportional to the sizeof the vec=
tor; using preallocated storage will unavoidably make moves slower. We cert=
ainly don't want to make the situation worse by making a vector 24 bytes la=
rger than it needs to be. </div><div><br></div><div><div><b>Implementa=
tions</b><br></div><div> </div><div>This is by no means a new id=
ea. There are four implementations that I'm aware of, all from major projec=
ts:</div><div><ul><li><font size=3D"2"><a href=3D"http://llvm.org/docs/Prog=
rammersManual.html#llvm-adt-smallvector-h">SmallVec from LLVM</a><br></font=
></li><li><font size=3D"2"><a href=3D"https://github.com/facebook/folly/blo=
b/master/folly/docs/small_vector.md">folly::small_vector from Facebook</a><=
br></font></li><li><font size=3D"2"><a href=3D"http://www.boost.org/doc/lib=
s/1_60_0/doc/html/boost/container/small_vector.html">boost::container::smal=
l_vector</a><br></font></li><li><font size=3D"2"><a href=3D"https://github.=
com/paulhodge/EASTL/blob/community/include/EASTL/fixed_vector.h">fixed_vect=
or from EASTL</a> (with template param bEnableOverflow =3D true)</font=
></li></ul><div><br></div></div></div><div>So there is clearly "a market" f=
or this optimisation. Would there be any interest in proposing such a conta=
iner for standardisation?</div><div><br></div><div>Feedback much appreciate=
d,</div><div><br></div><div><br></div><div>Tristan</div><div><br></div><div=
><br></div><div><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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Mon, 04 Jan 2016 09:18:24 -0500
Raw View
--Apple-Mail=_0A0C0104-9621-4626-8991-020504653B11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Your analysis of allocator support (within the current standard) is
correct. Stack-allocators are typically handed a reference to some
stack-based buffer, rather than owning their own internal buffer, due
to the copies-must-compare-equal requirement. This works well
for a single container, but does not cover the case of containers-of-
containers, where you may want millions of small containers.
I think this would be a great proposal for a TS, especially as it has
been re-implemented many times. One of the key issues is
reframing the container requirements documentation to allow for
containers with different iterator/reference stability rules, although
this is already done for =E2=80=98basic_string=E2=80=99.
I am not yet convinced that such a special-purpose container belongs
in the main standard, the concern being how many more special-purpose
containers would then follow the precedent. I think that is a worthwhile
question to pursue though, either as part of this as a proposal, or as a
separate follow-up.
AlisdairM
> On Jan 4, 2016, at 2:41 AM, Tristan Brindle <tcbrindle@gmail.com> wrote:
>=20
> Okay, so why not std::vector with a stack allocator?
>=20
> With stateful allocators introduced C++11, it might be possible to store =
some Ts inside the allocator itself, and overflow to a fallback allocator o=
nce the local storage is exhausted. This would seem ideal, but unfortunatel=
y there are two problems:
> It's not clear that this is permitted within the allocator rules as they =
stand. I'm happy to defer to anyone with better knowledge, but my understan=
ding is that copies of allocators must compare equal, and this does not see=
m to be possible if storage is embedded in the allocator itself. Notably, H=
oward Hinnant's stack allocator uses a separate arena which the user must p=
rovide.
> Embedding the preallocated array in the vector itself means that the stor=
age can overlap (i.e. in a union) with the standard three-pointer implement=
ation of a heap-allocated vector -- as is the case with the small string op=
timisation for std::string. On the contrary, with a stack allocator the arr=
ay cannot overlap and will we always be using 3 words more than necessary.
> The latter point is particularly important as the speed of move operation=
s is be directly proportional to the sizeof the vector; using preallocated =
storage will unavoidably make moves slower. We certainly don't want to make=
the situation worse by making a vector 24 bytes larger than it needs to be=
..=20
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_0A0C0104-9621-4626-8991-020504653B11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">Your analysis of a=
llocator support (within the current standard) is<div class=3D"">correct. &=
nbsp;Stack-allocators are typically handed a reference to some</div><div cl=
ass=3D"">stack-based buffer, rather than owning their own internal buffer, =
due</div><div class=3D"">to the copies-must-compare-equal requirement. &nbs=
p;This works well</div><div class=3D"">for a single container, but does not=
cover the case of containers-of-</div><div class=3D"">containers, where yo=
u may want millions of small containers.</div><div class=3D""><br class=3D"=
"></div><div class=3D"">I think this would be a great proposal for a TS, es=
pecially as it has</div><div class=3D"">been re-implemented many times. &nb=
sp;One of the key issues is</div><div class=3D"">reframing the container re=
quirements documentation to allow for</div><div class=3D"">containers with =
different iterator/reference stability rules, although</div><div class=3D""=
>this is already done for =E2=80=98basic_string=E2=80=99.</div><div class=
=3D""><br class=3D""></div><div class=3D"">I am not yet convinced that such=
a special-purpose container belongs</div><div class=3D"">in the main stand=
ard, the concern being how many more special-purpose</div><div class=3D"">c=
ontainers would then follow the precedent. I think that is a worthwhi=
le</div><div class=3D"">question to pursue though, either as part of this a=
s a proposal, or as a</div><div class=3D"">separate follow-up.</div><div cl=
ass=3D""><br class=3D""></div><div class=3D"">AlisdairM</div><div class=3D"=
"><br class=3D""></div><div class=3D""><div><blockquote type=3D"cite" class=
=3D""><div class=3D"">On Jan 4, 2016, at 2:41 AM, Tristan Brindle <<a hr=
ef=3D"mailto:tcbrindle@gmail.com" class=3D"">tcbrindle@gmail.com</a>> wr=
ote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><b class=3D"">Okay, so why not std::vector with a stack allocator?</b=
></div><div style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px;" class=3D""><br class=3D""></div><div style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">With stateful alloc=
ators introduced C++11, it might be possible to store some Ts inside the al=
locator itself, and overflow to a fallback allocator once the local storage=
is exhausted. This would seem ideal, but unfortunately there are two probl=
ems:</div><div style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; orphans: auto; text-align: start; text-indent: 0px; text-transform: none;=
white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-=
width: 0px;" class=3D""><ul class=3D""><li class=3D"">It's not clear that t=
his is permitted within the allocator rules as they stand. I'm happy to def=
er to anyone with better knowledge, but my understanding is that copies of =
allocators must compare equal, and this does not seem to be possible if sto=
rage is embedded in the allocator itself. Notably, Howard Hinnant's stack a=
llocator uses a separate arena which the user must provide.</li><li class=
=3D"">Embedding the preallocated array in the vector itself means that the =
storage can overlap (i.e. in a union) with the standard three-pointer imple=
mentation of a heap-allocated vector -- as is the case with the small strin=
g optimisation for std::string. On the contrary, with a stack allocator the=
array cannot overlap and will we always be using 3 words more than necessa=
ry.</li></ul></div><div style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D"">The latter point is particularly important=
as the speed of move operations is be directly proportional to the sizeof =
the vector; using preallocated storage will unavoidably make moves slower. =
We certainly don't want to make the situation worse by making a vector 24 b=
ytes larger than it needs to be. </div></div></blockquote></div><br cl=
ass=3D""></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_0A0C0104-9621-4626-8991-020504653B11--
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Mon, 04 Jan 2016 09:23:06 -0500
Raw View
--Apple-Mail=_61F443A5-2770-4273-AB2B-2D1930AE0ED6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
This is why I would strongly oppose allowing the =E2=80=98small object=E2=
=80=99 optimization
for =E2=80=98std::vector=E2=80=99. I think it is much more interesting as =
a distinct type though,
where users can pick the container optimized to match their needs.
One interesting question that occurs to me is whether we should want
=E2=80=98vector=E2=80=99 and =E2=80=98small_vector=E2=80=99 to have the sam=
e iterator type? That would make
it easier to change containers in (function) implementations without
impacting ABIs, as the iterator type (more typically used in interfaces) re=
mains
the same. That would also deal with =E2=80=98template bloat=E2=80=9D issue=
s.
On the other hand, there are enough folks that seem to prefer that =E2=80=
=98array=E2=80=99,
=E2=80=98basic_string=E2=80=99, and =E2=80=98vector=E2=80=99 all have disti=
nct iterator types, even though a simple
pointer would be a valid implementation in each case.
AlisdairM
> On Jan 4, 2016, at 9:11 AM, Tony V E <tvaneerd@gmail.com> wrote:
>=20
> On your list of things to consider, note that vector has non-throwing mov=
e and swap, whereas a smallvec won't (unless T is non throwing).=20
>=20
> Doesn't mean I don't want it, but it can be an important difference.
>=20
> Sent from my BlackBerry portable Babbage Device
> From: Tristan Brindle
> Sent: Monday, January 4, 2016 2:41 AM
> To: ISO C++ Standard - Future Proposals
> Reply To: std-proposals@isocpp.org
> Subject: [std-proposals] Views on a small_vector<T, N>?
>=20
>=20
> (tl;dr: We should have a vector which does the "small string optimisation=
")
>=20
> Overview
>=20
> It is sometimes the case that one needs to store items of a type T, where=
the number of items will vary dynamically but it known that it will (usual=
ly) be small. For example, consider an implementation of a sudoku solver: t=
he number of values which could possibly occupy a single square will vary a=
s the puzzle is solved, but in no case can it ever be more than 9. Or perha=
ps we have an algorithm which we know will usually require temporary storag=
e for 5 items, but in the worst case will require us to store 99.
>=20
> The standard library has two containers which could be used for such purp=
oses:
> std::array<T, N>
> std::vector<T>
> Unfortunately, neither is perfectly suited to the task, for reasons given=
below. What would be ideal is a hybrid container with the semantics of a v=
ector, but which preallocates a certain number of Ts on the stack, only aft=
er which (if more elements are added) does it touch the heap -- in essence,=
the small string optimisation for std::string, but applied to a vector. Le=
t's call such a container a small_vector<T, N>.
>=20
> Why not std::array?
>=20
> A std::array is a simple wrapper around a raw array. Its semantics are qu=
ite different from those of a vector; it cannot grow, and its size is fixed=
at compile time. There are many places where std::array is the right choic=
el, but equally many places where it cannot be used.
>=20
> Why not std::vector?
>=20
> Unlike std::array, std::vector has the semantics we want -- that is, an a=
rray with dynamic size. The downside is that in order to do this is needs t=
o use dynamic allocation. In some scenarios (for example creating and destr=
oying millions of tiny vectors) this can be extremely expensive. Where the =
number of items will (usually) be small, we would much prefer to use only t=
he stack and not touch malloc().
>=20
> Okay, so why not std::vector with a stack allocator?
>=20
> With stateful allocators introduced C++11, it might be possible to store =
some Ts inside the allocator itself, and overflow to a fallback allocator o=
nce the local storage is exhausted. This would seem ideal, but unfortunatel=
y there are two problems:
> It's not clear that this is permitted within the allocator rules as they =
stand. I'm happy to defer to anyone with better knowledge, but my understan=
ding is that copies of allocators must compare equal, and this does not see=
m to be possible if storage is embedded in the allocator itself. Notably, H=
oward Hinnant's stack allocator uses a separate arena which the user must p=
rovide.
> Embedding the preallocated array in the vector itself means that the stor=
age can overlap (i.e. in a union) with the standard three-pointer implement=
ation of a heap-allocated vector -- as is the case with the small string op=
timisation for std::string. On the contrary, with a stack allocator the arr=
ay cannot overlap and will we always be using 3 words more than necessary.
> The latter point is particularly important as the speed of move operation=
s is be directly proportional to the sizeof the vector; using preallocated =
storage will unavoidably make moves slower. We certainly don't want to make=
the situation worse by making a vector 24 bytes larger than it needs to be=
..=20
>=20
> Implementations
> =20
> This is by no means a new idea. There are four implementations that I'm a=
ware of, all from major projects:
> SmallVec from LLVM <http://llvm.org/docs/ProgrammersManual.html#llvm-adt-=
smallvector-h>
> folly::small_vector from Facebook <https://github.com/facebook/folly/blob=
/master/folly/docs/small_vector.md>
> boost::container::small_vector <http://www.boost.org/doc/libs/1_60_0/doc/=
html/boost/container/small_vector.html>
> fixed_vector from EASTL <https://github.com/paulhodge/EASTL/blob/communit=
y/include/EASTL/fixed_vector.h> (with template param bEnableOverflow =3D tr=
ue)
>=20
> So there is clearly "a market" for this optimisation. Would there be any =
interest in proposing such a container for standardisation?
>=20
> Feedback much appreciated,
>=20
>=20
> Tristan
>=20
>=20
>=20
>=20
>=20
> --=20
>=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/ <https://groups.google.com/a/isocpp.org/group/std-proposals/>.
>=20
>=20
> --=20
>=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/ <https://groups.google.com/a/isocpp.org/group/std-proposals/>.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_61F443A5-2770-4273-AB2B-2D1930AE0ED6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">This is why I woul=
d strongly oppose allowing the =E2=80=98small object=E2=80=99 optimization<=
div class=3D"">for =E2=80=98std::vector=E2=80=99. I think it is much =
more interesting as a distinct type though,</div><div class=3D"">where user=
s can pick the container optimized to match their needs.</div><div class=3D=
""><br class=3D""></div><div class=3D"">One interesting question that occur=
s to me is whether we should want</div><div class=3D"">=E2=80=98vector=E2=
=80=99 and =E2=80=98small_vector=E2=80=99 to have the same iterator type? &=
nbsp;That would make</div><div class=3D"">it easier to change containers in=
(function) implementations without</div><div class=3D"">impacting ABIs, as=
the iterator type (more typically used in interfaces) remains</div><div cl=
ass=3D"">the same. That would also deal with =E2=80=98template bloat=
=E2=80=9D issues.</div><div class=3D""><br class=3D""></div><div class=3D""=
>On the other hand, there are enough folks that seem to prefer that =E2=80=
=98array=E2=80=99,</div><div class=3D"">=E2=80=98basic_string=E2=80=99, and=
=E2=80=98vector=E2=80=99 all have distinct iterator types, even though a s=
imple</div><div class=3D"">pointer would be a valid implementation in each =
case.</div><div class=3D""><br class=3D""></div><div class=3D"">AlisdairM</=
div><div class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D"=
"><div class=3D"">On Jan 4, 2016, at 9:11 AM, Tony V E <<a href=3D"mailt=
o:tvaneerd@gmail.com" class=3D"">tvaneerd@gmail.com</a>> wrote:</div><br=
class=3D"Apple-interchange-newline"><div class=3D""><div lang=3D"en-US" st=
yle=3D"background-color: rgb(255, 255, 255); line-height: initial;" class=
=3D""> =
<div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);" class=3D"">On you=
r list of things to consider, note that vector has non-throwing move and sw=
ap, whereas a smallvec won't (unless T is non throwing). </div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);" class=3D""><br class=3D""></div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);" class=3D"">Doesn't mean I don't want it, bu=
t it can be an important difference. </div> =
=
<div style=3D"width: 100%; font-size: initial; fo=
nt-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73,=
125); text-align: initial; background-color: rgb(255, 255, 255);" class=3D=
""><br style=3D"display:initial" class=3D""></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri,=
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: =
initial; background-color: rgb(255, 255, 255);" class=3D"">Sent from&n=
bsp;my BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;b=
order-spacing:0px;" class=3D""> <tbody class=3D""><tr class=3D""><td colspa=
n=3D"2" style=3D"font-size: initial; text-align: initial; background-color:=
rgb(255, 255, 255);" class=3D""> <div style=3D"b=
order-style: solid none none; border-top-color: rgb(181, 196, 223); border-=
top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans',=
'Slate Pro'; font-size: 10pt;" class=3D""> <div class=3D""><b class=3D"">=
From: </b>Tristan Brindle</div><div class=3D""><b class=3D"">Sent: </b>Mond=
ay, January 4, 2016 2:41 AM</div><div class=3D""><b class=3D"">To: </b>ISO =
C++ Standard - Future Proposals</div><div class=3D""><b class=3D"">Reply To=
: </b><a href=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@=
isocpp.org</a></div><div class=3D""><b class=3D"">Subject: </b>[std-proposa=
ls] Views on a small_vector<T, N>?</div></div></td></tr></tbody></tab=
le><div style=3D"border-style: solid none none; border-top-color: rgb(186, =
188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; =
background-color: rgb(255, 255, 255);" class=3D""></div><br class=3D""><div=
id=3D"_originalContent" style=3D"" class=3D""><div dir=3D"ltr" class=3D"">=
<div class=3D""><br class=3D""></div><div class=3D""><i class=3D"">(tl;dr: =
We should have a vector which does the "small string optimisation")</i></di=
v><div class=3D""><b class=3D""><br class=3D""></b></div><div class=3D""><b=
class=3D"">Overview</b><br class=3D""></div><div class=3D""><br class=3D""=
></div><div class=3D"">It is sometimes the case that one needs to store ite=
ms of a type T, where the number of items will vary dynamically but it know=
n that it will (usually) be small. For example, consider an implementation =
of a sudoku solver: the number of values which could possibly occupy a sing=
le square will vary as the puzzle is solved, but in no case can it ever be =
more than 9. Or perhaps we have an algorithm which we know will usually req=
uire temporary storage for 5 items, but in the worst case will require us t=
o store 99.</div><div class=3D""><br class=3D""></div><div class=3D"">The s=
tandard library has two containers which could be used for such purposes:<b=
r class=3D""></div><div class=3D""><ul class=3D""><li class=3D"">std::array=
<T, N><br class=3D""></li><li class=3D"">std::vector<T><br clas=
s=3D""></li></ul><div class=3D"">Unfortunately, neither is perfectly suited=
to the task, for reasons given below. What would be ideal is a hybrid cont=
ainer with the semantics of a vector, but which preallocates a certain numb=
er of Ts on the stack, only after which (if more elements are added) does i=
t touch the heap -- in essence, the small string optimisation for std::stri=
ng, but applied to a vector. Let's call such a container a small_vector<=
T, N>.</div></div><div class=3D""><br class=3D""></div><div class=3D""><=
b class=3D"">Why not std::array?</b></div><div class=3D""><b class=3D""><br=
class=3D""></b></div><div class=3D"">A std::array is a simple wrapper arou=
nd a raw array. Its semantics are quite different from those of a vector; i=
t cannot grow, and its size is fixed at compile time. There are many places=
where std::array is the right choicel, but equally many places where it ca=
nnot be used.</div><div class=3D""><br class=3D""></div><div class=3D""><di=
v class=3D""><b class=3D"">Why not std::vector?</b></div><div class=3D""><b=
r class=3D""></div><div class=3D"">Unlike std::array, std::vector has the s=
emantics we want -- that is, an array with dynamic size. The downside is th=
at in order to do this is needs to use dynamic allocation. In some scenario=
s (for example creating and destroying millions of tiny vectors) this can b=
e extremely expensive. Where the number of items will (usually) be small, w=
e would much prefer to use only the stack and not touch malloc().</div></di=
v><div class=3D""><br class=3D""></div><div class=3D""><b class=3D"">Okay, =
so why not std::vector with a stack allocator?</b></div><div class=3D""><br=
class=3D""></div><div class=3D"">With stateful allocators introduced C++11=
, it might be possible to store some Ts inside the allocator itself, and ov=
erflow to a fallback allocator once the local storage is exhausted. This wo=
uld seem ideal, but unfortunately there are two problems:</div><div class=
=3D""><ul class=3D""><li class=3D"">It's not clear that this is permitted w=
ithin the allocator rules as they stand. I'm happy to defer to anyone with =
better knowledge, but my understanding is that copies of allocators must co=
mpare equal, and this does not seem to be possible if storage is embedded i=
n the allocator itself. Notably, Howard Hinnant's stack allocator uses a se=
parate arena which the user must provide.</li><li class=3D"">Embedding the =
preallocated array in the vector itself means that the storage can overlap =
(i.e. in a union) with the standard three-pointer implementation of a heap-=
allocated vector -- as is the case with the small string optimisation for s=
td::string. On the contrary, with a stack allocator the array cannot overla=
p and will we always be using 3 words more than necessary.</li></ul></div><=
div class=3D"">The latter point is particularly important as the speed of m=
ove operations is be directly proportional to the sizeof the vector; using =
preallocated storage will unavoidably make moves slower. We certainly don't=
want to make the situation worse by making a vector 24 bytes larger than i=
t needs to be. </div><div class=3D""><br class=3D""></div><div class=
=3D""><div class=3D""><b class=3D"">Implementations</b><br class=3D""></div=
><div class=3D""> </div><div class=3D"">This is by no means a ne=
w idea. There are four implementations that I'm aware of, all from major pr=
ojects:</div><div class=3D""><ul class=3D""><li class=3D""><font size=3D"2"=
class=3D""><a href=3D"http://llvm.org/docs/ProgrammersManual.html#llvm-adt=
-smallvector-h" class=3D"">SmallVec from LLVM</a><br class=3D""></font></li=
><li class=3D""><font size=3D"2" class=3D""><a href=3D"https://github.com/f=
acebook/folly/blob/master/folly/docs/small_vector.md" class=3D"">folly::sma=
ll_vector from Facebook</a><br class=3D""></font></li><li class=3D""><font =
size=3D"2" class=3D""><a href=3D"http://www.boost.org/doc/libs/1_60_0/doc/h=
tml/boost/container/small_vector.html" class=3D"">boost::container::small_v=
ector</a><br class=3D""></font></li><li class=3D""><font size=3D"2" class=
=3D""><a href=3D"https://github.com/paulhodge/EASTL/blob/community/include/=
EASTL/fixed_vector.h" class=3D"">fixed_vector from EASTL</a> (with tem=
plate param bEnableOverflow =3D true)</font></li></ul><div class=3D""><br c=
lass=3D""></div></div></div><div class=3D"">So there is clearly "a market" =
for this optimisation. Would there be any interest in proposing such a cont=
ainer for standardisation?</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Feedback much appreciated,</div><div class=3D""><br class=3D""></=
div><div class=3D""><br class=3D""></div><div class=3D"">Tristan</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div c=
lass=3D""><br class=3D""></div><div class=3D""><br class=3D""></div></div><=
div class=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" class=3D"">https://groups.google.com/a/isocpp.org/group/st=
d-proposals/</a>.<br class=3D"">
<br class=3D""><!--end of _originalContent --></div></div><div class=3D""><=
br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" class=3D"">https://groups.google.com/a/isocpp.org/group/st=
d-proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_61F443A5-2770-4273-AB2B-2D1930AE0ED6--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jan 2016 13:07:34 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Also, for nonthrowing or trivial T, could a small buffer optimi=
zation inside std::vector<T> be conforming? (as a constant such as 16=
elements is still constant time?). </div> =
=
<div style=3D"width: 100%; font-size: initial; fon=
t-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, =
125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div=
> =
=
<div style=3D"font-size: init=
ial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(=
31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">S=
ent from my BlackBerry portable Babbage Devic=
e</div> =
=
<table width=3D"100%" style=3D"backgroun=
d-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"f=
ont-size: initial; text-align: initial; background-color: rgb(255, 255, 255=
);"> <div style=3D"border-style: solid none none;=
border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt =
0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt=
;"> <div><b>From: </b>Tony V E</div><div><b>Sent: </b>Monday, January 4, 2=
016 9:11 AM</div><div><b>To: </b>Tristan Brindle; ISO C++ Standard - Future=
Proposals</div><div><b>Subject: </b>Re: [std-proposals] Views on a small_v=
ector<T, N>?</div></div></td></tr></tbody></table><div style=3D"borde=
r-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-=
width: 1pt; font-size: initial; text-align: initial; background-color: rgb(=
255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""> =
=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);">On your list of things to consi=
der, note that vector has non-throwing move and swap, whereas a smallvec wo=
n't (unless T is non throwing). </div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);"><br></div><div style=3D"width: 100%; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);">Doesn't mean I =
don't want it, but it can be an important difference. </div> =
=
<div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Sla=
te Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initi=
al; background-color: rgb(255, 255, 255);">Sent from my Blac=
kBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-spacing:0p=
x;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: =
initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb(181, 196=
, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, '=
BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Tristan =
Brindle</div><div><b>Sent: </b>Monday, January 4, 2016 2:41 AM</div><div><b=
>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std=
-proposals@isocpp.org</div><div><b>Subject: </b>[std-proposals] Views on a =
small_vector<T, N>?</div></div></td></tr></tbody></table><div style=
=3D"border-style: solid none none; border-top-color: rgb(186, 188, 209); bo=
rder-top-width: 1pt; font-size: initial; text-align: initial; background-co=
lor: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""=
><div dir=3D"ltr"><div><br></div><div><i>(tl;dr: We should have a vector wh=
ich does the "small string optimisation")</i></div><div><b><br></b></div><d=
iv><b>Overview</b><br></div><div><br></div><div>It is sometimes the case th=
at one needs to store items of a type T, where the number of items will var=
y dynamically but it known that it will (usually) be small. For example, co=
nsider an implementation of a sudoku solver: the number of values which cou=
ld possibly occupy a single square will vary as the puzzle is solved, but i=
n no case can it ever be more than 9. Or perhaps we have an algorithm which=
we know will usually require temporary storage for 5 items, but in the wor=
st case will require us to store 99.</div><div><br></div><div>The standard =
library has two containers which could be used for such purposes:<br></div>=
<div><ul><li>std::array<T, N><br></li><li>std::vector<T><br></l=
i></ul><div>Unfortunately, neither is perfectly suited to the task, for rea=
sons given below. What would be ideal is a hybrid container with the semant=
ics of a vector, but which preallocates a certain number of Ts on the stack=
, only after which (if more elements are added) does it touch the heap -- i=
n essence, the small string optimisation for std::string, but applied to a =
vector. Let's call such a container a small_vector<T, N>.</div></div>=
<div><br></div><div><b>Why not std::array?</b></div><div><b><br></b></div><=
div>A std::array is a simple wrapper around a raw array. Its semantics are =
quite different from those of a vector; it cannot grow, and its size is fix=
ed at compile time. There are many places where std::array is the right cho=
icel, but equally many places where it cannot be used.</div><div><br></div>=
<div><div><b>Why not std::vector?</b></div><div><br></div><div>Unlike std::=
array, std::vector has the semantics we want -- that is, an array with dyna=
mic size. The downside is that in order to do this is needs to use dynamic =
allocation. In some scenarios (for example creating and destroying millions=
of tiny vectors) this can be extremely expensive. Where the number of item=
s will (usually) be small, we would much prefer to use only the stack and n=
ot touch malloc().</div></div><div><br></div><div><b>Okay, so why not std::=
vector with a stack allocator?</b></div><div><br></div><div>With stateful a=
llocators introduced C++11, it might be possible to store some Ts inside th=
e allocator itself, and overflow to a fallback allocator once the local sto=
rage is exhausted. This would seem ideal, but unfortunately there are two p=
roblems:</div><div><ul><li>It's not clear that this is permitted within the=
allocator rules as they stand. I'm happy to defer to anyone with better kn=
owledge, but my understanding is that copies of allocators must compare equ=
al, and this does not seem to be possible if storage is embedded in the all=
ocator itself. Notably, Howard Hinnant's stack allocator uses a separate ar=
ena which the user must provide.</li><li>Embedding the preallocated array i=
n the vector itself means that the storage can overlap (i.e. in a union) wi=
th the standard three-pointer implementation of a heap-allocated vector -- =
as is the case with the small string optimisation for std::string. On the c=
ontrary, with a stack allocator the array cannot overlap and will we always=
be using 3 words more than necessary.</li></ul></div><div>The latter point=
is particularly important as the speed of move operations is be directly p=
roportional to the sizeof the vector; using preallocated storage will unavo=
idably make moves slower. We certainly don't want to make the situation wor=
se by making a vector 24 bytes larger than it needs to be. </div><div>=
<br></div><div><div><b>Implementations</b><br></div><div> </div>=
<div>This is by no means a new idea. There are four implementations that I'=
m aware of, all from major projects:</div><div><ul><li><font size=3D"2"><a =
href=3D"http://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h"=
>SmallVec from LLVM</a><br></font></li><li><font size=3D"2"><a href=3D"http=
s://github.com/facebook/folly/blob/master/folly/docs/small_vector.md">folly=
::small_vector from Facebook</a><br></font></li><li><font size=3D"2"><a hre=
f=3D"http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_ve=
ctor.html">boost::container::small_vector</a><br></font></li><li><font size=
=3D"2"><a href=3D"https://github.com/paulhodge/EASTL/blob/community/include=
/EASTL/fixed_vector.h">fixed_vector from EASTL</a> (with template para=
m bEnableOverflow =3D true)</font></li></ul><div><br></div></div></div><div=
>So there is clearly "a market" for this optimisation. Would there be any i=
nterest in proposing such a container for standardisation?</div><div><br></=
div><div>Feedback much appreciated,</div><div><br></div><div><br></div><div=
>Tristan</div><div><br></div><div><br></div><div><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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div>
<br><!--end of _originalContent --></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Mon, 4 Jan 2016 12:27:38 -0600
Raw View
--089e01176ba3f2bc830528864851
Content-Type: text/plain; charset=UTF-8
On 4 January 2016 at 01:41, Tristan Brindle <tcbrindle@gmail.com> wrote:
> Would there be any interest in proposing such a container for
> standardisation?
Yes (as a separate container and not trying to adapt vector to support
it). LEWG said as much in Kansas when I brought it up, but I have not yet
had time to write up a proposal. (If someone else wishes to do it, go for
it!)
--
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
+1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01176ba3f2bc830528864851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 4 January 2016 at 01:41, Tri=
stan Brindle <span dir=3D"ltr"><<a href=3D"mailto:tcbrindle@gmail.com" t=
arget=3D"_blank">tcbrindle@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">Would there be any interest in=
proposing such a container for standardisation?</blockquote></div><br>Yes =
(as a separate container and not trying to adapt vector to support it).=C2=
=A0 LEWG said as much in Kansas when I brought it up, but I have not yet ha=
d time to write up a proposal. =C2=A0(If someone else wishes to do it, go f=
or it!)</div><div class=3D"gmail_extra">-- <br><div class=3D"gmail_signatur=
e"><div dir=3D"ltr">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusguy.=
com</a>>=C2=A0 +1-847-691-1404<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e01176ba3f2bc830528864851--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Mon, 4 Jan 2016 15:29:08 -0300
Raw View
On 1/4/2016 3:07 PM, Tony V E wrote:
> Also, for nonthrowing or trivial T, could a small buffer optimization
> inside std::vector<T> be conforming? (as a constant such as 16 elements
> is still constant time?).
No, because swapping `std::vector<T>` shall not invalidate any=20
references, pointers, or iterators.
> Sent from my BlackBerry portable Babbage Device
> *From: *Tony V E
> *Sent: *Monday, January 4, 2016 9:11 AM
> *To: *Tristan Brindle; ISO C++ Standard - Future Proposals
> *Subject: *Re: [std-proposals] Views on a small_vector<T, N>?
>
>
> On your list of things to consider, note that vector has non-throwing
> move and swap, whereas a smallvec won't (unless T is non throwing).
>
> Doesn't mean I don't want it, but it can be an important difference.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jan 2016 13:38:16 -0500
Raw View
Ah, right. I'm not a fan of that feature generally, thus I forgot it :-)
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Agust=C3=ADn K-ballo Berg=C3=A9
Sent: Monday, January 4, 2016 1:29 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Views on a small_vector<T, N>?
On 1/4/2016 3:07 PM, Tony V E wrote:
> Also, for nonthrowing or trivial T, could a small buffer optimization
> inside std::vector<T> be conforming? (as a constant such as 16 elements
> is still constant time?).
No, because swapping `std::vector<T>` shall not invalidate any=20
references, pointers, or iterators.
> Sent from my BlackBerry portable Babbage Device
> *From: *Tony V E
> *Sent: *Monday, January 4, 2016 9:11 AM
> *To: *Tristan Brindle; ISO C++ Standard - Future Proposals
> *Subject: *Re: [std-proposals] Views on a small_vector<T, N>?
>
>
> On your list of things to consider, note that vector has non-throwing
> move and swap, whereas a smallvec won't (unless T is non throwing).
>
> Doesn't mean I don't want it, but it can be an important difference.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Mon, 4 Jan 2016 17:33:10 -0200
Raw View
2016-01-04 12:18 GMT-02:00 Alisdair Meredith <alisdairm@me.com>:
> Your analysis of allocator support (within the current standard) is
> correct. Stack-allocators are typically handed a reference to some
> stack-based buffer, rather than owning their own internal buffer, due
> to the copies-must-compare-equal requirement. This works well
> for a single container, but does not cover the case of containers-of-
> containers, where you may want millions of small containers.
Can't scoped allocators cover the container of containers case?
For example:
using inner_alloc_type = my::allocator<int>;
using inner_vector_type = std::vector<int, inner_alloc_type>;
using outer_alloc_type =
std::scoped_allocator_adaptor< std::allocator<inner_vector_type>
, inner_alloc_type>;
// All small inner-allocations go on this buffer.
std::array<char, 2000> buffer = {{}};
inner_alloc_type alloc1(buffer);
std::allocator<inner_vector_type> alloc2;
outer_alloc_type alloc(alloc2, alloc1);
std::list<inner_vector_type, outer_alloc_type> t1(alloc);
t1.push_back({{5, 3, 7, 20}});
t1.push_back({{1, 44, 22, 8}});
Then the implementation of my::allocator<int>::allocate can decide
what goes on the stack buffer and what goes on the heap:
....
my::allocator<int>::allocate(size_type n)
{
if (n < stack_max_size)
return find_space_on_the_stack_buffer();
return find_space_on_the_heap();
}
This has the advantage that the shared stack buffer can have a smaller size
than if I had individual buffers for each small_vector, since in this case, it
is very unlikely that all containers have reached their "stack limit" at the
same time.
Marcelo
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Tue, 5 Jan 2016 13:37:50 +0000
Raw View
--001a11402764ff583a0528965717
Content-Type: text/plain; charset=UTF-8
On 4 January 2016 at 18:07, Tony V E <tvaneerd@gmail.com> wrote:
> Also, for nonthrowing or trivial T, could a small buffer optimization
> inside std::vector<T> be conforming? (as a constant such as 16 elements is
> still constant time?).
>
Nope, because swap has to preserve iterators, and you would then have
pointers into another vector's internal state, which could go out of scope.
Chris
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11402764ff583a0528965717
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4=
January 2016 at 18:07, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tv=
aneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background=
-color:rgb(255,255,255);line-height:initial"> =
<div style=3D"width=
:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,=
sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255=
,255,255)">Also, for nonthrowing or trivial T, could a small buffer optimiz=
ation inside std::vector<T> be conforming? (as a constant such as 16 =
elements is still constant time?).</div></div></blockquote><div><br></div><=
div>Nope, because swap has to preserve iterators, and you would then have p=
ointers into another vector's internal state, which could go out of sco=
pe.</div><div><br></div><div>Chris</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11402764ff583a0528965717--
.
Author: Alisdair Meredith <alisdairm@me.com>
Date: Tue, 05 Jan 2016 08:57:45 -0500
Raw View
> On Jan 4, 2016, at 2:33 PM, Marcelo Zimbres <mzimbres@gmail.com> wrote:
>=20
> Can't scoped allocators cover the container of containers case?
This is fine for the simple case, where you can put a simple limit on the
amount of stack space to the used by all elements in the container, but
the original problem is slightly mis-stated.
The intent is that for a small vector, memory allocation comes out of space
in the vector object itself, rather than necessitating a trip to the heap. =
When
we have a container with millions of small vectors, that saving is notable.=
In
this case, we do not really mean =E2=80=98allocate on the stack=E2=80=99 bu=
t =E2=80=98allocate from
internal state=E2=80=99, and that is where allocators can no longer help, b=
ut the
optimization must be built into the data structure itself.
AlisdairM
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 5 Jan 2016 15:06:28 +0100
Raw View
--001a114242a467b3a0052896befe
Content-Type: text/plain; charset=UTF-8
On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <alisdairm@me.com> wrote:
> I am not yet convinced that such a special-purpose container belongs
> in the main standard, the concern being how many more special-purpose
> containers would then follow the precedent. I think that is a worthwhile
> question to pursue though, either as part of this as a proposal, or as a
> separate follow-up.
>
I'm with Alisdair on this one. There are many many different data
structures with all sorts of different interfaces and performance
profiles. The standard containers do and should only cover a handful of
the most common general-purpose ones.
I'd be much more interested in proposals that would make it easier and
safer to implement data structures like small_vector yourself.
Implementing a data structure to the level of sophistication of say
std::vector (with all the iterators and allocators and member types and
specializations of various things and so on) is way more work than it could
be if we provided better tools/primtivites/building-blocks to assist.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114242a467b3a0052896befe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <span dir=3D"ltr"><<a href=
=3D"mailto:alisdairm@me.com" target=3D"_blank">alisdairm@me.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word"><div>I am not yet convinced that such a special-purpose container bel=
ongs</div><div>in the main standard, the concern being how many more specia=
l-purpose</div><div>containers would then follow the precedent.=C2=A0 I thi=
nk that is a worthwhile</div><div>question to pursue though, either as part=
of this as a proposal, or as a</div><div>separate follow-up.</div><div></d=
iv></div></blockquote></div><br></div><div class=3D"gmail_extra">I'm wi=
th Alisdair on this one.=C2=A0 There are many many different data structure=
s with all sorts of different interfaces and performance profiles.=C2=A0 Th=
e standard containers do and should only cover a handful of the most common=
general-purpose ones.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">I'd be much more interested in proposals that would ma=
ke it easier and safer to implement data structures like small_vector yours=
elf.=C2=A0 Implementing a data structure to the level of sophistication of =
say std::vector (with all the iterators and allocators and member types and=
specializations of various things and so on) is way more work than it coul=
d be if we provided better tools/primtivites/building-blocks to assist.</di=
v><div class=3D"gmail_extra"><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114242a467b3a0052896befe--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Jan 2016 16:22:17 +0200
Raw View
On 5 January 2016 at 16:06, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <alisdairm@me.com> wrote:
>>
>> I am not yet convinced that such a special-purpose container belongs
>> in the main standard, the concern being how many more special-purpose
>> containers would then follow the precedent. I think that is a worthwhile
>> question to pursue though, either as part of this as a proposal, or as a
>> separate follow-up.
>
>
> I'm with Alisdair on this one. There are many many different data
> structures with all sorts of different interfaces and performance profiles.
> The standard containers do and should only cover a handful of the most
> common general-purpose ones.
>
> I'd be much more interested in proposals that would make it easier and safer
> to implement data structures like small_vector yourself. Implementing a
> data structure to the level of sophistication of say std::vector (with all
> the iterators and allocators and member types and specializations of various
> things and so on) is way more work than it could be if we provided better
> tools/primtivites/building-blocks to assist.
Even so, there's fairly good amounts of evidence that a small-vector
is a commonly
used container, so concerns about that somehow opening the door for too many
special-purpose containers, for whatever values of "too many" and
"special-purpose",
seem completely theoretical, whereas the need for a small-vector is
seemingly not so theoretical.
Building blocks aren't that useful, because the real benefit from a
small-vector comes
when it can be used as a portable "vocabulary type", rather than
having a plethora of small-vectors
built from said building blocks. Sure, it's probably much more
"special-purpose" than
std::vector, but there is some evidence that it's not so
"special-purpose" that there wouldn't
exist a very good amount of use cases to provide it in the standard library.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 5 Jan 2016 16:00:20 +0100
Raw View
--001a1141997413647a0528977fc8
Content-Type: text/plain; charset=UTF-8
On Tue, Jan 5, 2016 at 3:22 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 5 January 2016 at 16:06, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
> > On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <alisdairm@me.com>
> wrote:
> >>
> >> I am not yet convinced that such a special-purpose container belongs
> >> in the main standard, the concern being how many more special-purpose
> >> containers would then follow the precedent. I think that is a
> worthwhile
> >> question to pursue though, either as part of this as a proposal, or as a
> >> separate follow-up.
> >
> >
> > I'm with Alisdair on this one. There are many many different data
> > structures with all sorts of different interfaces and performance
> profiles.
> > The standard containers do and should only cover a handful of the most
> > common general-purpose ones.
> >
> > I'd be much more interested in proposals that would make it easier and
> safer
> > to implement data structures like small_vector yourself. Implementing a
> > data structure to the level of sophistication of say std::vector (with
> all
> > the iterators and allocators and member types and specializations of
> various
> > things and so on) is way more work than it could be if we provided better
> > tools/primtivites/building-blocks to assist.
>
>
> Even so, there's fairly good amounts of evidence that a small-vector
> is a commonly
> used container, so concerns about that somehow opening the door for too
> many
> special-purpose containers, for whatever values of "too many" and
> "special-purpose",
> seem completely theoretical, whereas the need for a small-vector is
> seemingly not so theoretical.
> Building blocks aren't that useful, because the real benefit from a
> small-vector comes
> when it can be used as a portable "vocabulary type", rather than
> having a plethora of small-vectors
> built from said building blocks. Sure, it's probably much more
> "special-purpose" than
> std::vector, but there is some evidence that it's not so
> "special-purpose" that there wouldn't
> exist a very good amount of use cases to provide it in the standard
> library.
I concede that the amount of existing practice is compelling. I do not
agree that small_vector is a vocabulary type. It is just a different
flavor of std::vector with slightly different (not even asymptotic)
time-space tradeoffs. I find it hard to imagine it crossing library
boundaries. I'm under the impression it is used mainly as an internal
performance optimization, maybe even prematurely/unsuccesfully in some
cases. The heap allocator usually does a pretty damn good job with small
blocks anyway.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1141997413647a0528977fc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jan 5, 2016 at 3:22 PM, Ville Voutilainen <span dir=3D"ltr"><=
;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vou=
tilainen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div class=3D"HOEnZb"><div class=3D"h5">On 5 January 2016 at 16:06, Andrew =
Tomazos <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.=
com</a>> wrote:<br>
> On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <<a href=3D"mailt=
o:alisdairm@me.com">alisdairm@me.com</a>> wrote:<br>
>><br>
>> I am not yet convinced that such a special-purpose container belon=
gs<br>
>> in the main standard, the concern being how many more special-purp=
ose<br>
>> containers would then follow the precedent.=C2=A0 I think that is =
a worthwhile<br>
>> question to pursue though, either as part of this as a proposal, o=
r as a<br>
>> separate follow-up.<br>
><br>
><br>
> I'm with Alisdair on this one.=C2=A0 There are many many different=
data<br>
> structures with all sorts of different interfaces and performance prof=
iles.<br>
> The standard containers do and should only cover a handful of the most=
<br>
> common general-purpose ones.<br>
><br>
> I'd be much more interested in proposals that would make it easier=
and safer<br>
> to implement data structures like small_vector yourself.=C2=A0 Impleme=
nting a<br>
> data structure to the level of sophistication of say std::vector (with=
all<br>
> the iterators and allocators and member types and specializations of v=
arious<br>
> things and so on) is way more work than it could be if we provided bet=
ter<br>
> tools/primtivites/building-blocks to assist.<br>
<br>
<br>
</div></div>Even so, there's fairly good amounts of evidence that a sma=
ll-vector<br>
is a commonly<br>
used container, so concerns about that somehow opening the door for too man=
y<br>
special-purpose containers, for whatever values of "too many" and=
<br>
"special-purpose",<br>
seem completely theoretical, whereas the need for a small-vector is<br>
seemingly not so theoretical.<br>
Building blocks aren't that useful, because the real benefit from a<br>
small-vector comes<br>
when it can be used as a portable "vocabulary type", rather than<=
br>
having a plethora of small-vectors<br>
built from said building blocks. Sure, it's probably much more<br>
"special-purpose" than<br>
std::vector, but there is some evidence that it's not so<br>
"special-purpose" that there wouldn't<br>
exist a very good amount of use cases to provide it in the standard library=
..</blockquote><div><br></div><div>I concede that the amount of existing pra=
ctice is compelling.=C2=A0 I do not agree that small_vector is a vocabulary=
type.=C2=A0 It is just a different flavor of std::vector with slightly dif=
ferent (not even asymptotic) time-space tradeoffs.=C2=A0 I find it hard to =
imagine it crossing library boundaries.=C2=A0 I'm under the impression =
it is used mainly as an internal performance optimization, maybe even prema=
turely/unsuccesfully in some cases.=C2=A0 The heap allocator usually does a=
pretty damn good job with small blocks anyway.</div><div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1141997413647a0528977fc8--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Jan 2016 17:10:13 +0200
Raw View
On 5 January 2016 at 17:00, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> I concede that the amount of existing practice is compelling. I do not
> agree that small_vector is a vocabulary type. It is just a different flavor
> of std::vector with slightly different (not even asymptotic) time-space
> tradeoffs. I find it hard to imagine it crossing library boundaries. I'm
Those tradeoffs, and their repercussions, are apparently sufficiently
different that
many people think it shouldn't and can't be a "flavor of std::vector".
> under the impression it is used mainly as an internal performance
> optimization, maybe even prematurely/unsuccesfully in some cases. The heap
> allocator usually does a pretty damn good job with small blocks anyway.
Whether it crosses library boundaries or not doesn't make or not make
it a vocabulary
type. It's a type that tends to cross other boundaries that have
different programmers
and different teams on the ends of those boundaries, so practically it
helps them
decide what type to choose if one is readily available, rather than
just an ephemeral
idea out of which a concrete type can be built if certain building
blocks are combined
just the right way.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 05 Jan 2016 10:33:44 -0500
Raw View
On 2016-01-05 10:00, Andrew Tomazos wrote:
> I concede that the amount of existing practice is compelling. I do not
> agree that small_vector is a vocabulary type. It is just a different
> flavor of std::vector with slightly different (not even asymptotic)
> time-space tradeoffs.
....and other "gotchas" like swap invalidating iterators.
> I'm under the impression it is used mainly as an internal performance
> optimization, maybe even prematurely/unsuccesfully in some cases.
> The heap allocator usually does a pretty damn good job with small
> blocks anyway.
No matter how perfect the heap allocator may be, it can't escape cache
non-locality...
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jan 2016 07:36:25 -0800 (PST)
Raw View
------=_Part_4564_1717761298.1452008185941
Content-Type: multipart/alternative;
boundary="----=_Part_4565_490653773.1452008185941"
------=_Part_4565_490653773.1452008185941
Content-Type: text/plain; charset=UTF-8
Details for any eventual proposal:
1) Make sure that `small_vector` can be moved into/outof regular `vector`.
Obviously, they must use compatible allocator types. Also obviously, if the
incoming `vector` is smaller than the small size, then no memory allocation
takes place and the old `vector` doesn't necessarily lose its memory. It
would then look like a copy operation, and it would only be noexcept if the
copy for `T` were noexcept.
2) Since the number of "small" elements is stated up-front, there should be
a function to ask "are you heap allocated yet?", rather than asking for the
capacity and comparing it to the small element count.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4565_490653773.1452008185941
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Details for any eventual proposal:<br><br>1) Make sure tha=
t `small_vector` can be moved into/outof regular `vector`. Obviously, they =
must use compatible allocator types. Also obviously, if the incoming `vecto=
r` is smaller than the small size, then no memory allocation takes place an=
d the old `vector` doesn't necessarily lose its memory. It would then l=
ook like a copy operation, and it would only be noexcept if the copy for `T=
` were noexcept.<br><br>2) Since the number of "small" elements i=
s stated up-front, there should be a function to ask "are you heap all=
ocated yet?", rather than asking for the capacity and comparing it to =
the small element count.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_4565_490653773.1452008185941--
------=_Part_4564_1717761298.1452008185941--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 5 Jan 2016 09:44:35 -0600
Raw View
--001a1145a83aac647e0528981f9b
Content-Type: text/plain; charset=UTF-8
On 5 January 2016 at 09:36, Nicol Bolas <jmckesson@gmail.com> wrote:
> Details for any eventual proposal:
>
> 1) Make sure that `small_vector` can be moved into/outof regular `vector`.
> Obviously, they must use compatible allocator types. Also obviously, if the
> incoming `vector` is smaller than the small size, then no memory allocation
> takes place and the old `vector` doesn't necessarily lose its memory. It
> would then look like a copy operation, and it would only be noexcept if the
> copy for `T` were noexcept.
>
What is the motivation? This seems like a lot of complexity for an
incredibly minor use case.
> 2) Since the number of "small" elements is stated up-front, there should
> be a function to ask "are you heap allocated yet?", rather than asking for
> the capacity and comparing it to the small element count.
>
While I don't see much motivation for this as well, it is fairly easy to
provide.
__
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1145a83aac647e0528981f9b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 5 January 2016 at 09:36, Nicol Bolas <span dir=3D"ltr">=
<<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Details for any e=
ventual proposal:<br><br>1) Make sure that `small_vector` can be moved into=
/outof regular `vector`. Obviously, they must use compatible allocator type=
s. Also obviously, if the incoming `vector` is smaller than the small size,=
then no memory allocation takes place and the old `vector` doesn't nec=
essarily lose its memory. It would then look like a copy operation, and it =
would only be noexcept if the copy for `T` were noexcept.<br></div></blockq=
uote><div><br></div><div>What is the motivation?=C2=A0 This seems like a lo=
t of complexity for an incredibly minor use case.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">2) Since the number of "s=
mall" elements is stated up-front, there should be a function to ask &=
quot;are you heap allocated yet?", rather than asking for the capacity=
and comparing it to the small element count.<br></div></blockquote><div><b=
r></div><div>While I don't see much motivation for this as well, it is =
fairly easy to provide.</div><div>__=C2=A0</div></div><div class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)=
" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" tar=
get=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></=
div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1145a83aac647e0528981f9b--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jan 2016 07:48:00 -0800 (PST)
Raw View
------=_Part_7079_1621889355.1452008880707
Content-Type: multipart/alternative;
boundary="----=_Part_7080_1352972577.1452008880708"
------=_Part_7080_1352972577.1452008880708
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 5, 2016 at 10:00:23 AM UTC-5, Andrew Tomazos wrote:
>
> On Tue, Jan 5, 2016 at 3:22 PM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 5 January 2016 at 16:06, Andrew Tomazos <andrew...@gmail.com
>> <javascript:>> wrote:
>> > On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <alis...@me.com
>> <javascript:>> wrote:
>> >>
>> >> I am not yet convinced that such a special-purpose container belongs
>> >> in the main standard, the concern being how many more special-purpose
>> >> containers would then follow the precedent. I think that is a
>> worthwhile
>> >> question to pursue though, either as part of this as a proposal, or as
>> a
>> >> separate follow-up.
>> >
>> >
>> > I'm with Alisdair on this one. There are many many different data
>> > structures with all sorts of different interfaces and performance
>> profiles.
>> > The standard containers do and should only cover a handful of the most
>> > common general-purpose ones.
>> >
>> > I'd be much more interested in proposals that would make it easier and
>> safer
>> > to implement data structures like small_vector yourself. Implementing a
>> > data structure to the level of sophistication of say std::vector (with
>> all
>> > the iterators and allocators and member types and specializations of
>> various
>> > things and so on) is way more work than it could be if we provided
>> better
>> > tools/primtivites/building-blocks to assist.
>>
>>
>> Even so, there's fairly good amounts of evidence that a small-vector
>> is a commonly
>> used container, so concerns about that somehow opening the door for too
>> many
>> special-purpose containers, for whatever values of "too many" and
>> "special-purpose",
>> seem completely theoretical, whereas the need for a small-vector is
>> seemingly not so theoretical.
>> Building blocks aren't that useful, because the real benefit from a
>> small-vector comes
>> when it can be used as a portable "vocabulary type", rather than
>> having a plethora of small-vectors
>> built from said building blocks. Sure, it's probably much more
>> "special-purpose" than
>> std::vector, but there is some evidence that it's not so
>> "special-purpose" that there wouldn't
>> exist a very good amount of use cases to provide it in the standard
>> library.
>
>
> I concede that the amount of existing practice is compelling. I do not
> agree that small_vector is a vocabulary type. It is just a different
> flavor of std::vector with slightly different (not even asymptotic)
> time-space tradeoffs. I find it hard to imagine it crossing library
> boundaries. I'm under the impression it is used mainly as an internal
> performance optimization, maybe even prematurely/unsuccesfully in some
> cases. The heap allocator usually does a pretty damn good job with small
> blocks anyway.
>
Let's assume for a moment that this is true. Let's take it for granted that
`small_vector` doesn't qualify as a "vocabulary type", that it's just a
"different flavor of std::vector".
Two things. First, we have library fundamentals TS's. Why can't we stick
such types in there?
It seems to me that the library fundamentals TS is the perfect place for
container types that aren't "vocabulary types" yet are in strong demand by
the community. They wouldn't be a core part of the standard, so they
wouldn't interfere with the notion that the standard library should only
have vocabulary types.
Second... there are lots of things being standardized that are not
"vocabulary types". Networking isn't vocabulary. Filesystem isn't
vocabulary. There are strong pushes to get these, not just into TS's, but
into the core C++ standard.
So it seems to me that the "vocabulary types" ship has long since sailed.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7080_1352972577.1452008880708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 5, 2016 at 10:00:23 AM UTC-5, Andrew Tomazos wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Tue, Jan 5, 2016 at 3:22 PM, Ville Voutilainen <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"ZKz_D9BhEwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">ville.vo...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div>On 5 January 2016 at 16:06, Andrew Tomazos <<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ZKz_D9BhEwAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">andrew...=
@gmail.com</a>> wrote:<br>
> On Mon, Jan 4, 2016 at 3:18 PM, Alisdair Meredith <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ZKz_D9BhEwAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">alis...@me.com</a>>=
; wrote:<br>
>><br>
>> I am not yet convinced that such a special-purpose container belon=
gs<br>
>> in the main standard, the concern being how many more special-purp=
ose<br>
>> containers would then follow the precedent.=C2=A0 I think that is =
a worthwhile<br>
>> question to pursue though, either as part of this as a proposal, o=
r as a<br>
>> separate follow-up.<br>
><br>
><br>
> I'm with Alisdair on this one.=C2=A0 There are many many different=
data<br>
> structures with all sorts of different interfaces and performance prof=
iles.<br>
> The standard containers do and should only cover a handful of the most=
<br>
> common general-purpose ones.<br>
><br>
> I'd be much more interested in proposals that would make it easier=
and safer<br>
> to implement data structures like small_vector yourself.=C2=A0 Impleme=
nting a<br>
> data structure to the level of sophistication of say std::vector (with=
all<br>
> the iterators and allocators and member types and specializations of v=
arious<br>
> things and so on) is way more work than it could be if we provided bet=
ter<br>
> tools/primtivites/building-<wbr>blocks to assist.<br>
<br>
<br>
</div></div>Even so, there's fairly good amounts of evidence that a sma=
ll-vector<br>
is a commonly<br>
used container, so concerns about that somehow opening the door for too man=
y<br>
special-purpose containers, for whatever values of "too many" and=
<br>
"special-purpose",<br>
seem completely theoretical, whereas the need for a small-vector is<br>
seemingly not so theoretical.<br>
Building blocks aren't that useful, because the real benefit from a<br>
small-vector comes<br>
when it can be used as a portable "vocabulary type", rather than<=
br>
having a plethora of small-vectors<br>
built from said building blocks. Sure, it's probably much more<br>
"special-purpose" than<br>
std::vector, but there is some evidence that it's not so<br>
"special-purpose" that there wouldn't<br>
exist a very good amount of use cases to provide it in the standard library=
..</blockquote><div><br></div><div>I concede that the amount of existing pra=
ctice is compelling.=C2=A0 I do not agree that small_vector is a vocabulary=
type.=C2=A0 It is just a different flavor of std::vector with slightly dif=
ferent (not even asymptotic) time-space tradeoffs.=C2=A0 I find it hard to =
imagine it crossing library boundaries.=C2=A0 I'm under the impression =
it is used mainly as an internal performance optimization, maybe even prema=
turely/unsuccesfully in some cases.=C2=A0 The heap allocator usually does a=
pretty damn good job with small blocks anyway.</div></div></div></div></bl=
ockquote><div><br>Let's assume for a moment that this is true. Let'=
s take it for granted that `small_vector` doesn't qualify as a "vo=
cabulary type", that it's just a "different flavor of std::ve=
ctor".<br><br>Two things. First, we have library fundamentals TS's=
.. Why can't we stick such types in there?<br><br>It seems to me that th=
e library fundamentals TS is the perfect place for container types that are=
n't "vocabulary types" yet are in strong demand by the commun=
ity. They wouldn't be a core part of the standard, so they wouldn't=
interfere with the notion that the standard library should only have vocab=
ulary types.<br><br>Second... there are lots of things being standardized t=
hat are not "vocabulary types". Networking isn't vocabulary. =
Filesystem isn't vocabulary. There are strong pushes to get these, not =
just into TS's, but into the core C++ standard.<br><br>So it seems to m=
e that the "vocabulary types" ship has long since sailed.<br></di=
v>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_7080_1352972577.1452008880708--
------=_Part_7079_1621889355.1452008880707--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Jan 2016 17:54:46 +0200
Raw View
On 5 January 2016 at 17:48, Nicol Bolas <jmckesson@gmail.com> wrote:
> Let's assume for a moment that this is true. Let's take it for granted that
> `small_vector` doesn't qualify as a "vocabulary type", that it's just a
> "different flavor of std::vector".
> Two things. First, we have library fundamentals TS's. Why can't we stick
> such types in there?
So as to keep such types there without ever moving them to the main standard?
Yes, technically we could do that.
> It seems to me that the library fundamentals TS is the perfect place for
> container types that aren't "vocabulary types" yet are in strong demand by
> the community. They wouldn't be a core part of the standard, so they
> wouldn't interfere with the notion that the standard library should only
> have vocabulary types.
Or if we have problems with the word "fundamentals", we could well come up
with a separate "Batteries Included TS". :)
> Second... there are lots of things being standardized that are not
> "vocabulary types". Networking isn't vocabulary. Filesystem isn't
> vocabulary. There are strong pushes to get these, not just into TS's, but
> into the core C++ standard.
> So it seems to me that the "vocabulary types" ship has long since sailed.
That may well be, but it still requires committee agreement to add types into
any TS, and some are going to argue that they don't agree on the applicability
of whatever type to be broad enough to ship such types in any standard document,
TS or IS. ;)
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jan 2016 07:59:38 -0800 (PST)
Raw View
------=_Part_125_464937097.1452009578993
Content-Type: multipart/alternative;
boundary="----=_Part_126_1632362068.1452009578993"
------=_Part_126_1632362068.1452009578993
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 5, 2016 at 10:45:16 AM UTC-5, Nevin ":-)" Liber wrote:
>
> On 5 January 2016 at 09:36, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> Details for any eventual proposal:
>>
>> 1) Make sure that `small_vector` can be moved into/outof regular
>> `vector`. Obviously, they must use compatible allocator types. Also
>> obviously, if the incoming `vector` is smaller than the small size, then no
>> memory allocation takes place and the old `vector` doesn't necessarily lose
>> its memory. It would then look like a copy operation, and it would only be
>> noexcept if the copy for `T` were noexcept.
>>
>
> What is the motivation? This seems like a lot of complexity for an
> incredibly minor use case.
>
If an API takes a vector, and I use a small_vector (or vice-versa), I want
to be able to transfer that information with the fastest performance
possible. After all, `small_vector` exists for performance reasons. We
wouldn't want to do things to make code slower.
This should also extend to different `small_vector` types that have
different small element 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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_126_1632362068.1452009578993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, January 5, 2016 at 10:45:16 AM UTC-5, Nevin ":-)&q=
uot; Liber wrote:<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 5 January 2016 at 09:36, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rMkZMkNkEwAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gmai=
l.com</a>></span> wrote:<br><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 dir=3D"ltr">Details for any eventual proposal:<br><=
br>1) Make sure that `small_vector` can be moved into/outof regular `vector=
`. Obviously, they must use compatible allocator types. Also obviously, if =
the incoming `vector` is smaller than the small size, then no memory alloca=
tion takes place and the old `vector` doesn't necessarily lose its memo=
ry. It would then look like a copy operation, and it would only be noexcept=
if the copy for `T` were noexcept.<br></div></blockquote><div><br></div><d=
iv>What is the motivation?=C2=A0 This seems like a lot of complexity for an=
incredibly minor use case.</div></div></div></div></blockquote><div><br>If=
an API takes a vector, and I use a small_vector (or vice-versa), I want to=
be able to transfer that information with the fastest performance possible=
.. After all, `small_vector` exists for performance reasons. We wouldn't=
want to do things to make code slower.<br><br>This should also extend to d=
ifferent `small_vector` types that have different small element counts.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_126_1632362068.1452009578993--
------=_Part_125_464937097.1452009578993--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 5 Jan 2016 10:15:27 -0600
Raw View
--089e01176ba30f02270528988e7d
Content-Type: text/plain; charset=UTF-8
On 5 January 2016 at 09:59, Nicol Bolas <jmckesson@gmail.com> wrote:
> If an API takes a vector, and I use a small_vector (or vice-versa), I want
> to be able to transfer that information with the fastest performance
> possible. After all, `small_vector` exists for performance reasons. We
> wouldn't want to do things to make code slower.
>
While there may be pathological cases that can be micro-optimized, I'm not
seeing why I just wouldn't use vector in this case.
Do you also suggest specializing small_vector<bool> for this type
exchangeability as well?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01176ba30f02270528988e7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 5 January 2016 at 09:59, Nic=
ol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targe=
t=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>If an API takes a vector, and=
I use a small_vector (or vice-versa), I want to be able to transfer that i=
nformation with the fastest performance possible. After all, `small_vector`=
exists for performance reasons. We wouldn't want to do things to make =
code slower.<br></div></blockquote></div><br>While there may be pathologica=
l cases that can be micro-optimized, I'm not seeing why I just wouldn&#=
39;t use vector in this case.</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">Do you also suggest specializing small_vector<bo=
ol> for this type exchangeability as well?</div><div class=3D"gmail_extr=
a">-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"=
ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
; =C2=A0+1-847-691-1404</div></div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e01176ba30f02270528988e7d--
.
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Tue, 5 Jan 2016 23:30:20 -0800 (PST)
Raw View
------=_Part_15604_1564569794.1452065420937
Content-Type: multipart/alternative;
boundary="----=_Part_15605_1825924800.1452065420937"
------=_Part_15605_1825924800.1452065420937
Content-Type: text/plain; charset=UTF-8
On Wednesday, 6 January 2016 04:59:39 UTC+13, Nicol Bolas wrote:
>
>
>
> On Tuesday, January 5, 2016 at 10:45:16 AM UTC-5, Nevin ":-)" Liber wrote:
>>
>> On 5 January 2016 at 09:36, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> Details for any eventual proposal:
>>>
>>> 1) Make sure that `small_vector` can be moved into/outof regular
>>> `vector`. Obviously, they must use compatible allocator types. Also
>>> obviously, if the incoming `vector` is smaller than the small size, then no
>>> memory allocation takes place and the old `vector` doesn't necessarily lose
>>> its memory. It would then look like a copy operation, and it would only be
>>> noexcept if the copy for `T` were noexcept.
>>>
>>
>> What is the motivation? This seems like a lot of complexity for an
>> incredibly minor use case.
>>
>
> If an API takes a vector, and I use a small_vector (or vice-versa), I want
> to be able to transfer that information with the fastest performance
> possible. After all, `small_vector` exists for performance reasons. We
> wouldn't want to do things to make code slower.
>
> This should also extend to different `small_vector` types that have
> different small element counts.
>
Let's view a `vector<T>` as being the special case `small_vector<T, 0>`,
i.e. zero elements preallocated*. Then imagine we had a move operation
small_vector<T, N> -> small_vector<T, M>
The only time this will actually be a move and not a copy is if the size of
the source vector is greater than both N and M. In every other case, you
will either be copying from the embedded storage of the source, copying
into the embedded storage of the target, or both.
I would suggest that if you are overflowing the preallocated storage often
enough that this single move case makes a difference to performance, then
you shouldn't be using a `small_vector` at all.
* FWIW, I would advocate prohibiting `small_vector<T, 0>` for precisely
this reason.
Tristan
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_15605_1825924800.1452065420937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, 6 January 2016 04:59:39 UTC+13, Nicol Bolas wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tuesday, January 5, 2=
016 at 10:45:16 AM UTC-5, Nevin ":-)" Liber wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">On 5 January 2016 at 09:36, Nicol=
Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>><=
/span> wrote:<br><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 dir=3D"ltr">Details for any eventual proposal:<br><br>1) Make sur=
e that `small_vector` can be moved into/outof regular `vector`. Obviously, =
they must use compatible allocator types. Also obviously, if the incoming `=
vector` is smaller than the small size, then no memory allocation takes pla=
ce and the old `vector` doesn't necessarily lose its memory. It would t=
hen look like a copy operation, and it would only be noexcept if the copy f=
or `T` were noexcept.<br></div></blockquote><div><br></div><div>What is the=
motivation?=C2=A0 This seems like a lot of complexity for an incredibly mi=
nor use case.</div></div></div></div></blockquote><div><br>If an API takes =
a vector, and I use a small_vector (or vice-versa), I want to be able to tr=
ansfer that information with the fastest performance possible. After all, `=
small_vector` exists for performance reasons. We wouldn't want to do th=
ings to make code slower.<br><br>This should also extend to different `smal=
l_vector` types that have different small element counts.<br></div></blockq=
uote><div><br></div><div>Let's view a `vector<T>` as being the sp=
ecial case `small_vector<T, 0>`, i.e. zero elements preallocated*. Th=
en imagine we had a move operation</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0small_vector<T, N> -> small_vector<T, M></div><div><br=
></div><div>The only time this will actually be a move and not a copy is if=
the size of the source vector is greater than both N and M. In every other=
case, you will either be copying from the embedded storage of the source, =
copying into the embedded storage of the target, or both.</div><div><br></d=
iv><div>I would suggest that if you are overflowing the preallocated storag=
e often enough that this single move case makes a difference to performance=
, then you shouldn't be using a `small_vector` at all.</div><div><br></=
div><div><br></div><div>* FWIW, I would advocate prohibiting `small_vector&=
lt;T, 0>` for precisely this reason.</div><div><br></div><div><br></div>=
<div>Tristan</div><div><br></div><div><br></div><div>=C2=A0</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_15605_1825924800.1452065420937--
------=_Part_15604_1564569794.1452065420937--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 13:48:32 +0100
Raw View
--047d7ba972228ae5ff0528a9c56a
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 8:30 AM, Tristan Brindle <tcbrindle@gmail.com> wrote:
>
>
> On Wednesday, 6 January 2016 04:59:39 UTC+13, Nicol Bolas wrote:
>>
>>
>>
>> On Tuesday, January 5, 2016 at 10:45:16 AM UTC-5, Nevin ":-)" Liber wrote:
>>>
>>> On 5 January 2016 at 09:36, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> Details for any eventual proposal:
>>>>
>>>> 1) Make sure that `small_vector` can be moved into/outof regular
>>>> `vector`. Obviously, they must use compatible allocator types. Also
>>>> obviously, if the incoming `vector` is smaller than the small size, then no
>>>> memory allocation takes place and the old `vector` doesn't necessarily lose
>>>> its memory. It would then look like a copy operation, and it would only be
>>>> noexcept if the copy for `T` were noexcept.
>>>>
>>>
>>> What is the motivation? This seems like a lot of complexity for an
>>> incredibly minor use case.
>>>
>>
>> If an API takes a vector, and I use a small_vector (or vice-versa), I
>> want to be able to transfer that information with the fastest performance
>> possible. After all, `small_vector` exists for performance reasons. We
>> wouldn't want to do things to make code slower.
>>
>> This should also extend to different `small_vector` types that have
>> different small element counts.
>>
>
> Let's view a `vector<T>` as being the special case `small_vector<T, 0>`,
> i.e. zero elements preallocated*. Then imagine we had a move operation
>
I'm not sure if the idea was discussed previously, but the above statement
admits an idea - another option, instead of providing a separate
small_vector class template - would be to add another template parameter to
std::vector. That being "size_t num_preallocated_elements = 0". As shown
defaulting to 0. The existing std::vector requirements/constraints that
are incompatible with preallocated elements would then be adjusted to only
apply when num_preallocated_elements is 0.
Not sure if this is a good or bad idea quite yet - but may be worth
exploring.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7ba972228ae5ff0528a9c56a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 8:30 AM, Tristan Brindle <span dir=3D"ltr"><<=
a href=3D"mailto:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@gmail.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;padding-left:1ex"><span class=3D""><br><br>On Wedn=
esday, 6 January 2016 04:59:39 UTC+13, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<br><br>On Tuesday, January 5, 2016 at 10:45:16 AM UTC-5, Nevin ":-)&q=
uot; Liber wrote:<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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr">On 5 January 2016 at 09:=
36, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com=
</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr">Details for any eventual proposal:<br><br>1) Make sure tha=
t `small_vector` can be moved into/outof regular `vector`. Obviously, they =
must use compatible allocator types. Also obviously, if the incoming `vecto=
r` is smaller than the small size, then no memory allocation takes place an=
d the old `vector` doesn't necessarily lose its memory. It would then l=
ook like a copy operation, and it would only be noexcept if the copy for `T=
` were noexcept.<br></div></blockquote><div><br></div><div>What is the moti=
vation?=C2=A0 This seems like a lot of complexity for an incredibly minor u=
se case.</div></div></div></div></blockquote><div><br>If an API takes a vec=
tor, and I use a small_vector (or vice-versa), I want to be able to transfe=
r that information with the fastest performance possible. After all, `small=
_vector` exists for performance reasons. We wouldn't want to do things =
to make code slower.<br><br>This should also extend to different `small_vec=
tor` types that have different small element counts.<br></div></blockquote>=
<div><br></div></span><div>Let's view a `vector<T>` as being the =
special case `small_vector<T, 0>`, i.e. zero elements preallocated*. =
Then imagine we had a move operation</div></blockquote><div><br></div><div>=
I'm not sure if the idea was discussed previously, but the above statem=
ent admits an idea - another option, instead of providing a separate small_=
vector class template - would be to add another template parameter to std::=
vector.=C2=A0 That being "size_t num_preallocated_elements =3D 0"=
..=C2=A0 As shown defaulting to 0.=C2=A0 The existing std::vector requiremen=
ts/constraints that are incompatible with preallocated elements would then =
be adjusted to only apply when num_preallocated_elements is 0.</div><div><b=
r></div><div>Not sure if this is a good or bad idea quite yet - but may be =
worth exploring.</div><div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7ba972228ae5ff0528a9c56a--
.
Author: "Nevin \":-)\" Liber" <"Nevin ":-)" Liber" <nliber@gmail.com>>
Date: Wed, 6 Jan 2016 09:12:07 -0600
Raw View
> On Jan 6, 2016, at 6:48 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>
> Not sure if this is a good or bad idea quite yet - but may be worth exploring.
Adding a third parameter at the end is an ABI breakage and hinders usability, as most people rarely have to specify allocators.
Adding it as the second parameter breaks source for anyone using allocators or passing vectors generically.
The only benefit is reusing the name. Doesn't seem worth it to me.
Other than these trivially obvious concerns, what else makes this worth exploring?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-312-623-5420
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Nevin \":-)\" Liber" <"Nevin ":-)" Liber" <nliber@gmail.com>>
Date: Wed, 6 Jan 2016 09:13:56 -0600
Raw View
>
> On Jan 6, 2016, at 1:30 AM, Tristan Brindle <tcbrindle@gmail.com> wrote:
>
> FWIW, I would advocate prohibiting `small_vector<T, 0>` for precisely this reason.
I disagree. I'd love to use this to replace vector, at a minimum because it doesn't have a bool specialization.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-312-623-5420
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Wed, 6 Jan 2016 07:53:55 -0800 (PST)
Raw View
------=_Part_4001_310588336.1452095635427
Content-Type: multipart/alternative;
boundary="----=_Part_4002_2015107570.1452095635427"
------=_Part_4002_2015107570.1452095635427
Content-Type: text/plain; charset=UTF-8
On Thursday, 7 January 2016 04:14:01 UTC+13, Nevin ":-)" Liber wrote:
>
>
> I disagree. I'd love to use this to replace vector, at a minimum because
> it doesn't have a bool specialization.
>
>
I think phrase "replace vector" might be enough to cause some committee
members to have kittens, which is why I'd advocate forbidding the zero
case, at least to start with. The restriction can always be relaxed later
if there's good reason.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4002_2015107570.1452095635427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, 7 January 2016 04:14:01 UTC+13, Nevin=
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>I disagree. I'd love to use this to replace vector, at a minimum be=
cause it doesn't have a bool specialization.=20
<br><br></blockquote><div><br></div><div>I think phrase "replace vecto=
r" might be enough to cause some committee members to have kittens, wh=
ich is why I'd advocate forbidding the zero case, at least to start wit=
h. The restriction can always be relaxed later if there's good reason.<=
/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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_4002_2015107570.1452095635427--
------=_Part_4001_310588336.1452095635427--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 6 Jan 2016 10:04:21 -0600
Raw View
--089e01176ba33caed70528ac846e
Content-Type: text/plain; charset=UTF-8
On 6 January 2016 at 09:53, Tristan Brindle <tcbrindle@gmail.com> wrote:
>
>
> On Thursday, 7 January 2016 04:14:01 UTC+13, Nevin ":-)" Liber wrote:
>>
>>
>> I disagree. I'd love to use this to replace vector, at a minimum because
>> it doesn't have a bool specialization.
>>
>>
> I think phrase "replace vector" might be enough to cause some committee
> members to have kittens, which is why I'd advocate forbidding the zero
> case, at least to start with. The restriction can always be relaxed later
> if there's good reason.
>
And by not putting it in we harm its use in generic programming. We added
array<T, 0>; I see no reason not to add small_vector<T, 0, A>.
I'm not seeing any actual technical concerns; just FUD.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01176ba33caed70528ac846e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 January 2016 at 09:53, Tristan Brindle <span dir=3D"l=
tr"><<a href=3D"mailto:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@=
gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><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 dir=3D"ltr"><span class=
=3D""><br><br>On Thursday, 7 January 2016 04:14:01 UTC+13, Nevin ":-)&=
quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>I disagree. I'd love to use this to replace vector, at a minimum be=
cause it doesn't have a bool specialization.=20
<br><br></blockquote><div><br></div></span><div>I think phrase "replac=
e vector" might be enough to cause some committee members to have kitt=
ens, which is why I'd advocate forbidding the zero case, at least to st=
art with. The restriction can always be relaxed later if there's good r=
eason.</div></div></blockquote><div><br></div><div>And by not putting it in=
we harm its use in generic programming.=C2=A0 We added array<T, 0>; =
I see no reason not to add small_vector<T, 0, A>.</div><div><br></div=
><div>I'm not seeing any actual technical concerns; just FUD.</div></di=
v>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"l=
tr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=C2=A0+1-847-691-1404</div></div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e01176ba33caed70528ac846e--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 17:05:23 +0100
Raw View
--001a114242a48993d70528ac853d
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 4:12 PM, Nevin ":-)" Liber <nliber@gmail.com> wrote:
>
>
> > On Jan 6, 2016, at 6:48 AM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
> >
> > Not sure if this is a good or bad idea quite yet - but may be worth
> exploring.
>
> Adding a third parameter at the end is an ABI breakage and hinders
> usability, as most people rarely have to specify allocators.
>
> Adding it as the second parameter breaks source for anyone using
> allocators or passing vectors generically.
>
> The only benefit is reusing the name. Doesn't seem worth it to me.
>
You are underestimating the advantages I think. It's not just "reusing the
name", its reusing the entire template. It's conceptually simpler, easier
to specify, easier to implement, its a single class template definition
(the branch if (num_preallocated_elements > 0) would be optimized out in
the zero case). The interfaces and implementations of operations that
dispatch on two std::vectors of different num_preallocated_elements
(comparisons, conversions, etc, etc) would be cleaner.
I don't however have a good answer currently for your ABI and source
compatibility concerns.
Other than these trivially obvious concerns, what else makes this worth
> exploring?
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-312-623-5420
>
> --
>
> ---
> 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
> https://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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114242a48993d70528ac853d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 6, 2016 at 4:12 PM, Nevin ":-)" Liber <span dir=3D"ltr">&=
lt;<a href=3D"mailto:nliber@gmail.com" target=3D"_blank">nliber@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br=
>
<br>
> On Jan 6, 2016, at 6:48 AM, Andrew Tomazos <<a href=3D"mailto:andre=
wtomazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br>
><br>
> Not sure if this is a good or bad idea quite yet - but may be worth ex=
ploring.<br>
<br>
</span>Adding a third parameter at the end is an ABI breakage and hinders u=
sability, as most people rarely have to specify allocators.<br>
<br>
Adding it as the second parameter breaks source for anyone using allocators=
or passing vectors generically.<br>
<br>
The only benefit is reusing the name. Doesn't seem worth it to me.<br><=
/blockquote><div><br></div><div>You are underestimating the advantages I th=
ink.=C2=A0 It's not just "reusing the name", its reusing the =
entire template.=C2=A0 It's conceptually simpler, easier to specify, ea=
sier to implement, its a single class template definition (the branch if (n=
um_preallocated_elements > 0) would be optimized out in the zero case).=
=C2=A0 The interfaces and implementations of operations that dispatch on tw=
o std::vectors of different num_preallocated_elements (comparisons, convers=
ions, etc, etc) would be cleaner.</div><div><br></div><div>I don't howe=
ver have a good answer currently for your ABI and source compatibility conc=
erns.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Other than these trivially obvious concerns, what else makes this worth exp=
loring?<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
=C2=A0Nevin ":-)" Liber <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com">nevin@eviloverlord.com</a>>=C2=A0 <a href=3D"tel:%2B1-312-62=
3-5420" value=3D"+13126235420">+1-312-623-5420</a><br>
</font></span><div class=3D"HOEnZb"><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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114242a48993d70528ac853d--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 17:18:11 +0100
Raw View
--001a1147dc985180010528acb3e0
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 5:05 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
> On Wed, Jan 6, 2016 at 4:12 PM, Nevin ":-)" Liber <nliber@gmail.com>
> wrote:
>
>>
>>
>> > On Jan 6, 2016, at 6:48 AM, Andrew Tomazos <andrewtomazos@gmail.com>
>> wrote:
>> >
>> > Not sure if this is a good or bad idea quite yet - but may be worth
>> exploring.
>>
>> Adding a third parameter at the end is an ABI breakage and hinders
>> usability, as most people rarely have to specify allocators.
>>
>> Adding it as the second parameter breaks source for anyone using
>> allocators or passing vectors generically.
>>
>> The only benefit is reusing the name. Doesn't seem worth it to me.
>>
>
> You are underestimating the advantages I think. It's not just "reusing
> the name", its reusing the entire template. It's conceptually simpler,
> easier to specify, easier to implement, its a single class template
> definition (the branch if (num_preallocated_elements > 0) would be
> optimized out in the zero case). The interfaces and implementations of
> operations that dispatch on two std::vectors of different
> num_preallocated_elements (comparisons, conversions, etc, etc) would be
> cleaner.
>
> I don't however have a good answer currently for your ABI and source
> compatibility concerns.
>
An idea that addresses source compatibility maybe to pick a new name
(vector was always a silly name anyway, its not a mathematical vector,
valarray should have really been called vector) and then make vector an
alias template:
template<
class T,
size_t NumPreallocatedElements = 0,
class Allocator = std::allocator
<http://en.cppreference.com/w/cpp/memory/allocator><T>
>
class sequence { ... };
template<
class T,
class Allocator = std::allocator
<http://en.cppreference.com/w/cpp/memory/allocator><T>
> using vector = sequence<T,0,Allocator>;
If you don't like "sequence", an alternative name is "vararray".
Other than these trivially obvious concerns, what else makes this worth
>> exploring?
>> --
>> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-312-623-5420
>>
>> --
>>
>> ---
>> 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
>> https://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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1147dc985180010528acb3e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 5:05 PM, Andrew Tomazos <span dir=3D"ltr"><<a=
href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gm=
ail.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,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Jan =
6, 2016 at 4:12 PM, Nevin ":-)" Liber <span dir=3D"ltr"><<a hr=
ef=3D"mailto:nliber@gmail.com" target=3D"_blank">nliber@gmail.com</a>></=
span> wrote:<br><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"><span><br>
<br>
> On Jan 6, 2016, at 6:48 AM, Andrew Tomazos <<a href=3D"mailto:andre=
wtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>> wrote=
:<br>
><br>
> Not sure if this is a good or bad idea quite yet - but may be worth ex=
ploring.<br>
<br>
</span>Adding a third parameter at the end is an ABI breakage and hinders u=
sability, as most people rarely have to specify allocators.<br>
<br>
Adding it as the second parameter breaks source for anyone using allocators=
or passing vectors generically.<br>
<br>
The only benefit is reusing the name. Doesn't seem worth it to me.<br><=
/blockquote><div><br></div></span><div>You are underestimating the advantag=
es I think.=C2=A0 It's not just "reusing the name", its reusi=
ng the entire template.=C2=A0 It's conceptually simpler, easier to spec=
ify, easier to implement, its a single class template definition (the branc=
h if (num_preallocated_elements > 0) would be optimized out in the zero =
case).=C2=A0 The interfaces and implementations of operations that dispatch=
on two std::vectors of different num_preallocated_elements (comparisons, c=
onversions, etc, etc) would be cleaner.</div><div><br></div><div>I don'=
t however have a good answer currently for your ABI and source compatibilit=
y concerns.</div></div></div></div></blockquote><div>=C2=A0</div><div>An id=
ea that addresses source compatibility maybe to pick a new name (vector was=
always a silly name anyway, its not a mathematical vector, valarray should=
have really been called vector) and then make vector an alias template:</d=
iv><div><br></div><div><span class=3D"" style=3D"line-height:14.08px;margin=
:0px;padding:0px;color:rgb(0,0,221);font-family:DejaVuSansMono,'DejaVu =
Sans Mono',courier,monospace;font-size:12.8px;white-space:nowrap">templ=
ate</span><span class=3D"" style=3D"line-height:14.08px;margin:0px;padding:=
0px;color:rgb(0,0,128);font-family:DejaVuSansMono,'DejaVu Sans Mono'=
;,courier,monospace;font-size:12.8px;white-space:nowrap"><</span><br sty=
le=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,'DejaVu Sans Mono'=
;,courier,monospace;font-size:12.8px;line-height:14.08px;white-space:nowrap=
"><p style=3D"margin:0px;line-height:14.08px;padding:0px;color:rgb(0,0,0);f=
ont-family:DejaVuSansMono,'DejaVu Sans Mono',courier,monospace;font=
-size:12.8px;white-space:nowrap">=C2=A0 =C2=A0=C2=A0<span class=3D"" style=
=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,221)">class</spa=
n>=C2=A0T,</p><p style=3D"margin:0px;line-height:14.08px;padding:0px;color:=
rgb(0,0,0);font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,mo=
nospace;font-size:12.8px;white-space:nowrap">=C2=A0 =C2=A0 size_t NumPreall=
ocatedElements =3D 0,<br>=C2=A0 =C2=A0=C2=A0<span class=3D"" style=3D"line-=
height:1.1em;margin:0px;padding:0px;color:rgb(0,0,221)">class</span>=C2=A0A=
llocator=C2=A0<span class=3D"" style=3D"line-height:1.1em;margin:0px;paddin=
g:0px;color:rgb(0,0,128)">=3D</span>=C2=A0<a href=3D"http://en.cppreference=
..com/w/cpp/memory/allocator" style=3D"color:rgb(0,48,128);text-decoration:n=
one;background:none"><span class=3D"" style=3D"line-height:1.1em;margin:0px=
;padding:0px">std::<span class=3D"" style=3D"line-height:1.1em;margin:0px;p=
adding:0px">allocator</span></span></a><span class=3D"" style=3D"line-heigh=
t:1.1em;margin:0px;padding:0px;color:rgb(0,0,128)"><</span>T<span class=
=3D"" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,128)"=
>></span><br></p><div><span class=3D"" style=3D"line-height:1.1em;margin=
:0px;padding:0px;color:rgb(0,0,128)">></span></div><div><span class=3D""=
style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,128)">clas=
s sequence { ... };</span></div><div><br></div><span class=3D"" style=3D"li=
ne-height:14.08px;margin:0px;padding:0px;color:rgb(0,0,128);font-family:Dej=
aVuSansMono,'DejaVu Sans Mono',courier,monospace;font-size:12.8px;w=
hite-space:nowrap"></span></div><div><span class=3D"" style=3D"line-height:=
14.08px;margin:0px;padding:0px;color:rgb(0,0,221);font-family:DejaVuSansMon=
o,'DejaVu Sans Mono',courier,monospace;font-size:12.8px;white-space=
:nowrap">template</span><span class=3D"" style=3D"line-height:14.08px;margi=
n:0px;padding:0px;color:rgb(0,0,128);font-family:DejaVuSansMono,'DejaVu=
Sans Mono',courier,monospace;font-size:12.8px;white-space:nowrap"><=
</span><br style=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,'DejaVu=
Sans Mono',courier,monospace;font-size:12.8px;line-height:14.08px;whit=
e-space:nowrap"><p style=3D"margin:0px;line-height:14.08px;padding:0px;colo=
r:rgb(0,0,0);font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,=
monospace;font-size:12.8px;white-space:nowrap">=C2=A0 =C2=A0=C2=A0<span cla=
ss=3D"" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,221=
)">class</span>=C2=A0T,<br>=C2=A0 =C2=A0=C2=A0<span class=3D"" style=3D"lin=
e-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,221)">class</span>=C2=
=A0Allocator=C2=A0<span class=3D"" style=3D"line-height:1.1em;margin:0px;pa=
dding:0px;color:rgb(0,0,128)">=3D</span>=C2=A0<a href=3D"http://en.cpprefer=
ence.com/w/cpp/memory/allocator" style=3D"text-decoration:none;color:rgb(0,=
48,128);background:none"><span class=3D"" style=3D"line-height:1.1em;margin=
:0px;padding:0px">std::<span class=3D"" style=3D"line-height:1.1em;margin:0=
px;padding:0px">allocator</span></span></a><span class=3D"" style=3D"line-h=
eight:1.1em;margin:0px;padding:0px;color:rgb(0,0,128)"><</span>T<span cl=
ass=3D"" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb(0,0,12=
8)">></span><br></p><span class=3D"" style=3D"line-height:14.08px;margin=
:0px;padding:0px;color:rgb(0,0,128);font-family:DejaVuSansMono,'DejaVu =
Sans Mono',courier,monospace;font-size:12.8px;white-space:nowrap">><=
/span><span style=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,'DejaV=
u Sans Mono',courier,monospace;font-size:12.8px;line-height:14.08px;whi=
te-space:nowrap">=C2=A0</span><span class=3D"" style=3D"line-height:14.08px=
;margin:0px;padding:0px;color:rgb(0,0,221);font-family:DejaVuSansMono,'=
DejaVu Sans Mono',courier,monospace;font-size:12.8px;white-space:nowrap=
">using</span><span style=3D"color:rgb(0,0,0);font-family:DejaVuSansMono,&#=
39;DejaVu Sans Mono',courier,monospace;font-size:12.8px;line-height:14.=
08px;white-space:nowrap">=C2=A0vector =3D sequence<T,0,Allocator></sp=
an><span class=3D"" style=3D"line-height:14.08px;margin:0px;padding:0px;col=
or:rgb(0,128,128);font-family:DejaVuSansMono,'DejaVu Sans Mono',cou=
rier,monospace;font-size:12.8px;white-space:nowrap">;</span><br></div><div>=
<span class=3D"" style=3D"line-height:14.08px;margin:0px;padding:0px;color:=
rgb(0,128,128);font-family:DejaVuSansMono,'DejaVu Sans Mono',courie=
r,monospace;font-size:12.8px;white-space:nowrap"><br></span></div><div><spa=
n class=3D"" style=3D"line-height:14.08px;margin:0px;padding:0px;color:rgb(=
0,128,128);font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,mo=
nospace;font-size:12.8px;white-space:nowrap">If you don't like "se=
quence", an alternative name is "vararray".</span></div><div=
><span class=3D"" style=3D"line-height:14.08px;margin:0px;padding:0px;color=
:rgb(0,128,128);font-family:DejaVuSansMono,'DejaVu Sans Mono',couri=
er,monospace;font-size:12.8px;white-space:nowrap"><br></span></div><div><br=
></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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span class=3D""><div></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">
Other than these trivially obvious concerns, what else makes this worth exp=
loring?<br>
<span><font color=3D"#888888">--<br>
=C2=A0Nevin ":-)" Liber <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 <a href=
=3D"tel:%2B1-312-623-5420" value=3D"+13126235420" target=3D"_blank">+1-312-=
623-5420</a><br>
</font></span><div><div><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" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></span></div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1147dc985180010528acb3e0--
.
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Thu, 7 Jan 2016 05:46:06 +1300
Raw View
> On 7/01/2016, at 5:04 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>=20
> And by not putting it in we harm its use in generic programming. We adde=
d array<T, 0>; I see no reason not to add small_vector<T, 0, A>.
>=20
That=E2=80=99s a good point. I hadn=E2=80=99t considered the generic progra=
mming aspect. The symmetry with `array` is appealing.
> I'm not seeing any actual technical concerns; just FUD.
Sure. The technical concern is that `small_vector<T, 0>` winds up being ide=
ntical to `vector<T>`, except that the two cannot be interchanged. Having t=
wo ways to say the same thing is never good, particularly for a type as fun=
damental and widely used as vector.
On the other hand, perhaps we could frame the discussion differently. The =
=E2=80=9Csmall vector=E2=80=9D being discussed here is really a generalisat=
ion of vector, similar to how `tuple` is a generalisation of `pair` =E2=80=
=94 both of which still exist, despite the latter being technically redunda=
nt.
Looking at it this way, `small_vector` is actually a poor name choice. Perh=
aps a better name would be `varray`, or variable array. If we default the s=
econd template argument, then `varray` becomes a drop-in replacement for `v=
ector`, except without the `vector<bool>` legacy. It also evokes `dynarray`=
, and covers many of the same use-cases (i.e. vector semantics on the stack=
), but requires no core language changes.
Hmmm...
--
Tristan
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 17:51:40 +0100
Raw View
--001a114199740e0e030528ad2ba9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jan 6, 2016 at 5:46 PM, Tristan Brindle <tcbrindle@gmail.com> wrote=
:
>
> > On 7/01/2016, at 5:04 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> >
> > And by not putting it in we harm its use in generic programming. We
> added array<T, 0>; I see no reason not to add small_vector<T, 0, A>.
> >
>
> That=E2=80=99s a good point. I hadn=E2=80=99t considered the generic prog=
ramming aspect.
> The symmetry with `array` is appealing.
>
>
> > I'm not seeing any actual technical concerns; just FUD.
>
> Sure. The technical concern is that `small_vector<T, 0>` winds up being
> identical to `vector<T>`, except that the two cannot be interchanged.
> Having two ways to say the same thing is never good, particularly for a
> type as fundamental and widely used as vector.
>
> On the other hand, perhaps we could frame the discussion differently. The
> =E2=80=9Csmall vector=E2=80=9D being discussed here is really a generalis=
ation of vector,
> similar to how `tuple` is a generalisation of `pair` =E2=80=94 both of wh=
ich still
> exist, despite the latter being technically redundant.
>
> Looking at it this way, `small_vector` is actually a poor name choice.
> Perhaps a better name would be `varray`, or variable array. If we default
> the second template argument, then `varray` becomes a drop-in replacement
> for `vector`, except without the `vector<bool>` legacy. It also evokes
> `dynarray`, and covers many of the same use-cases (i.e. vector semantics =
on
> the stack), but requires no core language changes.
>
I've mostly arrived at the same conclusion, but I think "vararray" (short
for "variable-length array") is a better name than "varray". Abbreviating
to a single character is no longer in vogue.
Hmmm...
>
>
>
> --
>
> Tristan
>
>
>
>
>
> --
>
> ---
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a114199740e0e030528ad2ba9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 5:46 PM, Tristan Brindle <span dir=3D"ltr"><<=
a href=3D"mailto:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@gmail.com=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><=
br>
> On 7/01/2016, at 5:04 AM, Nevin Liber <<a href=3D"mailto:nevin@evil=
overlord.com">nevin@eviloverlord.com</a>> wrote:<br>
><br>
> And by not putting it in we harm its use in generic programming.=C2=A0=
We added array<T, 0>; I see no reason not to add small_vector<T, =
0, A>.<br>
><br>
<br>
</span>That=E2=80=99s a good point. I hadn=E2=80=99t considered the generic=
programming aspect. The symmetry with `array` is appealing.<br>
<span class=3D""><br>
<br>
> I'm not seeing any actual technical concerns; just FUD.<br>
<br>
</span>Sure. The technical concern is that `small_vector<T, 0>` winds=
up being identical to `vector<T>`, except that the two cannot be int=
erchanged. Having two ways to say the same thing is never good, particularl=
y for a type as fundamental and widely used as vector.<br>
<br>
On the other hand, perhaps we could frame the discussion differently. The =
=E2=80=9Csmall vector=E2=80=9D being discussed here is really a generalisat=
ion of vector, similar to how `tuple` is a generalisation of `pair` =E2=80=
=94 both of which still exist, despite the latter being technically redunda=
nt.<br>
<br>
Looking at it this way, `small_vector` is actually a poor name choice. Perh=
aps a better name would be `varray`, or variable array. If we default the s=
econd template argument, then `varray` becomes a drop-in replacement for `v=
ector`, except without the `vector<bool>` legacy. It also evokes `dyn=
array`, and covers many of the same use-cases (i.e. vector semantics on the=
stack), but requires no core language changes.<br></blockquote><div>=C2=A0=
</div><div>I've mostly arrived at the same conclusion, but I think &quo=
t;vararray" (short for "variable-length array") is a better =
name than "varray".=C2=A0 Abbreviating to a single character is n=
o longer in vogue.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmmm...<br>
<br>
<br>
<br>
--<br>
<br>
Tristan<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
<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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114199740e0e030528ad2ba9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 06 Jan 2016 09:59:47 -0800
Raw View
On Wednesday 06 January 2016 13:48:32 Andrew Tomazos wrote:
> would be to add another template parameter to
> std::vector.
Breaks binary compatibility. Please don't.
--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 06 Jan 2016 10:01:12 -0800
Raw View
On Wednesday 06 January 2016 17:05:23 Andrew Tomazos wrote:
> You are underestimating the advantages I think. It's not just "reusing the
> name", its reusing the entire template. It's conceptually simpler, easier
> to specify, easier to implement, its a single class template definition
> (the branch if (num_preallocated_elements > 0) would be optimized out in
> the zero case). The interfaces and implementations of operations that
> dispatch on two std::vectors of different num_preallocated_elements
> (comparisons, conversions, etc, etc) would be cleaner.
Can't you do that by:
template <typename T, typename Allocator>
class vector : public small_vector<T, 0, Allocator>
{
using small_vector;
};
--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 6 Jan 2016 12:35:41 -0600
Raw View
--001a114b157a7559fc0528aea166
Content-Type: text/plain; charset=UTF-8
On 6 January 2016 at 10:46, Tristan Brindle <tcbrindle@gmail.com> wrote:
>
> Looking at it this way, `small_vector` is actually a poor name choice.
I'd much rather we not use the word "vector" in the name *for the initial
discussion*, as it limits thinking on design choices. No one says it has
to have exactly the same interface (no more, no less) as vector.
For instance, it might make sense to have a bool emplace_back_if_space(...)
member that returns false if the container is already at its capacity. We
may or may not want to add such a thing to std::vector.
> Perhaps a better name would be `varray`, or variable array.
I would say no. In C++, arrays refer to things that have exactly N
elements (well, maybe not valarray; I don't know, as I've never had cause
to use it).
I also think that bike shedding the name at this point is the least of our
worries. (Note: while I'm against it, calling it vector is not just a
bike shedding issue.)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114b157a7559fc0528aea166
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 January 2016 at 10:46, Tristan Brindle <span dir=3D"l=
tr"><<a href=3D"mailto:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@=
gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><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"><span class=3D""><br></span>Lo=
oking at it this way, `small_vector` is actually a poor name choice.</block=
quote><div><br></div><div>I'd much rather we not use the word "vec=
tor" in the name <i>for the initial discussion</i>, as it limits think=
ing on design choices.=C2=A0 No one says it has to have exactly the same in=
terface (no more, no less) as vector.</div><div><br></div><div>For instance=
, it might make sense to have a bool emplace_back_if_space(...) member that=
returns false if the container is already at its capacity.=C2=A0 We may or=
may not want to add such a thing to std::vector.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"> Perhaps a better name would be `varray`, or va=
riable array.</blockquote><div><br></div><div>I would say no.=C2=A0 In C++,=
arrays refer to things that have exactly N elements (well, maybe not valar=
ray; I don't know, as I've never had cause to use it).</div><div><b=
r></div><div>I also think that bike shedding the name at this point is the =
least of our worries. =C2=A0(Note: =C2=A0while I'm against it, calling =
it vector is not just a bike shedding issue.)</div></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevi=
n ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1=
404</div></div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114b157a7559fc0528aea166--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 6 Jan 2016 12:38:16 -0600
Raw View
--089e0102e3deaa8e720528aeaaf4
Content-Type: text/plain; charset=UTF-8
On 6 January 2016 at 12:01, Thiago Macieira <thiago@macieira.org> wrote:
> Can't you do that by:
>
> template <typename T, typename Allocator>
> class vector : public small_vector<T, 0, Allocator>
> {
> using small_vector;
> };
>
You still have to forward non-compiler-generated constructors and
assignment operators.
Is this something you would want the standard to *mandate*, or is it just
an implementation detail?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0102e3deaa8e720528aeaaf4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 January 2016 at 12:01, Thiago Macieira <span dir=3D"l=
tr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@mac=
ieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><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">Can't you do that by:<br>
<br>
template <typename T, typename Allocator><br>
class vector : public small_vector<T, 0, Allocator><br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using small_vector;<br>
};<br></blockquote><div><br></div><div>You still have to forward non-compil=
er-generated constructors and assignment operators.</div><div><br></div><di=
v>Is this something you would want the standard to <i>mandate</i>, or is it=
just an implementation detail?</div></div>-- <br><div class=3D"gmail_signa=
ture"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)&quo=
t; Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div=
></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e0102e3deaa8e720528aeaaf4--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 6 Jan 2016 10:51:26 -0800 (PST)
Raw View
------=_Part_813_1662248385.1452106286771
Content-Type: multipart/alternative;
boundary="----=_Part_814_734360541.1452106286771"
------=_Part_814_734360541.1452106286771
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 6, 2016 at 1:38:57 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 6 January 2016 at 12:01, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> Can't you do that by:
>>
>> template <typename T, typename Allocator>
>> class vector : public small_vector<T, 0, Allocator>
>> {
>> using small_vector;
>> };
>>
>
> You still have to forward non-compiler-generated constructors and
> assignment operators.
>
> Is this something you would want the standard to *mandate*, or is it just
> an implementation detail?
>
Actually, it'd be better to mandate the reverse as a specialization:
template<typename T, typename Allocator>
class small_vector<T, 0, Allocator> : public vector<T, Allocator>
{
using vector;
//Add interfaces specific to small_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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_814_734360541.1452106286771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 6, 2016 at 1:38:57 PM UTC-5, Nevin ":-)&=
quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On 6 January 2016 at 12:01, Thiago Macieira <span dir=3D"ltr"><<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"MjkzKFK8EwAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">thi...@ma=
cieira.org</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Can't you do that by:<br>
<br>
template <typename T, typename Allocator><br>
class vector : public small_vector<T, 0, Allocator><br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using small_vector;<br>
};<br></blockquote><div><br></div><div>You still have to forward non-compil=
er-generated constructors and assignment operators.</div><div><br></div><di=
v>Is this something you would want the standard to <i>mandate</i>, or is it=
just an implementation detail?</div></div></div></div></blockquote><div><b=
r><br>Actually, it'd be better to mandate the reverse as a specializati=
on:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><s=
pan 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=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Allocator</span><span style=3D"color: #660;" cla=
ss=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">class</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> small_vector</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">0</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;" c=
lass=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-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">pub=
lic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> vector=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #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"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> vector</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/Add interfaces specific to small_vector.</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span></div></code></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_814_734360541.1452106286771--
------=_Part_813_1662248385.1452106286771--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 20:08:54 +0100
Raw View
--001a1147dc98d92d510528af1554
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 7:35 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 6 January 2016 at 10:46, Tristan Brindle <tcbrindle@gmail.com> wrote:
>
>>
>> Looking at it this way, `small_vector` is actually a poor name choice.
>
>
> I'd much rather we not use the word "vector" in the name *for the initial
> discussion*, as it limits thinking on design choices. No one says it has
> to have exactly the same interface (no more, no less) as vector.
>
The advantage of having exactly the same interface (or even being exactly
the same type) is the same as why we didn't standardize two different
flavors of, for example, variant. Having multiple different, mostly
similar, but slightly different versions of things adds complexity to the
language for little gain.
For instance, it might make sense to have a bool emplace_back_if_space(...)
> member that returns false if the container is already at its capacity. We
> may or may not want to add such a thing to std::vector.
>
>
>> Perhaps a better name would be `varray`, or variable array.
>
>
> I would say no. In C++, arrays refer to things that have exactly N
> elements (well, maybe not valarray; I don't know, as I've never had cause
> to use it).
>
> I also think that bike shedding the name at this point is the least of our
> worries. (Note: while I'm against it, calling it vector is not just a
> bike shedding issue.)
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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
> https://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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1147dc98d92d510528af1554
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jan 6, 2016 at 7:35 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On 6 January 2016 at 10:46, Tristan Brindle <span dir=3D"ltr"><=
;<a href=3D"mailto:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@gmail.c=
om</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br></s=
pan>Looking at it this way, `small_vector` is actually a poor name choice.<=
/blockquote><div><br></div></span><div>I'd much rather we not use the w=
ord "vector" in the name <i>for the initial discussion</i>, as it=
limits thinking on design choices.=C2=A0 No one says it has to have exactl=
y the same interface (no more, no less) as vector.</div></div></div></div><=
/blockquote><div>=C2=A0</div><div>The advantage of having exactly the same =
interface (or even being exactly the same type) is the same as why we didn&=
#39;t standardize two different flavors of, for example, variant.=C2=A0 Hav=
ing multiple different, mostly similar, but slightly different versions of =
things adds complexity to the language for little gain.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div></div><div>For instance, it might make sen=
se to have a bool emplace_back_if_space(...) member that returns false if t=
he container is already at its capacity.=C2=A0 We may or may not want to ad=
d such a thing to std::vector.</div><span class=3D""><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"> Perhaps a better name would be `varray`, or vari=
able array.</blockquote><div><br></div></span><div>I would say no.=C2=A0 In=
C++, arrays refer to things that have exactly N elements (well, maybe not =
valarray; I don't know, as I've never had cause to use it).</div><d=
iv><br></div><div>I also think that bike shedding the name at this point is=
the least of our worries. =C2=A0(Note: =C2=A0while I'm against it, cal=
ling it vector is not just a bike shedding issue.)</div></div><span class=
=3D"">-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &=
quot;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0<a href=3D"tel:=
%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blank">+1-847-691-1404=
</a></div></div></div></div></div>
</span></div></div>
<p></p>
-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1147dc98d92d510528af1554--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 6 Jan 2016 20:28:55 +0100
Raw View
--047d7ba972227384510528af5d94
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 7:01 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Wednesday 06 January 2016 17:05:23 Andrew Tomazos wrote:
> > You are underestimating the advantages I think. It's not just "reusing
> the
> > name", its reusing the entire template. It's conceptually simpler,
> easier
> > to specify, easier to implement, its a single class template definition
> > (the branch if (num_preallocated_elements > 0) would be optimized out in
> > the zero case). The interfaces and implementations of operations that
> > dispatch on two std::vectors of different num_preallocated_elements
> > (comparisons, conversions, etc, etc) would be cleaner.
>
> Can't you do that by:
>
> template <typename T, typename Allocator>
> class vector : public small_vector<T, 0, Allocator>
> {
> using small_vector;
> };
>
>
I think you may be onto something here:
template<
class T,
size_t NumPreallocatedElements = 0,
class Allocator = std::allocator<T>
>
class vararray { ... };
template <typename T, typename Allocator>
class vector : public vararray<T, 0, Allocator>
{
using vararray;
// plus necessary forwards
};
This maintains source and binary compatibility. I wonder if this works:
template<size_t N>
void f(const std::vararray<int, N>& v);
std::vector<int> v;
f(v);
Is the deduction going to consider base classes? Can't quite remember
right now.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7ba972227384510528af5d94
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 7:01 PM, Thiago Macieira <span dir=3D"ltr"><<=
a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org=
</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;padding-left:1ex"><span class=3D"">On Wednesday 06=
January 2016 17:05:23 Andrew Tomazos wrote:<br>
> You are underestimating the advantages I think.=C2=A0 It's not jus=
t "reusing the<br>
> name", its reusing the entire template.=C2=A0 It's conceptual=
ly simpler, easier<br>
> to specify, easier to implement, its a single class template definitio=
n<br>
> (the branch if (num_preallocated_elements > 0) would be optimized o=
ut in<br>
> the zero case).=C2=A0 The interfaces and implementations of operations=
that<br>
> dispatch on two std::vectors of different num_preallocated_elements<br=
>
> (comparisons, conversions, etc, etc) would be cleaner.<br>
<br>
</span>Can't you do that by:<br>
<br>
template <typename T, typename Allocator><br>
class vector : public small_vector<T, 0, Allocator><br>
{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using small_vector;<br>
};<br><div class=3D""><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>I think =C2=A0you may be onto something here:</div><div><br><=
/div><div><div>template<</div><div>=C2=A0 =C2=A0 class T,</div><div>=C2=
=A0 =C2=A0 size_t NumPreallocatedElements =3D 0,</div><div>=C2=A0 =C2=A0 cl=
ass Allocator =3D std::allocator<T></div><div>></div><div>class va=
rarray { ... };</div></div><div><br></div><div>template <typename T, typ=
ename Allocator><br>class vector : public vararray<T, 0, Allocator>=
;<br>{<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 using vararray;</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 // plus necessary forwards<br>};<br></div></div><br></div=
><div class=3D"gmail_extra">This maintains source and binary compatibility.=
=C2=A0 I wonder if this works:</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">=C2=A0 =C2=A0template<size_t N></div><div cl=
ass=3D"gmail_extra">=C2=A0 =C2=A0void f(const std::vararray<int, N>&a=
mp; v);<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">=C2=A0 =C2=A0std::vector<int> v;</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=A0f(v);</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Is the deduction goin=
g to consider base classes?=C2=A0 Can't quite remember right now.</div>=
<div class=3D"gmail_extra"><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7ba972227384510528af5d94--
.
Author: =?UTF-8?Q?Ion_Gazta=c3=b1aga?= <igaztanaga@gmail.com>
Date: Wed, 6 Jan 2016 21:56:16 +0100
Raw View
On 05/01/2016 14:57, Alisdair Meredith wrote:
>> On Jan 4, 2016, at 2:33 PM, Marcelo Zimbres <mzimbres@gmail.com> wrote:
>>
>> Can't scoped allocators cover the container of containers case?
>
>
> This is fine for the simple case, where you can put a simple limit on the
> amount of stack space to the used by all elements in the container, but
> the original problem is slightly mis-stated.
>
> The intent is that for a small vector, memory allocation comes out of spa=
ce
> in the vector object itself, rather than necessitating a trip to the heap=
.. When
> we have a container with millions of small vectors, that saving is notabl=
e. In
> this case, we do not really mean =E2=80=98allocate on the stack=E2=80=99 =
but =E2=80=98allocate from
> internal state=E2=80=99, and that is where allocators can no longer help,=
but the
> optimization must be built into the data structure itself.
Alidair, in case this helps,
In order to implement small_vector for Boost, I've tried to reuse all=20
vector code to improve maintenance. The implementation detail (which is=20
not ready to be a proposal at all), is to declare a new allocator attribute=
:
is_partially_propagable
which means that memory allocated by one allocator might not be=20
propagated as a general rule, but it must be queried storage per=20
storage. Currently it is done by:
bool storage_is_unpropagable(pointer p);
(maybe is not a good idea to have a negative query, this might change in=20
future versions)
Also, in a "partially propagable" allocator, one allocator compares=20
equal to another one if *storage that is propagable*=20
(!storage_is_unpropagable()) can be deallocated by another allocator.
boost::container::vector handles those partially propagable allocators=20
and small_vector is just a wrapper a vector with a partially propagable=20
allocator.
This scheme might not be scalable to other classes like node-based=20
allocators (one would need to query "storage_is_unpropagable" in all=20
nodes, so the performance might suffer a bit) but at least for single=20
storage holders like vector it's quite useful.
Best,
Ion
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 6 Jan 2016 17:19:17 -0600
Raw View
--001a114242a4b0bc230528b297b0
Content-Type: text/plain; charset=UTF-8
On 6 January 2016 at 13:08, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Wed, Jan 6, 2016 at 7:35 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 6 January 2016 at 10:46, Tristan Brindle <tcbrindle@gmail.com> wrote:
>>
>>>
>>> Looking at it this way, `small_vector` is actually a poor name choice.
>>
>>
>> I'd much rather we not use the word "vector" in the name *for the
>> initial discussion*, as it limits thinking on design choices. No one
>> says it has to have exactly the same interface (no more, no less) as vector.
>>
>
> The advantage of having exactly the same interface (or even being exactly
> the same type) is the same as why we didn't standardize two different
> flavors of, for example, variant. Having multiple different, mostly
> similar, but slightly different versions of things adds complexity to the
> language for little gain.
>
Breaking backwards compatibility is a huge *loss*, especially since we
don't need to, because unlike minor breakages to vector in the past (say
between C++98 and C++11 for move semantics), existing code will not
benefit. If this were a world where we didn't already have vector for
almost two decades, I might think differently.
If we stick with vector, we are saddled with the bool specialization wart,
we cannot conceptify the interface, etc.
This differs from the variant case in that (a) we were starting from
scratch and (b) the differences were in expert-only usage.
Combining it with vector without guidance from both LEWG and LWG saying
that they want them tied together as well has exactly how they want them
tied together seems a bit premature.
AFAIK, none of the current implementations have an interface that has
std::vector anywhere in it, so it is pure invention that there are enough
practical use cases for this to be worthwhile.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114242a4b0bc230528b297b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 January 2016 at 13:08, Andrew Tomazos <span dir=3D"lt=
r"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewt=
omazos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Ja=
n 6, 2016 at 7:35 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On 6 Ja=
nuary 2016 at 10:46, Tristan Brindle <span dir=3D"ltr"><<a href=3D"mailt=
o:tcbrindle@gmail.com" target=3D"_blank">tcbrindle@gmail.com</a>></span>=
wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span><br></span>Looking at it this way, =
`small_vector` is actually a poor name choice.</blockquote><div><br></div><=
/span><div>I'd much rather we not use the word "vector" in th=
e name <i>for the initial discussion</i>, as it limits thinking on design c=
hoices.=C2=A0 No one says it has to have exactly the same interface (no mor=
e, no less) as vector.</div></div></div></div></blockquote><div>=C2=A0</div=
></span><div>The advantage of having exactly the same interface (or even be=
ing exactly the same type) is the same as why we didn't standardize two=
different flavors of, for example, variant.=C2=A0 Having multiple differen=
t, mostly similar, but slightly different versions of things adds complexit=
y to the language for little gain.</div></div></div></div></blockquote><div=
><br></div><div>Breaking backwards compatibility is a huge <i>loss</i>, esp=
ecially since we don't need to, because unlike minor breakages to vecto=
r in the past (say between C++98 and C++11 for move semantics), existing co=
de will not benefit.=C2=A0 If=C2=A0this were a world where we didn't al=
ready have vector for almost two decades, I might think differently.</div><=
div><br></div><div>If we stick with vector, we are saddled with the bool sp=
ecialization wart, we cannot conceptify the interface, etc.</div><div><br><=
/div><div>This differs from the variant case in that (a) we were starting f=
rom scratch and (b) the differences were in expert-only usage.</div><div><b=
r></div><div>Combining it with vector without guidance from both LEWG and L=
WG saying that they want them tied together as well has exactly how they wa=
nt them tied together seems a bit premature.</div><div><br></div><div>AFAIK=
, none of the current implementations have an interface that has std::vecto=
r anywhere in it, so it is pure invention that there are enough practical u=
se cases for this to be worthwhile.</div></div>-- <br><div class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)=
" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" tar=
get=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></=
div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114242a4b0bc230528b297b0--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 6 Jan 2016 21:24:01 -0800 (PST)
Raw View
------=_Part_8457_1484453058.1452144242053
Content-Type: multipart/alternative;
boundary="----=_Part_8458_1971335433.1452144242054"
------=_Part_8458_1971335433.1452144242054
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 6, 2016 at 2:08:56 PM UTC-5, Andrew Tomazos wrote:
>
> On Wed, Jan 6, 2016 at 7:35 PM, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>
>> On 6 January 2016 at 10:46, Tristan Brindle <tcbr...@gmail.com
>> <javascript:>> wrote:
>>
>>>
>>> Looking at it this way, `small_vector` is actually a poor name choice.
>>
>>
>> I'd much rather we not use the word "vector" in the name *for the
>> initial discussion*, as it limits thinking on design choices. No one
>> says it has to have exactly the same interface (no more, no less) as vector.
>>
>
> The advantage of having exactly the same interface (or even being exactly
> the same type) is the same as why we didn't standardize two different
> flavors of, for example, variant. Having multiple different, mostly
> similar, but slightly different versions of things adds complexity to the
> language for little gain.
>
And yet we do.
What is std::forward_list if not purely an optimization over std::list?
What does std::string provide over std::vector<char>? It offers a few minor
differences: guaranteed null-termination, implicit construction from T
arrays and pointers, and the possibility for small-array optimization. Is
not most of the interface for std::unordered_map equivalent to that of
std::map?
Having "multiple different, mostly similar, but slightly different versions
of things" is a ship that has already sailed in the standard library.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8458_1971335433.1452144242054
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 6, 2016 at 2:08:56 PM UTC-5, Andrew Tomazos wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Wed, Jan 6, 2016 at 7:35 PM, Nevin Liber <span dir=3D"l=
tr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Eh_v9fS9EwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">ne...@eviloverlord.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span>On 6 January 2016 at 10:46, Tristan Brindle <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"Eh_v9fS9EwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">tcbr...@gmail.com</a>></span> wrote:<br></span><div><div=
class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br></spa=
n>Looking at it this way, `small_vector` is actually a poor name choice.</b=
lockquote><div><br></div></span><div>I'd much rather we not use the wor=
d "vector" in the name <i>for the initial discussion</i>, as it l=
imits thinking on design choices.=C2=A0 No one says it has to have exactly =
the same interface (no more, no less) as vector.</div></div></div></div></b=
lockquote><div>=C2=A0</div><div>The advantage of having exactly the same in=
terface (or even being exactly the same type) is the same as why we didn=
9;t standardize two different flavors of, for example, variant.=C2=A0 Havin=
g multiple different, mostly similar, but slightly different versions of th=
ings adds complexity to the language for little gain.</div></div></div></di=
v></blockquote><div><br>And yet we do.<br><br>What is std::forward_list if =
not purely an optimization over std::list? What does std::string provide ov=
er std::vector<char>? It offers a few minor differences: guaranteed n=
ull-termination, implicit construction from T arrays and pointers, and the =
possibility for small-array optimization. Is not most of the interface for =
std::unordered_map equivalent to that of std::map?<br><br>Having "mult=
iple different, mostly similar, but slightly different versions of things&q=
uot; is a ship that has already sailed in the standard library.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_8458_1971335433.1452144242054--
------=_Part_8457_1484453058.1452144242053--
.
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Fri, 8 Jan 2016 00:02:48 +1300
Raw View
--001a113dc58847b93e0528bc69a9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jan 7, 2016 at 7:35 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> I'd much rather we not use the word "vector" in the name *for the initial
> discussion*, as it limits thinking on design choices. No one says it has
> to have exactly the same interface (no more, no less) as vector.
>
> Perhaps a better name would be `varray`, or variable array.
>
>
> I would say no. In C++, arrays refer to things that have exactly N
> elements (well, maybe not valarray; I don't know, as I've never had cause
> to use it).
>
Well, if you don't want to call it a vector and you don't want to call it
an array, then we're rapidly running out of commonly-used terms for a
linear data structure. I'm pretty sure "list" is the wrong one to go for :-=
)
I also think that bike shedding the name at this point is the least of our
> worries. (Note: while I'm against it, calling it vector is not just a
> bike shedding issue.)
>
I agree that bike-shedding on the name at this point is unhelpful, but if
we=E2=80=99re going to talk about it then we need to call it *something*. S=
o I
suggest that purely *for the purposes of this discussion*, we follow Qt=E2=
=80=99s
lead and refer to =E2=80=9Ca growable contiguous collection with zero or mo=
re
elements preallocated=E2=80=9D as a "variable-length array" or vararray, as
suggested by Andrew.
Moving on, I think everyone can agree that all of the following are true:
i. We cannot change the interface of vector in any backwards-incompatible
way. This includes removing the vector<bool> specialisation, at least in
any reasonably short time frame =E2=80=94 it would require an alternative t=
o be
available in the IS, plus at least one cycle of deprecation.
ii. Declaring vector<T> to be an alias for vararray<T, 0> today would
require vararray<bool, 0> to be specialised, due to (i).
iii. We cannot allow vararray<T, 0> to be a separate type today, and at
some point in the future declare vector to be an alias for it. This would
break any code written in the intervening time which overloads on the two
types.
This leads me to think that we have five alternatives:
A. We do not consider vararray until such time as the vector<bool>
specialisation is removed.
B. We introduce vararray but forbid the zero case. We make no
attempt to reconcile this with vector.
C. We introduce vararray but forbid the zero case. Years pass, and
when/if vector<bool> is removed, we remove the zero prohibition and
redefine vector as an alias.
D. We introduce vararray and permit the zero case. We hold our
noses and define vararray<bool, 0> to be specialised (at least temporarily)
due to (ii), and redeclare vector to be an alias.
E. We introduce vararray and permit the zero case with no bool
specialisation. Due to (iii), vector<T> and vararray<T, 0> must remain
separate types forever.
(I believe these options are exhaustive, but if there are any other
realistic cases I haven't considered then please do suggest them.)
Let=E2=80=99s have a look at each one in more detail.
*Option A*
The least interesting option, and one that really requires no further
discussion. If we go for this, our time would be better spent trying to
standardise boost::dynamic_bitset, as that's a likely requirement for the
vector<bool> wart to be removed.
*Option B*
This was my initial suggestion, and one that I think is relatively
self-contained and uncontroversial. It is effectively where the various
small_vector implementations stand now. The advantage is that since it is
unrelated to vector, there is no potential confusion for users as to which
one should be used -- we tell people to use vector almost all the time,
unless they have very particular needs that vararray (probably better named
small_vector in this case) can help with. The downside is that as pointed
out above, barring N=3D0 is inelegant and may be a pain for generic
programming. Notably, this restriction was removed from array between TR1
and C++11.
*Option C*
Basically the same a Option B, except that we have the ability to "unlock"
the zero case for generic programming at some point in the future. The cost
of this is that vararray's API must be fixed to be no narrower than vector'=
s
from the word go, whereas with Option B we have some leeway to propose a
different API (but see below for a discussion about that).
*Option D*
With this option we remove any potential confusion between vararray and
vector; vector is just another name for a vararray which always uses the
heap. The downside, of course, is that we are still lumbered with the bool
specialisation, which we'd still have to get rid of at some point down the
line. But on the other hand, it leaves us no worse off than we are at the
moment, and does not artificially prohibit the N=3D0 case. Whether we defau=
lt
the second template parameter to 0 and encourage people to start
saying "vararray<int>
v =3D { 1, 2, 3 };" is an open question. This option would require vararray=
's
API to be a superset of vector's, due to (i).
*Option E*
This option gives us the most freedom, but is easily the most
controversial. If we allow vararray and vector to be completely
independent, and permit the N=3D0 case, then we have two containers that
offer identical semantics, except that vararray<bool> behaves properly.
This being the case, we'd have to make the choice of telling people which
one they should prefer, and it makes much more sense to say "always use
vararray" than it does to say "use a vector unless you're dealing with bool=
s
or need stack-reservation, in which case use vector". Thus vector becomes
redundant.
We have the choice in this case of whether vararray offers an identical API
to vector. If it does, then it becomes a drop-in replacement. We can
promote vararray as the modern way to use a variable-length array -- free
from the vector<bool> legacy, and with optional stack-reservation when you
need it.
On the other hand, in theory we have the freedom to design a new,
"superior" API for vararray if we wish. In theory that is, in practice we
don't actually have much freedom at all, since we would of course want
vararray to be a SequenceContainer
<http://en.cppreference.com/w/cpp/concept/SequenceContainer>. By the time
most of those requirements are in place, you basically have the vector API
anyway. In any case, we'd want to be consistent with list, deque, and
developers' existing familiarity with vector, which again limits any
choices we could make. It's a matter for debate of course, but unlike
std::string and its hundreds of member functions, my opinion is that the
vector API doesn't really have any particular warts that need removing.
There is much to be gained from keeping vararray's API the same as vector's=
,
and little to be lost; conversely, there is little to be gained and much to
be lost if we are gratuitously incompatible.
Option E -- replacing std::vector as the default container! -- might seem
at first glance to be unrealistic, perhaps even a good suggestion for an
April Fool. At first I dismissed it out of hand, but having given it some
more thought I'm warming to the idea. With the arrival of concepts and
ranges, and the talk of "STL2", this is a unique opportunity to do
something so radical. A vararray, as proposed, is a strict superset of
vector. It is never worse and sometimes better. We can easily maintain API
compatibility. The hundreds of tutorials and millions of lines of code that
use vector wouldn't suddenly be wrong, any more than the millions of lines
of code that use pair are wrong now that tuple exists. There is an appetite
in the C++ community at the moment to embrace the new; if we are ever going
to do something like this, now is the time.
-------
Phew! I think that covers just about every eventuality. If I've made any
mistakes or left anything out please let me know. Otherwise, any thoughts
on the pros and cons of the various options would be great.
Tristan
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a113dc58847b93e0528bc69a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jan 7, 2016 at 7:35 AM, Nevin Liber <span dir=3D"ltr"><<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div>I'd much rather we not use th=
e word "vector" in the name <i>for the initial discussion</i>, as=
it limits thinking on design choices.=C2=A0 No one says it has to have exa=
ctly the same interface (no more, no less) as vector.</div></div></div></di=
v></blockquote><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"> Perhaps a better name would be `varray`, or variable array.</block=
quote><div><br></div></span><div>I would say no.=C2=A0 In C++, arrays refer=
to things that have exactly N elements (well, maybe not valarray; I don=
9;t know, as I've never had cause to use it).</div></div></div></div></=
blockquote><div><br></div><div>Well, if you don't want to call it a vec=
tor and you don't want to call it an array, then we're rapidly runn=
ing out of commonly-used terms for a linear data structure. I'm pretty =
sure "list" is the wrong one to go for :-)</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div></div><div>I also think that bike shedding the name at this=
point is the least of our worries. =C2=A0(Note: =C2=A0while I'm agains=
t it, calling it vector is not just a bike shedding issue.)</div></div><spa=
n class=3D""></span></div></div></blockquote><div><br></div><div><span styl=
e=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">I agree that =
bike-shedding on the name at this point is unhelpful, but if we=E2=80=99re =
going to talk about it then we need to call it=C2=A0</span><span style=3D"f=
ont-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><i>something</i></s=
pan><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"=
>. So I suggest</span><span style=3D"font-family:arial,helvetica,sans-serif=
;color:rgb(0,0,0)">=C2=A0</span><span style=3D"font-family:arial,helvetica,=
sans-serif;color:rgb(0,0,0)">that purely <i>for the purposes of this discus=
sion</i>, we follow Qt=E2=80=99s lead and refer to =E2=80=9Ca growable cont=
iguous collection with zero or more elements</span><span style=3D"font-fami=
ly:arial,helvetica,sans-serif;color:rgb(0,0,0)">=C2=A0</span><span style=3D=
"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">preallocated=E2=
=80=9D as a "variable-length array" or=C2=A0</span><span style=3D=
"color:rgb(0,0,0)"><font face=3D"monospace, monospace">vararray</font></spa=
n><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">,=
as suggested by Andrew.</span><br style=3D"color:rgb(0,0,0);font-family:mo=
nospace;font-size:11px"></div><div><br></div><div><span style=3D"color:rgb(=
0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span =
style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Moving on=
, I think everyone can agree that all of the following are true:</span><br>=
</div><font face=3D"arial, helvetica, sans-serif"><br style=3D"color:rgb(0,=
0,0)"></font><span class=3D"" style=3D"font-family:arial,helvetica,sans-ser=
if;color:rgb(0,0,0);white-space:pre"> </span><span style=3D"font-family:ari=
al,helvetica,sans-serif;color:rgb(0,0,0)">i. We cannot change the interface=
of=C2=A0</span><span style=3D"color:rgb(0,0,0)"><font face=3D"monospace, m=
onospace">vector</font></span><span style=3D"font-family:arial,helvetica,sa=
ns-serif;color:rgb(0,0,0)">=C2=A0in any backwards-incompatible way. This in=
cludes removing the </span><span style=3D"color:rgb(0,0,0)"><font face=3D"m=
onospace, monospace">vector<bool></font></span><span style=3D"font-fa=
mily:arial,helvetica,sans-serif;color:rgb(0,0,0)"> specialisation, at</span=
><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">=
=C2=A0</span><span style=3D"font-family:arial,helvetica,sans-serif;color:rg=
b(0,0,0)">least in any reasonably short time frame =E2=80=94 it would requi=
re an alternative to be available in the IS, plus at least one cycle of dep=
recation.</span><font face=3D"arial, helvetica, sans-serif"><br><font color=
=3D"#000000"><br></font></font><span class=3D"" style=3D"font-family:arial,=
helvetica,sans-serif;color:rgb(0,0,0);white-space:pre"> </span><span style=
=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">ii. Declaring =
</span><span style=3D"color:rgb(0,0,0)"><font face=3D"monospace, monospace"=
>vector<T></font></span><span style=3D"font-family:arial,helvetica,sa=
ns-serif;color:rgb(0,0,0)"> to be an alias for </span><span style=3D"color:=
rgb(0,0,0)"><font face=3D"monospace, monospace">vararray<T, 0></font>=
</span><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,=
0)"> today would require </span><span style=3D"color:rgb(0,0,0)"><font face=
=3D"monospace, monospace">vararray<bool, 0></font></span><span style=
=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"> to be special=
ised, due to (i).</span><font face=3D"arial, helvetica, sans-serif"><br><fo=
nt color=3D"#000000"><br></font></font><span class=3D"" style=3D"font-famil=
y:arial,helvetica,sans-serif;color:rgb(0,0,0);white-space:pre"> </span><spa=
n style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">iii. We=
cannot allow </span><span style=3D"color:rgb(0,0,0)"><font face=3D"monospa=
ce, monospace">vararray<T, 0></font></span><span style=3D"font-family=
:arial,helvetica,sans-serif;color:rgb(0,0,0)"> to be a separate type today,=
and at some point in the future declare </span><span style=3D"color:rgb(0,=
0,0)"><font face=3D"monospace, monospace">vector</font></span><span style=
=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"> to be an alia=
s for it</span><span style=3D"font-family:arial,helvetica,sans-serif;color:=
rgb(0,0,0)">. This would break any code written in the intervening time whi=
ch overloads on the two types.</span><font face=3D"arial, helvetica, sans-s=
erif"><br></font><div>=C2=A0</div><div><br></div><div><br></div>This leads =
me to think that we have five alternatives:<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 A. We do not consider=C2=A0<font face=3D"monospace, monospace">vararray=
</font> until such time as the <font face=3D"monospace, monospace">vector&l=
t;bool></font> specialisation is removed.</div><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote">=C2=A0 =C2=A0 =C2=A0 =C2=A0 B. We in=
troduce=C2=A0<font face=3D"monospace, monospace">vararray</font><font face=
=3D"arial, helvetica, sans-serif">=C2=A0</font>but forbid the zero case. We=
make no attempt to reconcile this with=C2=A0<font face=3D"monospace, monos=
pace">vector</font>.<br></div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">=C2=A0 =C2=A0 =C2=A0 =C2=A0 C. We introduce <font face=
=3D"monospace, monospace">vararray=C2=A0</font>but forbid the zero case. Ye=
ars pass, and when/if <font face=3D"monospace, monospace">vector<bool>=
;</font> is removed, we remove the zero prohibition and redefine <font face=
=3D"monospace, monospace">vector</font> as an alias.</div><div class=3D"gma=
il_quote"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 D. We introduce <font face=3D"mon=
ospace, monospace">vararray</font> and permit the zero case. We hold our no=
ses and define <font face=3D"monospace, monospace">vararray<bool, 0><=
/font> to be specialised (at least temporarily) due to (ii), and redeclare =
<font face=3D"monospace, monospace">vector</font> to be an alias.<br><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 E. We introduce <font face=3D"monospace, monosp=
ace">vararray</font> and permit the zero case with no <font face=3D"monospa=
ce, monospace">bool</font> specialisation. Due to (iii), <font face=3D"mono=
space, monospace">vector<T></font> and <font face=3D"monospace, monos=
pace">vararray<T, 0></font> must remain separate types forever.<br><b=
r>(I believe these options are exhaustive, but if there are any other reali=
stic cases I haven't considered then please do suggest them.)<br><br>Le=
t=E2=80=99s have a look at each one in more detail.<br><br><b>Option A</b><=
/div><div class=3D"gmail_quote"><b><br></b></div><div class=3D"gmail_quote"=
>The least interesting option, and one that really requires no further disc=
ussion. If we go for this, our time would be better spent trying to standar=
dise <font face=3D"monospace, monospace">boost::dynamic_bitset</font>, as t=
hat's a likely requirement for the <font face=3D"monospace, monospace">=
vector<bool></font> wart to be removed.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote"><b>Option B</b></div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">This was my initial sugge=
stion, and one that I think is relatively self-contained and uncontroversia=
l. It is effectively where the various <font face=3D"monospace, monospace">=
small_vector</font> implementations stand now. The advantage is that since =
it is unrelated to <font face=3D"monospace, monospace">vector</font>, there=
is no potential confusion for users as to which one should be used -- we t=
ell people to use <font face=3D"monospace, monospace">vector</font> almost =
all the time, unless they have very particular needs that <font face=3D"mon=
ospace, monospace">vararray</font> (probably better named <font face=3D"mon=
ospace, monospace">small_vector</font> in this case) can help with. The dow=
nside is that as pointed out above, barring N=3D0 is inelegant and may be a=
pain for generic programming. Notably, this restriction was removed from <=
font face=3D"monospace, monospace">array</font><font face=3D"arial, helveti=
ca, sans-serif">=C2=A0between TR1 and C++11.</font></div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote"><font face=3D"arial, helvetic=
a, sans-serif"><b>Option C</b></font></div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">Basically the same a Option B, except that =
we have the ability to "unlock" the zero case for generic program=
ming at some point in the future. The cost of this is that <font face=3D"mo=
nospace, monospace">vararray</font>'s API must be fixed to be no narrow=
er than=C2=A0<font face=3D"monospace, monospace">vector</font>'s from t=
he word go, whereas with Option B we have some leeway to propose a differen=
t API (but see below for a discussion about that).</div><div class=3D"gmail=
_quote"><b><br></b></div><div class=3D"gmail_quote"><b>Option D</b></div><d=
iv class=3D"gmail_quote"><b><br></b></div><div class=3D"gmail_quote">With t=
his option we remove any potential confusion between <font face=3D"monospac=
e, monospace">vararray</font> and <font face=3D"monospace, monospace">vecto=
r</font><font face=3D"arial, helvetica, sans-serif">;</font>=C2=A0<font fac=
e=3D"monospace, monospace">vector</font> is just another name for a=C2=A0<f=
ont face=3D"monospace, monospace">vararray</font> which always uses the hea=
p. The downside, of course, is that we are still lumbered with the <font fa=
ce=3D"monospace, monospace">bool</font> specialisation, which we'd stil=
l have to get rid of at some point down the line. But on the other hand, it=
leaves us no worse off than we are at the moment, and does not artificiall=
y prohibit the N=3D0 case. Whether we default the second template parameter=
to 0 and encourage people to start saying "<font face=3D"monospace, m=
onospace">vararray<int> v =3D { 1, 2, 3 };</font>" is an open qu=
estion. This option would require <font face=3D"monospace, monospace">varar=
ray</font>'s API to be a superset of=C2=A0<font face=3D"monospace, mono=
space">vector</font>'s, due to (i).</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote"><b>Option E</b></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">This option gives us the most f=
reedom, but is easily the most controversial. If we allow <font face=3D"mon=
ospace, monospace">vararray</font> and <font face=3D"monospace, monospace">=
vector</font> to be completely independent, and permit the N=3D0 case, then=
we have two containers that offer identical semantics, except that <font f=
ace=3D"monospace, monospace">vararray<bool></font> behaves properly. =
This being the case, we'd have to make the choice of telling people whi=
ch one they should prefer, and it makes much more sense to say "always=
use <font face=3D"monospace, monospace">vararray</font>" than it does=
to say "use a <font face=3D"monospace, monospace">vector</font> unles=
s you're dealing with <font face=3D"monospace, monospace">bool</font>s =
or need stack-reservation, in which case use <font face=3D"monospace, monos=
pace">vector</font>". Thus <font face=3D"monospace, monospace">vector<=
/font> becomes redundant.</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">We have the choice in this case of whether <font face=
=3D"monospace, monospace">vararray</font> offers an identical API to <font =
face=3D"monospace, monospace">vector</font>. If it does, then it becomes a =
drop-in replacement. We can promote <font face=3D"monospace, monospace">var=
array</font> as the modern way to use a variable-length array -- free from =
the <font face=3D"monospace, monospace">vector<bool></font> legacy, a=
nd with optional stack-reservation when you need it.</div><div class=3D"gma=
il_quote"><br></div><div class=3D"gmail_quote">On the other hand, in theory=
we have the freedom to design a new, "superior" API for <font fa=
ce=3D"monospace, monospace">vararray</font> if we wish. In theory that is, =
in practice we don't actually have much freedom at all, since we would =
of course want <font face=3D"monospace, monospace">vararray</font> to be a=
=C2=A0<a href=3D"http://en.cppreference.com/w/cpp/concept/SequenceContainer=
">SequenceContainer</a>. By the time most of those requirements are in plac=
e, you basically have the <font face=3D"monospace, monospace">vector</font>=
API anyway. In any case, we'd want to be consistent with <font face=3D=
"monospace, monospace">list</font>, <font face=3D"monospace, monospace">deq=
ue</font>, and developers' existing familiarity with <font face=3D"mono=
space, monospace">vector</font><font face=3D"arial, helvetica, sans-serif">=
, which again limits any choices we could make.</font>=C2=A0It's a matt=
er for debate of course, but unlike <font face=3D"monospace, monospace">std=
::string</font> and its hundreds of member functions, my opinion is that th=
e <font face=3D"monospace, monospace">vector</font> API doesn't really =
have any particular warts that need removing. There is much to be gained fr=
om keeping <font face=3D"monospace, monospace">vararray</font>'s API th=
e same as <font face=3D"monospace, monospace">vector</font>'s, and litt=
le to be lost; conversely, there is little to be gained and much to be lost=
if we are gratuitously incompatible.</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">Option E -- replacing <font face=3D"monospa=
ce, monospace">std::vector</font><font face=3D"arial, helvetica, sans-serif=
">=C2=A0as the=C2=A0default=C2=A0container</font>! -- might seem at first g=
lance to be unrealistic, perhaps even a good suggestion for an April Fool. =
At first I dismissed it out of hand, but having given it some more thought =
I'm warming to the idea. With the arrival of concepts and ranges, and t=
he talk of "STL2", this is a unique opportunity to do something s=
o radical. A <font face=3D"monospace, monospace">vararray</font>, as propos=
ed, is a strict superset of <font face=3D"monospace, monospace">vector</fon=
t>. It is never worse and sometimes better. We can easily maintain API comp=
atibility. The hundreds of tutorials and millions of lines of code that use=
<font face=3D"monospace, monospace">vector</font> wouldn't suddenly be=
wrong, any more than the millions of lines of code that use <font face=3D"=
monospace, monospace">pair</font>=C2=A0are wrong now that <font face=3D"mon=
ospace, monospace">tuple</font>=C2=A0exists. There is an appetite in the C+=
+ community at the moment to embrace the new; if we are ever going to do so=
mething like this, now is the time.</div><div class=3D"gmail_quote"><br></d=
iv><div class=3D"gmail_quote">-------</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">Phew! I think that covers just about every =
eventuality. If I've made any mistakes or left anything out please let =
me know. Otherwise, any thoughts on the pros and cons of the various option=
s would be great.</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">Tristan</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote"><b><br></b></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113dc58847b93e0528bc69a9--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 7 Jan 2016 06:41:53 -0800 (PST)
Raw View
------=_Part_8544_1360659558.1452177713233
Content-Type: multipart/alternative;
boundary="----=_Part_8545_1523037716.1452177713234"
------=_Part_8545_1523037716.1452177713234
Content-Type: text/plain; charset=UTF-8
On Thursday, January 7, 2016 at 6:02:53 AM UTC-5, Tristan Brindle wrote:
>
> Option E -- replacing std::vector as the default container! -- might seem
> at first glance to be unrealistic, perhaps even a good suggestion for an
> April Fool. At first I dismissed it out of hand, but having given it some
> more thought I'm warming to the idea. With the arrival of concepts and
> ranges, and the talk of "STL2", this is a unique opportunity to do
> something so radical. A vararray, as proposed, is a strict superset of
> vector. It is never worse and sometimes better. We can easily maintain
> API compatibility. The hundreds of tutorials and millions of lines of code
> that use vector wouldn't suddenly be wrong, any more than the millions of
> lines of code that use pair are wrong now that tuple exists. There is an
> appetite in the C++ community at the moment to embrace the new; if we are
> ever going to do something like this, now is the time.
>
I do not believe that now is the time at all.
Ranges makes modifications to the iterator paradigm. Since it makes such
sweeping changes to iterators and creates new algorithms (and new concepts
like ranges and adapters), it brings with it the possibility of "STL2",
which is good. But here's the thing: until we actually get all of that
stuff *finished*, we're not in a position to start specifying how
containers should function.
Also, if you're going to start saying "hey, new container paradigm!", then
there are going to be a *lot* of people who want in on that conversation.
For example, I'd love to see a new vector where you can extract the memory
from it as a free-standing object, and pass it around elsewhere (along with
the allocator, of course). It could be given to a C-style API. Or more to
the point, a C-style API could *provide* such data, which could be used as
the initial storage for the vector (again, along with the allocator).
And if you're doing this for vector, you'd have to do it for string. Both
what I just suggested and explicit sizing for small-strings.
Some people will want a vector that can have an explicit limit to how big
it gets. Oh and since we're talking about changing the container paradigm,
why not throw away allocators and use a better allocation interface? Maybe
one that understands the concept of "type erasure". There are going to be
API suggestions for the associative containers. There are going to be
changes suggested for list and deque. Someone will probably suggest a
blanket ban on any throwing-move container implementation for the new
containers (I wouldn't say no to that one). And so on.
The discussion you're wanting to start is *endless*. Everyone and their
mother will come out and add their own pet feature.
If you want to start having that discussion, fine. And maybe in preparation
of the completion of the Ranges TS (probably version 2), it might be
appropriate to start collecting ideas now. But just be prepared for where
it leads.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8545_1523037716.1452177713234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, January 7, 2016 at 6:02:53 AM UTC-5, Tristan Brindle wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"></div><div class=3D"gmail_quote">Option E -- replacing <fo=
nt face=3D"monospace, monospace">std::vector</font><font face=3D"arial, hel=
vetica, sans-serif">=C2=A0as the=C2=A0default=C2=A0container</font>! -- mig=
ht seem at first glance to be unrealistic, perhaps even a good suggestion f=
or an April Fool. At first I dismissed it out of hand, but having given it =
some more thought I'm warming to the idea. With the arrival of concepts=
and ranges, and the talk of "STL2", this is a unique opportunity=
to do something so radical. A <font face=3D"monospace, monospace">vararray=
</font>, as proposed, is a strict superset of <font face=3D"monospace, mono=
space">vector</font>. It is never worse and sometimes better. We can easily=
maintain API compatibility. The hundreds of tutorials and millions of line=
s of code that use <font face=3D"monospace, monospace">vector</font> wouldn=
't suddenly be wrong, any more than the millions of lines of code that =
use <font face=3D"monospace, monospace">pair</font>=C2=A0are wrong now that=
<font face=3D"monospace, monospace">tuple</font>=C2=A0exists. There is an =
appetite in the C++ community at the moment to embrace the new; if we are e=
ver going to do something like this, now is the time.</div></div></div></bl=
ockquote><div><br>I do not believe that now is the time at all.<br><br>Rang=
es makes modifications to the iterator paradigm. Since it makes such sweepi=
ng changes to iterators and creates new algorithms (and new concepts like r=
anges and adapters), it brings with it the possibility of "STL2",=
which is good. But here's the thing: until we actually get all of that=
stuff=C2=A0<i>finished</i>, we're not in a position to start specifyin=
g how containers should function.<br><br>Also, if you're going to start=
saying "hey, new container paradigm!", then there are going to b=
e a <i>lot</i> of people who want in on that conversation. For example, I&#=
39;d love to see a new vector where you can extract the memory from it as a=
free-standing object, and pass it around elsewhere (along with the allocat=
or, of course). It could be given to a C-style API. Or more to the point, a=
C-style API could <i>provide</i> such data, which could be used as the ini=
tial storage for the vector (again, along with the allocator).<br><br>And i=
f you're doing this for vector, you'd have to do it for string. Bot=
h what I just suggested and explicit sizing for small-strings.<br><br>Some =
people will want a vector that can have an explicit limit to how big it get=
s. Oh and since we're talking about changing the container paradigm, wh=
y not throw away allocators and use a better allocation interface? Maybe on=
e that understands the concept of "type erasure". There are going=
to be API suggestions for the associative containers. There are going to b=
e changes suggested for list and deque. Someone will probably suggest a bla=
nket ban on any throwing-move container implementation for the new containe=
rs (I wouldn't say no to that one). And so on.<br><br>The discussion yo=
u're wanting to start is <i>endless</i>. Everyone and their mother will=
come out and add their own pet feature.</div><br>If you want to start havi=
ng that discussion, fine. And maybe in preparation of the completion of the=
Ranges TS (probably version 2), it might be appropriate to start collectin=
g ideas now. But just be prepared for where it leads.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_8545_1523037716.1452177713234--
------=_Part_8544_1360659558.1452177713233--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 7 Jan 2016 16:39:20 +0100
Raw View
--001a114199743c74510528c04675
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 7, 2016 at 3:41 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Ranges makes modifications to the iterator paradigm. Since it makes such
> sweeping changes to iterators and creates new algorithms (and new concepts
> like ranges and adapters), it brings with it the possibility of "STL2",
> which is good. But here's the thing: until we actually get all of that
> stuff *finished*, we're not in a position to start specifying how
> containers should function.
>
That's the standard dilemma between waiting for the slow big vague new
thing or making fast incremental concrete changes. The best approach is to
propose both, and let the committee gate/merge things as they will.
> I'd love to see a new vector where you can extract the memory from it as a
> free-standing object, and pass it around elsewhere (along with the
> allocator, of course). It could be given to a C-style API. Or more to the
> point, a C-style API could *provide* such data, which could be used as
> the initial storage for the vector (again, along with the allocator).
>
Why can't that be proposed as an extension to vector today? I don't see
the relevance. It seems orthogonal to everything discussed, and a
compatible extension to either/both vector and vararray.
> And if you're doing this for vector, you'd have to do it for string. Both
> what I just suggested and explicit sizing for small-strings.
>
Is there an existing practice of small_string? Isn't there already a
"small string optimization" possible and used in std::string? std::string
is mainly targetted at text, whereas vector/vararray are targeted at
contiguous homogenous sequences of an arbitrary type. They are
intentionally distinct.
Some people will want a vector that can have an explicit limit to how big
> it gets.
>
This could be a feature of vararray, it just depends how much demand there
is. The tradeoff is between additional complexity versus extra
functionality. Whether it is worth it depends on how much it would be used.
> Oh and since we're talking about changing the container paradigm, why not
> throw away allocators and use a better allocation interface? Maybe one that
> understands the concept of "type erasure". There are going to be API
> suggestions for the associative containers. There are going to be changes
> suggested for list and deque. Someone will probably suggest a blanket ban
> on any throwing-move container implementation for the new containers (I
> wouldn't say no to that one). And so on.
>
This is some sort of slippery slope fallacy. Noone is going to reject
vararray because they think we should wait for an allocators v2. Very few
people use anything but the default allocators anyway - virtually noone
cares.
The discussion you're wanting to start is *endless*. Everyone and their
> mother will come out and add their own pet feature.
>
I don't agree. A proposal of vararray should not be disccouraged by this
thought. All proposals get pulled in all directions. It doesn't mean it
won't be successful.
> If you want to start having that discussion, fine. And maybe in
> preparation of the completion of the Ranges TS (probably version 2), it
> might be appropriate to start collecting ideas now. But just be prepared
> for where it leads.
I think the right thing to do would be to write a proposal of vararray for
LEWG JAX, carefully considering and exploring all the options and making a
recommendation for a course of action - and see what they have to say.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114199743c74510528c04675
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 7, 2016 at 3:41 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>Ranges makes modification=
s to the iterator paradigm. Since it makes such sweeping changes to iterato=
rs and creates new algorithms (and new concepts like ranges and adapters), =
it brings with it the possibility of "STL2", which is good. But h=
ere's the thing: until we actually get all of that stuff=C2=A0<i>finish=
ed</i>, we're not in a position to start specifying how containers shou=
ld function.<br></div></blockquote><div><br></div><div>That's the stand=
ard dilemma between waiting for the slow big vague new thing or making fast=
incremental concrete changes.=C2=A0 The best approach is to propose both, =
and let the committee gate/merge things as they will.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div>I'd love to see a new vector where=
you can extract the memory from it as a free-standing object, and pass it =
around elsewhere (along with the allocator, of course).=C2=A0 It could be g=
iven to a C-style API. Or more to the point, a C-style API could <i>provide=
</i> such data, which could be used as the initial storage for the vector (=
again, along with the allocator).</div></blockquote><div><br></div><div>Why=
can't that be proposed as an extension to vector today?=C2=A0 I don=
9;t see the relevance.=C2=A0 It seems orthogonal to everything discussed, a=
nd a compatible extension to either/both vector and vararray.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>And if you're doing this f=
or vector, you'd have to do it for string. Both what I just suggested a=
nd explicit sizing for small-strings.<br></div></blockquote><div><br></div>=
<div>Is there an existing practice of small_string?=C2=A0 Isn't there a=
lready a "small string optimization" possible and used in std::st=
ring? =C2=A0std::string is mainly targetted at text, whereas vector/vararra=
y are targeted at contiguous homogenous sequences of an arbitrary type.=C2=
=A0 They are intentionally distinct.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>Some people will want a vector that can have an explicit=
limit to how big it gets.</div></blockquote><div><br></div><div>This could=
be a feature of vararray, it just depends how much demand there is.=C2=A0 =
The tradeoff is between additional complexity versus extra functionality.=
=C2=A0 Whether it is worth it depends on how much it would be used.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div> Oh and since we're =
talking about changing the container paradigm, why not throw away allocator=
s and use a better allocation interface? Maybe one that understands the con=
cept of "type erasure". There are going to be API suggestions for=
the associative containers. There are going to be changes suggested for li=
st and deque. Someone will probably suggest a blanket ban on any throwing-m=
ove container implementation for the new containers (I wouldn't say no =
to that one). And so on.<br></div></blockquote><div><br></div><div>This is =
some sort of slippery slope fallacy.=C2=A0 Noone is going to reject vararra=
y because they think we should wait for an allocators v2.=C2=A0 Very few pe=
ople use anything but the default allocators anyway - virtually noone cares=
..</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The discussion yo=
u're wanting to start is <i>endless</i>. Everyone and their mother will=
come out and add their own pet feature.</div></blockquote><div><br></div><=
div>I don't agree.=C2=A0 A proposal of vararray should not be disccoura=
ged by this thought.=C2=A0 All proposals get pulled in all directions.=C2=
=A0 It doesn't mean it won't be successful.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">If you want to start having that discussion, =
fine. And maybe in preparation of the completion of the Ranges TS (probably=
version 2), it might be appropriate to start collecting ideas now. But jus=
t be prepared for where it leads.</blockquote><div>=C2=A0<br></div><div>I t=
hink the right thing to do would be to write a proposal of vararray for LEW=
G JAX, carefully considering and exploring all the options and making a rec=
ommendation for a course of action - and see what they have to say.</div><d=
iv><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114199743c74510528c04675--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 7 Jan 2016 17:55:59 +0200
Raw View
On 7 January 2016 at 17:39, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> Oh and since we're talking about changing the container paradigm, why not
>> throw away allocators and use a better allocation interface? Maybe one that
>> understands the concept of "type erasure". There are going to be API
>> suggestions for the associative containers. There are going to be changes
>> suggested for list and deque. Someone will probably suggest a blanket ban on
>> any throwing-move container implementation for the new containers (I
>> wouldn't say no to that one). And so on.
> This is some sort of slippery slope fallacy. Noone is going to reject
> vararray because they think we should wait for an allocators v2. Very few
> people use anything but the default allocators anyway - virtually noone
> cares.
There's no shortage of vocal proponents of allocators in WG21, so I don't know
what you mean by "virtually noone cares". The high-performance crowd cares,
embedded programmers care, there's a whole host of audiences who care.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 7 Jan 2016 17:15:02 +0100
Raw View
--001a1147dc98e48d150528c0c5ec
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 7, 2016 at 4:55 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 7 January 2016 at 17:39, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
> >> Oh and since we're talking about changing the container paradigm, why
> not
> >> throw away allocators and use a better allocation interface? Maybe one
> that
> >> understands the concept of "type erasure". There are going to be API
> >> suggestions for the associative containers. There are going to be
> changes
> >> suggested for list and deque. Someone will probably suggest a blanket
> ban on
> >> any throwing-move container implementation for the new containers (I
> >> wouldn't say no to that one). And so on.
> > This is some sort of slippery slope fallacy. Noone is going to reject
> > vararray because they think we should wait for an allocators v2. Very
> few
> > people use anything but the default allocators anyway - virtually noone
> > cares.
>
> There's no shortage of vocal proponents of allocators in WG21, so I don't
> know
> what you mean by "virtually noone cares". The high-performance crowd cares,
> embedded programmers care, there's a whole host of audiences who care.
What I mean is (and admittedly I don't have exact numbers) that I claim
99.99%+ of instantiations of the standard container templates (like
std::vector) have a defaulted allocator argument. Interpret that as you
will. While certainly we won't break the existing allocator
infrastructure, I expect the voters will not give some new version of
allocators "right of way" over more mainstream proposals and use cases.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1147dc98e48d150528c0c5ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 7, 2016 at 4:55 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On 7 January 2016 at 17:39, Andrew Tomazos <<a href=3D"mailto:a=
ndrewtomazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br>
>> Oh and since we're talking about changing the container paradi=
gm, why not<br>
>> throw away allocators and use a better allocation interface? Maybe=
one that<br>
>> understands the concept of "type erasure". There are goi=
ng to be API<br>
>> suggestions for the associative containers. There are going to be =
changes<br>
>> suggested for list and deque. Someone will probably suggest a blan=
ket ban on<br>
>> any throwing-move container implementation for the new containers =
(I<br>
>> wouldn't say no to that one). And so on.<br>
> This is some sort of slippery slope fallacy.=C2=A0 Noone is going to r=
eject<br>
> vararray because they think we should wait for an allocators v2.=C2=A0=
Very few<br>
> people use anything but the default allocators anyway - virtually noon=
e<br>
> cares.<br>
<br>
</span>There's no shortage of vocal proponents of allocators in WG21, s=
o I don't know<br>
what you mean by "virtually noone cares". The high-performance cr=
owd cares,<br>
embedded programmers care, there's a whole host of audiences who care.<=
/blockquote><div><br></div><div>What I mean is (and admittedly I don't =
have exact numbers) that I claim 99.99%+ of instantiations of the standard =
container templates (like std::vector) have a defaulted allocator argument.=
=C2=A0 Interpret that as you will.=C2=A0 While certainly we won't break=
the existing allocator infrastructure, I expect the voters will not give s=
ome new version of allocators "right of way" over more mainstream=
proposals and use cases.<br></div><div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1147dc98e48d150528c0c5ec--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 7 Jan 2016 11:21:19 -0800 (PST)
Raw View
------=_Part_3015_1389218862.1452194479498
Content-Type: multipart/alternative;
boundary="----=_Part_3016_1891159429.1452194479499"
------=_Part_3016_1891159429.1452194479499
Content-Type: text/plain; charset=UTF-8
On Thursday, January 7, 2016 at 10:39:24 AM UTC-5, Andrew Tomazos wrote:
>
> On Thu, Jan 7, 2016 at 3:41 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Ranges makes modifications to the iterator paradigm. Since it makes such
>> sweeping changes to iterators and creates new algorithms (and new concepts
>> like ranges and adapters), it brings with it the possibility of "STL2",
>> which is good. But here's the thing: until we actually get all of that
>> stuff *finished*, we're not in a position to start specifying how
>> containers should function.
>>
>
> That's the standard dilemma between waiting for the slow big vague new
> thing or making fast incremental concrete changes. The best approach is to
> propose both, and let the committee gate/merge things as they will.
>
No, I can't say that I agree with that. The committee isn't good at merging
things. Or have you looked at std::string's interface lately?
I'd love to see a new vector where you can extract the memory from it as a
>> free-standing object, and pass it around elsewhere (along with the
>> allocator, of course). It could be given to a C-style API. Or more to the
>> point, a C-style API could *provide* such data, which could be used as
>> the initial storage for the vector (again, along with the allocator).
>>
>
> Why can't that be proposed as an extension to vector today? I don't see
> the relevance. It seems orthogonal to everything discussed, and a
> compatible extension to either/both vector and vararray.
>
It certainly could be. But if you're going to revamp the allocation
mechanism (which has to be a breaking change if it's going to be useful),
then whatever type you use has to use the new allocation mechanism.
Which means you'd need two of them: one for STL1-style allocators and one
for STL2-style allocators.
And if you're doing this for vector, you'd have to do it for string. Both
>> what I just suggested and explicit sizing for small-strings.
>>
>
> Is there an existing practice of small_string? Isn't there already a
> "small string optimization" possible and used in std::string? std::string
> is mainly targetted at text, whereas vector/vararray are targeted at
> contiguous homogenous sequences of an arbitrary type. They are
> intentionally distinct.
>
Yes, but different `std::string` implementations have *different* small
sizes. I personally like Microsoft's approach, where the small size is 16
characters, no matter how big the character is. As I understand it,
libc++'s approach is to pick the size such that `std::string` is never
bigger than 3 pointers. So their `std::string<char>` provides a small size
of 12 in 32-bits and 24 in 64-bits. But `std::string<char16_t>` only gives
you 6 in 32-bits, which is not exactly a useful small size.
Members of SG14 and people here have expressed interest in having the
ability to directly specify the number of characters. So if we're going to
have `small_vector`, we should have a corresponding `small_string`, with
`std::string` being an implementation-defined selection from. That one at
least shouldn't cause ABI issues.
Some people will want a vector that can have an explicit limit to how big
>> it gets.
>>
>
> This could be a feature of vararray, it just depends how much demand there
> is. The tradeoff is between additional complexity versus extra
> functionality. Whether it is worth it depends on how much it would be used.
>
There's lots of demand. Just talk to the SG14 guys. Go look at EASTL. The
same kind of people who care about `small_vector` are the same kind who
would care about a dynarray class.
Oh and since we're talking about changing the container paradigm, why not
>> throw away allocators and use a better allocation interface? Maybe one that
>> understands the concept of "type erasure". There are going to be API
>> suggestions for the associative containers. There are going to be changes
>> suggested for list and deque. Someone will probably suggest a blanket ban
>> on any throwing-move container implementation for the new containers (I
>> wouldn't say no to that one). And so on.
>>
>
> This is some sort of slippery slope fallacy. Noone is going to reject
> vararray because they think we should wait for an allocators v2. Very few
> people use anything but the default allocators anyway - virtually noone
> cares.
>
If you want to believe that, I can't stop you. But you may want to take a
look around at other C++ programmers outside of your usual programming
circles.
The discussion you're wanting to start is *endless*. Everyone and their
>> mother will come out and add their own pet feature.
>>
>
> I don't agree. A proposal of vararray should not be disccouraged by this
> thought. All proposals get pulled in all directions. It doesn't mean it
> won't be successful.
>
Please remember the context of my statements. Namely, I was replying to his
"option E", which was to propose this as replacement to `vector` as part of
some STL2 effort.
My point is that his talk about ranges and STL2 containers is *woefully*
premature. Let `small_vector` work within the existing paradigm, without
trying to replace or improve `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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3016_1891159429.1452194479499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, January 7, 2016 at 10:39:24 AM UTC-5, Andrew Tomazos wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Jan 7, 2016 at 3:41 PM, Nicol Bolas <span dir=3D"l=
tr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
3YWJTRoBFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div>Ranges makes modifications to the iterator paradigm. Since it makes =
such sweeping changes to iterators and creates new algorithms (and new conc=
epts like ranges and adapters), it brings with it the possibility of "=
STL2", which is good. But here's the thing: until we actually get =
all of that stuff=C2=A0<i>finished</i>, we're not in a position to star=
t specifying how containers should function.<br></div></blockquote><div><br=
></div><div>That's the standard dilemma between waiting for the slow bi=
g vague new thing or making fast incremental concrete changes.=C2=A0 The be=
st approach is to propose both, and let the committee gate/merge things as =
they will.</div></div></div></div></blockquote><div><br>No, I can't say=
that I agree with that. The committee isn't good at merging things. Or=
have you looked at std::string's interface lately?<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I'd love to=
see a new vector where you can extract the memory from it as a free-standi=
ng object, and pass it around elsewhere (along with the allocator, of cours=
e).=C2=A0 It could be given to a C-style API. Or more to the point, a C-sty=
le API could <i>provide</i> such data, which could be used as the initial s=
torage for the vector (again, along with the allocator).</div></blockquote>=
<div><br></div><div>Why can't that be proposed as an extension to vecto=
r today?=C2=A0 I don't see the relevance.=C2=A0 It seems orthogonal to =
everything discussed, and a compatible extension to either/both vector and =
vararray.</div></div></div></div></blockquote><div><br>It certainly could b=
e. But if you're going to revamp the allocation mechanism (which has to=
be a breaking change if it's going to be useful), then whatever type y=
ou use has to use the new allocation mechanism.<br><br>Which means you'=
d need two of them: one for STL1-style allocators and one for STL2-style al=
locators.<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 di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>And if you're doing this for vector, you'd have to do=
it for string. Both what I just suggested and explicit sizing for small-st=
rings.<br></div></blockquote><div><br></div><div>Is there an existing pract=
ice of small_string?=C2=A0 Isn't there already a "small string opt=
imization" possible and used in std::string? =C2=A0std::string is main=
ly targetted at text, whereas vector/vararray are targeted at contiguous ho=
mogenous sequences of an arbitrary type.=C2=A0 They are intentionally disti=
nct.</div></div></div></div></blockquote><div><br>Yes, but different `std::=
string` implementations have <i>different</i> small sizes. I personally lik=
e Microsoft's approach, where the small size is 16 characters, no matte=
r how big the character is. As I understand it, libc++'s approach is to=
pick the size such that `std::string` is never bigger than 3 pointers. So =
their `std::string<char>` provides a small size of 12 in 32-bits and =
24 in 64-bits. But `std::string<char16_t>` only gives you 6 in 32-bit=
s, which is not exactly a useful small size.<br><br>Members of SG14 and peo=
ple here have expressed interest in having the ability to directly specify =
the number of characters. So if we're going to have `small_vector`, we =
should have a corresponding `small_string`, with `std::string` being an imp=
lementation-defined selection from. That one at least shouldn't cause A=
BI issues.<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 d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div>Some people will want a vector that can have an explicit lim=
it to how big it gets.</div></blockquote><div><br></div><div>This could be =
a feature of vararray, it just depends how much demand there is.=C2=A0 The =
tradeoff is between additional complexity versus extra functionality.=C2=A0=
Whether it is worth it depends on how much it would be used.</div></div></=
div></div></blockquote><div><br>There's lots of demand. Just talk to th=
e SG14 guys. Go look at EASTL. The same kind of people who care about `smal=
l_vector` are the same kind who would care about a dynarray class.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v 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> Oh and since w=
e're talking about changing the container paradigm, why not throw away =
allocators and use a better allocation interface? Maybe one that understand=
s the concept of "type erasure". There are going to be API sugges=
tions for the associative containers. There are going to be changes suggest=
ed for list and deque. Someone will probably suggest a blanket ban on any t=
hrowing-move container implementation for the new containers (I wouldn'=
t say no to that one). And so on.<br></div></blockquote><div><br></div><div=
>This is some sort of slippery slope fallacy.=C2=A0 Noone is going to rejec=
t vararray because they think we should wait for an allocators v2.=C2=A0 Ve=
ry few people use anything but the default allocators anyway - virtually no=
one cares.</div></div></div></div></blockquote><div><br>If you want to beli=
eve that, I can't stop you. But you may want to take a look around at o=
ther C++ programmers outside of your usual programming circles.<br><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 dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The dis=
cussion you're wanting to start is <i>endless</i>. Everyone and their m=
other will come out and add their own pet feature.</div></blockquote><div><=
br></div><div>I don't agree.=C2=A0 A proposal of vararray should not be=
disccouraged by this thought.=C2=A0 All proposals get pulled in all direct=
ions.=C2=A0 It doesn't mean it won't be successful.</div></div></di=
v></div></blockquote><div><br>Please remember the context of my statements.=
Namely, I was replying to his "option E", which was to propose t=
his as replacement to `vector` as part of some STL2 effort.<br><br>My point=
is that his talk about ranges and STL2 containers is <i>woefully</i> prema=
ture. Let `small_vector` work within the existing paradigm, without trying =
to replace or improve `vector`.<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"></div></div></d=
iv>
</blockquote>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3016_1891159429.1452194479499--
------=_Part_3015_1389218862.1452194479498--
.
Author: Patrice Roy <patricer@gmail.com>
Date: Thu, 7 Jan 2016 20:41:09 -0500
Raw View
--089e01184e627d10300528c8ae23
Content-Type: text/plain; charset=UTF-8
I'd be one of those who would react to throwing away allocators unless
there's a very, very good replacement. The SG14 crowd uses this a lot (they
might complain about the way things work, but in principle they are heavy
users of allocators). Let's not forget that there are many kinds of C++
users out there, and that there are reasons for them being C++ users :)
2016-01-07 10:55 GMT-05:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 7 January 2016 at 17:39, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
> >> Oh and since we're talking about changing the container paradigm, why
> not
> >> throw away allocators and use a better allocation interface? Maybe one
> that
> >> understands the concept of "type erasure". There are going to be API
> >> suggestions for the associative containers. There are going to be
> changes
> >> suggested for list and deque. Someone will probably suggest a blanket
> ban on
> >> any throwing-move container implementation for the new containers (I
> >> wouldn't say no to that one). And so on.
> > This is some sort of slippery slope fallacy. Noone is going to reject
> > vararray because they think we should wait for an allocators v2. Very
> few
> > people use anything but the default allocators anyway - virtually noone
> > cares.
>
> There's no shortage of vocal proponents of allocators in WG21, so I don't
> know
> what you mean by "virtually noone cares". The high-performance crowd cares,
> embedded programmers care, there's a whole host of audiences who care.
>
> --
>
> ---
> 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
> https://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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01184e627d10300528c8ae23
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd be one of those who would react to throwing away a=
llocators unless there's a very, very good replacement. The SG14 crowd =
uses this a lot (they might complain about the way things work, but in prin=
ciple they are heavy users of allocators). Let's not forget that there =
are many kinds of C++ users out there, and that there are reasons for them =
being C++ users :)<br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2016-01-07 10:55 GMT-05:00 Ville Voutilainen <span dir=3D"ltr">&=
lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.v=
outilainen@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n class=3D"">On 7 January 2016 at 17:39, Andrew Tomazos <<a href=3D"mail=
to:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br>
>> Oh and since we're talking about changing the container paradi=
gm, why not<br>
>> throw away allocators and use a better allocation interface? Maybe=
one that<br>
>> understands the concept of "type erasure". There are goi=
ng to be API<br>
>> suggestions for the associative containers. There are going to be =
changes<br>
>> suggested for list and deque. Someone will probably suggest a blan=
ket ban on<br>
>> any throwing-move container implementation for the new containers =
(I<br>
>> wouldn't say no to that one). And so on.<br>
> This is some sort of slippery slope fallacy.=C2=A0 Noone is going to r=
eject<br>
> vararray because they think we should wait for an allocators v2.=C2=A0=
Very few<br>
> people use anything but the default allocators anyway - virtually noon=
e<br>
> cares.<br>
<br>
</span>There's no shortage of vocal proponents of allocators in WG21, s=
o I don't know<br>
what you mean by "virtually noone cares". The high-performance cr=
owd cares,<br>
embedded programmers care, there's a whole host of audiences who care.<=
br>
<div class=3D"HOEnZb"><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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e01184e627d10300528c8ae23--
.
Author: Tristan Brindle <tcbrindle@gmail.com>
Date: Fri, 8 Jan 2016 15:27:22 +1300
Raw View
> On 8/01/2016, at 3:41 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Also, if you're going to start saying "hey, new container paradigm!", the=
n there are going to be a lot of people who want in on that conversation.
Personally, I absolutely don=E2=80=99t want a new container *paradigm*. Wha=
t I want is a new container that=E2=80=99s identical to vector, except that=
it can optionally use some storage in the object itself to avoid the alloc=
ator in certain situations. That was what I suggested in the first place.
But consequences of that are that either
* You need to forbid people from creating small_vector/vararray with ze=
ro elements stack-reserved, or
* You need to make vararray<T, 0> and vector<T> the same type, which im=
plies a specialisation for vararray<bool, 0>, or
* If you do neither of these, you need to accept that people will start=
using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D, simply because =
they can use it generically without worrying about the bool case.
We =E2=80=94 or rather LEWG, most likely =E2=80=94 need to decide between o=
ne of these three cases.
My e-mail that you quoted was intended to suggest that the last option isn=
=E2=80=99t actually as terrible as it might seem, but for it to work we=E2=
=80=99d need to "get out in front=E2=80=9D and promote it this way from the=
start =E2=80=94 having a replacement vector sneak in by the back door is t=
he worst of all possibilities.
I certainly wasn=E2=80=99t looking to open a can of worms about new contain=
er models. I don=E2=80=99t think there is any realistic prospect of that =
=E2=80=94 and even if we were going to do such a thing, it would be wise to=
get a few years experience with ranges and concepts first, to see where (i=
f anywhere) the current container models are deficient, and to see what gro=
ws in the community.
Tristan
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Alisdair Meredith <alisdairm@icloud.com>
Date: Fri, 08 Jan 2016 00:07:26 -0500
Raw View
--Apple-Mail-E9E57E1E-ABBD-4501-A31E-B5D2116FDAB2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Note that if you make vector an alias template for even an identical implem=
entation and interface (complete with bool support) you still break users w=
ho specialize vector for their own user-defined types, as you cannot specia=
lize an alias template.
While I am interested in the idea of an optimized vector-like type, I would=
be very concerned at trying to make it part of our current vector - coupli=
ng thing for an apparent similarity that is not fundamental, tends to lead =
to overly constrained, more complicated solutions.
I would be more open to the idea in the context of "STL 2.0", where we migh=
t take a broader look at the design space of our containers in general.
Sent from my iPhone
> On Jan 7, 2016, at 6:02 AM, Tristan Brindle <tcbrindle@gmail.com> wrote:
>=20
>=20
>=20
>> On Thu, Jan 7, 2016 at 7:35 AM, Nevin Liber <nevin@eviloverlord.com> wro=
te:
>> I'd much rather we not use the word "vector" in the name for the initial=
discussion, as it limits thinking on design choices. No one says it has t=
o have exactly the same interface (no more, no less) as vector.
> =20
>>> Perhaps a better name would be `varray`, or variable array.
>>=20
>> I would say no. In C++, arrays refer to things that have exactly N elem=
ents (well, maybe not valarray; I don't know, as I've never had cause to us=
e it).
>=20
> Well, if you don't want to call it a vector and you don't want to call it=
an array, then we're rapidly running out of commonly-used terms for a line=
ar data structure. I'm pretty sure "list" is the wrong one to go for :-)
>=20
>> I also think that bike shedding the name at this point is the least of o=
ur worries. (Note: while I'm against it, calling it vector is not just a =
bike shedding issue.)
>=20
> I agree that bike-shedding on the name at this point is unhelpful, but if=
we=E2=80=99re going to talk about it then we need to call it something. So=
I suggest that purely for the purposes of this discussion, we follow Qt=E2=
=80=99s lead and refer to =E2=80=9Ca growable contiguous collection with ze=
ro or more elements preallocated=E2=80=9D as a "variable-length array" or v=
ararray, as suggested by Andrew.
>=20
>=20
> Moving on, I think everyone can agree that all of the following are true:
>=20
> i. We cannot change the interface of vector in any backwards-incompatibl=
e way. This includes removing the vector<bool> specialisation, at least in =
any reasonably short time frame =E2=80=94 it would require an alternative t=
o be available in the IS, plus at least one cycle of deprecation.
>=20
> ii. Declaring vector<T> to be an alias for vararray<T, 0> today would re=
quire vararray<bool, 0> to be specialised, due to (i).
>=20
> iii. We cannot allow vararray<T, 0> to be a separate type today, and at =
some point in the future declare vector to be an alias for it. This would b=
reak any code written in the intervening time which overloads on the two ty=
pes.
> =20
>=20
>=20
> This leads me to think that we have five alternatives:
>=20
> A. We do not consider vararray until such time as the vector<bool=
> specialisation is removed.
>=20
> B. We introduce vararray but forbid the zero case. We make no att=
empt to reconcile this with vector.
>=20
> C. We introduce vararray but forbid the zero case. Years pass, an=
d when/if vector<bool> is removed, we remove the zero prohibition and redef=
ine vector as an alias.
>=20
> D. We introduce vararray and permit the zero case. We hold our no=
ses and define vararray<bool, 0> to be specialised (at least temporarily) d=
ue to (ii), and redeclare vector to be an alias.
>=20
> E. We introduce vararray and permit the zero case with no bool sp=
ecialisation. Due to (iii), vector<T> and vararray<T, 0> must remain separa=
te types forever.
>=20
> (I believe these options are exhaustive, but if there are any other reali=
stic cases I haven't considered then please do suggest them.)
>=20
> Let=E2=80=99s have a look at each one in more detail.
>=20
> Option A
>=20
> The least interesting option, and one that really requires no further dis=
cussion. If we go for this, our time would be better spent trying to standa=
rdise boost::dynamic_bitset, as that's a likely requirement for the vector<=
bool> wart to be removed.
>=20
> Option B
>=20
> This was my initial suggestion, and one that I think is relatively self-c=
ontained and uncontroversial. It is effectively where the various small_vec=
tor implementations stand now. The advantage is that since it is unrelated =
to vector, there is no potential confusion for users as to which one should=
be used -- we tell people to use vector almost all the time, unless they h=
ave very particular needs that vararray (probably better named small_vector=
in this case) can help with. The downside is that as pointed out above, ba=
rring N=3D0 is inelegant and may be a pain for generic programming. Notably=
, this restriction was removed from array between TR1 and C++11.
>=20
> Option C
>=20
> Basically the same a Option B, except that we have the ability to "unlock=
" the zero case for generic programming at some point in the future. The co=
st of this is that vararray's API must be fixed to be no narrower than vect=
or's from the word go, whereas with Option B we have some leeway to propose=
a different API (but see below for a discussion about that).
>=20
> Option D
>=20
> With this option we remove any potential confusion between vararray and v=
ector; vector is just another name for a vararray which always uses the hea=
p. The downside, of course, is that we are still lumbered with the bool spe=
cialisation, which we'd still have to get rid of at some point down the lin=
e. But on the other hand, it leaves us no worse off than we are at the mome=
nt, and does not artificially prohibit the N=3D0 case. Whether we default t=
he second template parameter to 0 and encourage people to start saying "var=
array<int> v =3D { 1, 2, 3 };" is an open question. This option would requi=
re vararray's API to be a superset of vector's, due to (i).
>=20
> Option E
>=20
> This option gives us the most freedom, but is easily the most controversi=
al. If we allow vararray and vector to be completely independent, and permi=
t the N=3D0 case, then we have two containers that offer identical semantic=
s, except that vararray<bool> behaves properly. This being the case, we'd h=
ave to make the choice of telling people which one they should prefer, and =
it makes much more sense to say "always use vararray" than it does to say "=
use a vector unless you're dealing with bools or need stack-reservation, in=
which case use vector". Thus vector becomes redundant.
>=20
> We have the choice in this case of whether vararray offers an identical A=
PI to vector. If it does, then it becomes a drop-in replacement. We can pro=
mote vararray as the modern way to use a variable-length array -- free from=
the vector<bool> legacy, and with optional stack-reservation when you need=
it.
>=20
> On the other hand, in theory we have the freedom to design a new, "superi=
or" API for vararray if we wish. In theory that is, in practice we don't ac=
tually have much freedom at all, since we would of course want vararray to =
be a SequenceContainer. By the time most of those requirements are in place=
, you basically have the vector API anyway. In any case, we'd want to be co=
nsistent with list, deque, and developers' existing familiarity with vector=
, which again limits any choices we could make. It's a matter for debate of=
course, but unlike std::string and its hundreds of member functions, my op=
inion is that the vector API doesn't really have any particular warts that =
need removing. There is much to be gained from keeping vararray's API the s=
ame as vector's, and little to be lost; conversely, there is little to be g=
ained and much to be lost if we are gratuitously incompatible.
>=20
> Option E -- replacing std::vector as the default container! -- might seem=
at first glance to be unrealistic, perhaps even a good suggestion for an A=
pril Fool. At first I dismissed it out of hand, but having given it some mo=
re thought I'm warming to the idea. With the arrival of concepts and ranges=
, and the talk of "STL2", this is a unique opportunity to do something so r=
adical. A vararray, as proposed, is a strict superset of vector. It is neve=
r worse and sometimes better. We can easily maintain API compatibility. The=
hundreds of tutorials and millions of lines of code that use vector wouldn=
't suddenly be wrong, any more than the millions of lines of code that use =
pair are wrong now that tuple exists. There is an appetite in the C++ commu=
nity at the moment to embrace the new; if we are ever going to do something=
like this, now is the time.
>=20
> -------
>=20
> Phew! I think that covers just about every eventuality. If I've made any =
mistakes or left anything out please let me know. Otherwise, any thoughts o=
n the pros and cons of the various options would be great.
>=20
> Tristan
>=20
>=20
> --=20
>=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=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail-E9E57E1E-ABBD-4501-A31E-B5D2116FDAB2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Note that if you make vector an al=
ias template for even an identical implementation and interface (complete w=
ith bool support) you still break users who specialize vector for their own=
user-defined types, as you cannot specialize an alias template.</div><div =
id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">While I =
am interested in the idea of an optimized vector-like type, I would be very=
concerned at trying to make it part of our current vector - coupling thing=
for an apparent similarity that is not fundamental, tends to lead to overl=
y constrained, more complicated solutions.</div><div id=3D"AppleMailSignatu=
re"><br></div><div id=3D"AppleMailSignature">I would be more open to the id=
ea in the context of "STL 2.0", where we might take a broader look at the d=
esign space of our containers in general.<br><br>Sent from my iPhone</div><=
div><br>On Jan 7, 2016, at 6:02 AM, Tristan Brindle <<a href=3D"mailto:t=
cbrindle@gmail.com">tcbrindle@gmail.com</a>> wrote:<br><br></div><blockq=
uote type=3D"cite"><div><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Thu, Jan 7, 2016 at 7:35 AM, Nevin Liber <sp=
an dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>></span> wrote:<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"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I'd muc=
h rather we not use the word "vector" in the name <i>for the initial discus=
sion</i>, as it limits thinking on design choices. No one says it has=
to have exactly the same interface (no more, no less) as vector.</div></di=
v></div></div></blockquote><div> <br></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"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"> Perhaps a better name would be `varray`, or variabl=
e array.</blockquote><div><br></div></span><div>I would say no. In C+=
+, arrays refer to things that have exactly N elements (well, maybe not val=
array; I don't know, as I've never had cause to use it).</div></div></div><=
/div></blockquote><div><br></div><div>Well, if you don't want to call it a =
vector and you don't want to call it an array, then we're rapidly running o=
ut of commonly-used terms for a linear data structure. I'm pretty sure "lis=
t" is the wrong one to go for :-)</div><div><br></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"><div=
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></d=
iv><div>I also think that bike shedding the name at this point is the least=
of our worries. (Note: while I'm against it, calling it vector=
is not just a bike shedding issue.)</div></div><span class=3D""></span></d=
iv></div></blockquote><div><br></div><div><span style=3D"font-family:arial,=
helvetica,sans-serif;color:rgb(0,0,0)">I agree that bike-shedding on the na=
me at this point is unhelpful, but if we=E2=80=99re going to talk about it =
then we need to call it </span><span style=3D"font-family:arial,helvet=
ica,sans-serif;color:rgb(0,0,0)"><i>something</i></span><span style=3D"font=
-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">. So I suggest</span><=
span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">&nbs=
p;</span><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,=
0,0)">that purely <i>for the purposes of this discussion</i>, we follow Qt=
=E2=80=99s lead and refer to =E2=80=9Ca growable contiguous collection with=
zero or more elements</span><span style=3D"font-family:arial,helvetica,san=
s-serif;color:rgb(0,0,0)"> </span><span style=3D"font-family:arial,hel=
vetica,sans-serif;color:rgb(0,0,0)">preallocated=E2=80=9D as a "variable-le=
ngth array" or </span><span style=3D"color:rgb(0,0,0)"><font face=3D"m=
onospace, monospace">vararray</font></span><span style=3D"font-family:arial=
,helvetica,sans-serif;color:rgb(0,0,0)">, as suggested by Andrew.</span><br=
style=3D"color:rgb(0,0,0);font-family:monospace;font-size:11px"></div><div=
><br></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica=
,sans-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-fam=
ily:arial,helvetica,sans-serif">Moving on, I think everyone can agree that =
all of the following are true:</span><br></div><font face=3D"arial, helveti=
ca, sans-serif"><br style=3D"color:rgb(0,0,0)"></font><span class=3D"" styl=
e=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0);white-space:pr=
e"> </span><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(=
0,0,0)">i. We cannot change the interface of </span><span style=3D"col=
or:rgb(0,0,0)"><font face=3D"monospace, monospace">vector</font></span><spa=
n style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"> i=
n any backwards-incompatible way. This includes removing the </span><span s=
tyle=3D"color:rgb(0,0,0)"><font face=3D"monospace, monospace">vector<boo=
l></font></span><span style=3D"font-family:arial,helvetica,sans-serif;co=
lor:rgb(0,0,0)"> specialisation, at</span><span style=3D"font-family:arial,=
helvetica,sans-serif;color:rgb(0,0,0)"> </span><span style=3D"font-fam=
ily:arial,helvetica,sans-serif;color:rgb(0,0,0)">least in any reasonably sh=
ort time frame =E2=80=94 it would require an alternative to be available in=
the IS, plus at least one cycle of deprecation.</span><font face=3D"arial,=
helvetica, sans-serif"><br><font color=3D"#000000"><br></font></font><span=
class=3D"" style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0=
);white-space:pre"> </span><span style=3D"font-family:arial,helvetica,sans-=
serif;color:rgb(0,0,0)">ii. Declaring </span><span style=3D"color:rgb(0,0,0=
)"><font face=3D"monospace, monospace">vector<T></font></span><span s=
tyle=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"> to be an =
alias for </span><span style=3D"color:rgb(0,0,0)"><font face=3D"monospace, =
monospace">vararray<T, 0></font></span><span style=3D"font-family:ari=
al,helvetica,sans-serif;color:rgb(0,0,0)"> today would require </span><span=
style=3D"color:rgb(0,0,0)"><font face=3D"monospace, monospace">vararray<=
;bool, 0></font></span><span style=3D"font-family:arial,helvetica,sans-s=
erif;color:rgb(0,0,0)"> to be specialised, due to (i).</span><font face=3D"=
arial, helvetica, sans-serif"><br><font color=3D"#000000"><br></font></font=
><span class=3D"" style=3D"font-family:arial,helvetica,sans-serif;color:rgb=
(0,0,0);white-space:pre"> </span><span style=3D"font-family:arial,helvetica=
,sans-serif;color:rgb(0,0,0)">iii. We cannot allow </span><span style=3D"co=
lor:rgb(0,0,0)"><font face=3D"monospace, monospace">vararray<T, 0></f=
ont></span><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(=
0,0,0)"> to be a separate type today, and at some point in the future decla=
re </span><span style=3D"color:rgb(0,0,0)"><font face=3D"monospace, monospa=
ce">vector</font></span><span style=3D"font-family:arial,helvetica,sans-ser=
if;color:rgb(0,0,0)"> to be an alias for it</span><span style=3D"font-famil=
y:arial,helvetica,sans-serif;color:rgb(0,0,0)">. This would break any code =
written in the intervening time which overloads on the two types.</span><fo=
nt face=3D"arial, helvetica, sans-serif"><br></font><div> </div><div><=
br></div><div><br></div>This leads me to think that we have five alternativ=
es:<br><br> A. We do not consider <font fac=
e=3D"monospace, monospace">vararray</font> until such time as the <font fac=
e=3D"monospace, monospace">vector<bool></font> specialisation is remo=
ved.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&=
nbsp; B. We introduce <font face=3D"monospace, mo=
nospace">vararray</font><font face=3D"arial, helvetica, sans-serif"> <=
/font>but forbid the zero case. We make no attempt to reconcile this with&n=
bsp;<font face=3D"monospace, monospace">vector</font>.<br></div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote"> =
C. We introduce <font face=3D"monospace, monospace">vararray </=
font>but forbid the zero case. Years pass, and when/if <font face=3D"monosp=
ace, monospace">vector<bool></font> is removed, we remove the zero pr=
ohibition and redefine <font face=3D"monospace, monospace">vector</font> as=
an alias.</div><div class=3D"gmail_quote"><br> =
D. We introduce <font face=3D"monospace, monospace">vararray</font> and per=
mit the zero case. We hold our noses and define <font face=3D"monospace, mo=
nospace">vararray<bool, 0></font> to be specialised (at least tempora=
rily) due to (ii), and redeclare <font face=3D"monospace, monospace">vector=
</font> to be an alias.<br><br> E. We introduce =
<font face=3D"monospace, monospace">vararray</font> and permit the zero cas=
e with no <font face=3D"monospace, monospace">bool</font> specialisation. D=
ue to (iii), <font face=3D"monospace, monospace">vector<T></font> and=
<font face=3D"monospace, monospace">vararray<T, 0></font> must remai=
n separate types forever.<br><br>(I believe these options are exhaustive, b=
ut if there are any other realistic cases I haven't considered then please =
do suggest them.)<br><br>Let=E2=80=99s have a look at each one in more deta=
il.<br><br><b>Option A</b></div><div class=3D"gmail_quote"><b><br></b></div=
><div class=3D"gmail_quote">The least interesting option, and one that real=
ly requires no further discussion. If we go for this, our time would be bet=
ter spent trying to standardise <font face=3D"monospace, monospace">boost::=
dynamic_bitset</font>, as that's a likely requirement for the <font face=3D=
"monospace, monospace">vector<bool></font> wart to be removed.</div><=
div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><b>Option B<=
/b></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Th=
is was my initial suggestion, and one that I think is relatively self-conta=
ined and uncontroversial. It is effectively where the various <font face=3D=
"monospace, monospace">small_vector</font> implementations stand now. The a=
dvantage is that since it is unrelated to <font face=3D"monospace, monospac=
e">vector</font>, there is no potential confusion for users as to which one=
should be used -- we tell people to use <font face=3D"monospace, monospace=
">vector</font> almost all the time, unless they have very particular needs=
that <font face=3D"monospace, monospace">vararray</font> (probably better =
named <font face=3D"monospace, monospace">small_vector</font> in this case)=
can help with. The downside is that as pointed out above, barring N=3D0 is=
inelegant and may be a pain for generic programming. Notably, this restric=
tion was removed from <font face=3D"monospace, monospace">array</font><font=
face=3D"arial, helvetica, sans-serif"> between TR1 and C++11.</font><=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><font =
face=3D"arial, helvetica, sans-serif"><b>Option C</b></font></div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Basically the same a=
Option B, except that we have the ability to "unlock" the zero case for ge=
neric programming at some point in the future. The cost of this is that <fo=
nt face=3D"monospace, monospace">vararray</font>'s API must be fixed to be =
no narrower than <font face=3D"monospace, monospace">vector</font>'s f=
rom the word go, whereas with Option B we have some leeway to propose a dif=
ferent API (but see below for a discussion about that).</div><div class=3D"=
gmail_quote"><b><br></b></div><div class=3D"gmail_quote"><b>Option D</b></d=
iv><div class=3D"gmail_quote"><b><br></b></div><div class=3D"gmail_quote">W=
ith this option we remove any potential confusion between <font face=3D"mon=
ospace, monospace">vararray</font> and <font face=3D"monospace, monospace">=
vector</font><font face=3D"arial, helvetica, sans-serif">;</font> <fon=
t face=3D"monospace, monospace">vector</font> is just another name for a&nb=
sp;<font face=3D"monospace, monospace">vararray</font> which always uses th=
e heap. The downside, of course, is that we are still lumbered with the <fo=
nt face=3D"monospace, monospace">bool</font> specialisation, which we'd sti=
ll have to get rid of at some point down the line. But on the other hand, i=
t leaves us no worse off than we are at the moment, and does not artificial=
ly prohibit the N=3D0 case. Whether we default the second template paramete=
r to 0 and encourage people to start saying "<font face=3D"monospace, monos=
pace">vararray<int> v =3D { 1, 2, 3 };</font>" is an open question. T=
his option would require <font face=3D"monospace, monospace">vararray</font=
>'s API to be a superset of <font face=3D"monospace, monospace">vector=
</font>'s, due to (i).</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote"><b>Option E</b></div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">This option gives us the most freedom, but is ea=
sily the most controversial. If we allow <font face=3D"monospace, monospace=
">vararray</font> and <font face=3D"monospace, monospace">vector</font> to =
be completely independent, and permit the N=3D0 case, then we have two cont=
ainers that offer identical semantics, except that <font face=3D"monospace,=
monospace">vararray<bool></font> behaves properly. This being the ca=
se, we'd have to make the choice of telling people which one they should pr=
efer, and it makes much more sense to say "always use <font face=3D"monospa=
ce, monospace">vararray</font>" than it does to say "use a <font face=3D"mo=
nospace, monospace">vector</font> unless you're dealing with <font face=3D"=
monospace, monospace">bool</font>s or need stack-reservation, in which case=
use <font face=3D"monospace, monospace">vector</font>". Thus <font face=3D=
"monospace, monospace">vector</font> becomes redundant.</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">We have the choice in thi=
s case of whether <font face=3D"monospace, monospace">vararray</font> offer=
s an identical API to <font face=3D"monospace, monospace">vector</font>. If=
it does, then it becomes a drop-in replacement. We can promote <font face=
=3D"monospace, monospace">vararray</font> as the modern way to use a variab=
le-length array -- free from the <font face=3D"monospace, monospace">vector=
<bool></font> legacy, and with optional stack-reservation when you ne=
ed it.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>On the other hand, in theory we have the freedom to design a new, "superio=
r" API for <font face=3D"monospace, monospace">vararray</font> if we wish. =
In theory that is, in practice we don't actually have much freedom at all, =
since we would of course want <font face=3D"monospace, monospace">vararray<=
/font> to be a <a href=3D"http://en.cppreference.com/w/cpp/concept/Seq=
uenceContainer">SequenceContainer</a>. By the time most of those requiremen=
ts are in place, you basically have the <font face=3D"monospace, monospace"=
>vector</font> API anyway. In any case, we'd want to be consistent with <fo=
nt face=3D"monospace, monospace">list</font>, <font face=3D"monospace, mono=
space">deque</font>, and developers' existing familiarity with <font face=
=3D"monospace, monospace">vector</font><font face=3D"arial, helvetica, sans=
-serif">, which again limits any choices we could make.</font> It's a =
matter for debate of course, but unlike <font face=3D"monospace, monospace"=
>std::string</font> and its hundreds of member functions, my opinion is tha=
t the <font face=3D"monospace, monospace">vector</font> API doesn't really =
have any particular warts that need removing. There is much to be gained fr=
om keeping <font face=3D"monospace, monospace">vararray</font>'s API the sa=
me as <font face=3D"monospace, monospace">vector</font>'s, and little to be=
lost; conversely, there is little to be gained and much to be lost if we a=
re gratuitously incompatible.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">Option E -- replacing <font face=3D"monospace, mono=
space">std::vector</font><font face=3D"arial, helvetica, sans-serif"> =
as the default container</font>! -- might seem at first glance to=
be unrealistic, perhaps even a good suggestion for an April Fool. At first=
I dismissed it out of hand, but having given it some more thought I'm warm=
ing to the idea. With the arrival of concepts and ranges, and the talk of "=
STL2", this is a unique opportunity to do something so radical. A <font fac=
e=3D"monospace, monospace">vararray</font>, as proposed, is a strict supers=
et of <font face=3D"monospace, monospace">vector</font>. It is never worse =
and sometimes better. We can easily maintain API compatibility. The hundred=
s of tutorials and millions of lines of code that use <font face=3D"monospa=
ce, monospace">vector</font> wouldn't suddenly be wrong, any more than the =
millions of lines of code that use <font face=3D"monospace, monospace">pair=
</font> are wrong now that <font face=3D"monospace, monospace">tuple</=
font> exists. There is an appetite in the C++ community at the moment =
to embrace the new; if we are ever going to do something like this, now is =
the time.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">-------</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">Phew! I think that covers just about every eventuality. If I've made =
any mistakes or left anything out please let me know. Otherwise, any though=
ts on the pros and cons of the various options would be great.</div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Tristan</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><b><br></b></div=
></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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
</div></blockquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail-E9E57E1E-ABBD-4501-A31E-B5D2116FDAB2--
.
Author: Alisdair Meredith <alisdairm@icloud.com>
Date: Fri, 08 Jan 2016 00:12:03 -0500
Raw View
--Apple-Mail-ADBFCD5F-E204-4E8C-AC87-AE2C2A136D1C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If you never use specialized allocators, that is easy to imagine. If you d=
o use customized allocator, you might well be familiar with code bases wher=
e the figure is the other way around. It is exceedingly rare for me to see=
a container using std::allocator as it allocator parameter - perhaps not 9=
9.99% rare, as that is a surprisingly high barrier, but probably over the 9=
9% case.
I do not claim to be the common case, but I think this is common where cust=
om allocators are used. If you need them, you really need them. Otherwise=
, they are a solution looking for a problem. It is no accident that the li=
brary allows you to painlessly ignore the feature unless you actually need =
it.
Sent from my iPhone
> On Jan 7, 2016, at 11:15 AM, Andrew Tomazos <andrewtomazos@gmail.com> wro=
te:
>=20
>> On Thu, Jan 7, 2016 at 4:55 PM, Ville Voutilainen <ville.voutilainen@gma=
il.com> wrote:
>> On 7 January 2016 at 17:39, Andrew Tomazos <andrewtomazos@gmail.com> wro=
te:
>> >> Oh and since we're talking about changing the container paradigm, why=
not
>> >> throw away allocators and use a better allocation interface? Maybe on=
e that
>> >> understands the concept of "type erasure". There are going to be API
>> >> suggestions for the associative containers. There are going to be cha=
nges
>> >> suggested for list and deque. Someone will probably suggest a blanket=
ban on
>> >> any throwing-move container implementation for the new containers (I
>> >> wouldn't say no to that one). And so on.
>> > This is some sort of slippery slope fallacy. Noone is going to reject
>> > vararray because they think we should wait for an allocators v2. Very=
few
>> > people use anything but the default allocators anyway - virtually noon=
e
>> > cares.
>>=20
>> There's no shortage of vocal proponents of allocators in WG21, so I don'=
t know
>> what you mean by "virtually noone cares". The high-performance crowd car=
es,
>> embedded programmers care, there's a whole host of audiences who care.
>=20
> What I mean is (and admittedly I don't have exact numbers) that I claim 9=
9.99%+ of instantiations of the standard container templates (like std::vec=
tor) have a defaulted allocator argument. Interpret that as you will. Whi=
le certainly we won't break the existing allocator infrastructure, I expect=
the voters will not give some new version of allocators "right of way" ove=
r more mainstream proposals and use cases.
>=20
> --=20
>=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=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail-ADBFCD5F-E204-4E8C-AC87-AE2C2A136D1C
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>If you never use specialized alloc=
ators, that is easy to imagine. If you do use customized allocator, y=
ou might well be familiar with code bases where the figure is the other way=
around. It is exceedingly rare for me to see a container using std::=
allocator as it allocator parameter - perhaps not 99.99% rare, as that is a=
surprisingly high barrier, but probably over the 99% case.</div><div id=3D=
"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">I do not clai=
m to be the common case, but I think this is common where custom allocators=
are used. If you need them, you really need them. Otherwise, t=
hey are a solution looking for a problem. It is no accident that the =
library allows you to painlessly ignore the feature unless you actually nee=
d it.<br><br>Sent from my iPhone</div><div><br>On Jan 7, 2016, at 11:15 AM,=
Andrew Tomazos <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazo=
s@gmail.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><div=
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, =
Jan 7, 2016 at 4:55 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"=
mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 7 January 2016 at 17:39, Andrew Tomazos <<a href=3D"mailto:andr=
ewtomazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:<br>
>> Oh and since we're talking about changing the container paradigm, =
why not<br>
>> throw away allocators and use a better allocation interface? Maybe=
one that<br>
>> understands the concept of "type erasure". There are going to be A=
PI<br>
>> suggestions for the associative containers. There are going to be =
changes<br>
>> suggested for list and deque. Someone will probably suggest a blan=
ket ban on<br>
>> any throwing-move container implementation for the new containers =
(I<br>
>> wouldn't say no to that one). And so on.<br>
> This is some sort of slippery slope fallacy. Noone is going to r=
eject<br>
> vararray because they think we should wait for an allocators v2. =
Very few<br>
> people use anything but the default allocators anyway - virtually noon=
e<br>
> cares.<br>
<br>
</span>There's no shortage of vocal proponents of allocators in WG21, so I =
don't know<br>
what you mean by "virtually noone cares". The high-performance crowd cares,=
<br>
embedded programmers care, there's a whole host of audiences who care.</blo=
ckquote><div><br></div><div>What I mean is (and admittedly I don't have exa=
ct numbers) that I claim 99.99%+ of instantiations of the standard containe=
r templates (like std::vector) have a defaulted allocator argument. I=
nterpret that as you will. While certainly we won't break the existin=
g allocator infrastructure, I expect the voters will not give some new vers=
ion of allocators "right of way" over more mainstream proposals and use cas=
es.<br></div><div><br></div></div></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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
</div></blockquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail-ADBFCD5F-E204-4E8C-AC87-AE2C2A136D1C--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 08 Jan 2016 00:15:06 -0800
Raw View
On Friday 08 January 2016 00:07:26 Alisdair Meredith wrote:
> users who specialize vector for their own user-defined types, as you cannot
> specialize an alias template.
Is that even allowed by the standard?
--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Nevin \":-)\" Liber" <"Nevin ":-)" Liber" <nliber@gmail.com>>
Date: Fri, 8 Jan 2016 08:08:25 -0600
Raw View
> On Jan 8, 2016, at 2:15 AM, Thiago Macieira <thiago@macieira.org> wrote:
>
> Is that even allowed by the standard?
Yes. If not specifically forbidden, users can specialize it.
Personally, I think we should list what can be specialize and forbid the rest by default, but that ship sailed a long time ago for the current library.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jan 2016 07:18:42 -0800 (PST)
Raw View
------=_Part_262_1580747714.1452266322398
Content-Type: multipart/alternative;
boundary="----=_Part_263_1449359666.1452266322398"
------=_Part_263_1449359666.1452266322398
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:
>
>
> > On 8/01/2016, at 3:41 AM, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:=20
> > Also, if you're going to start saying "hey, new container paradigm!",=
=20
> then there are going to be a lot of people who want in on that=20
> conversation.=20
>
> Personally, I absolutely don=E2=80=99t want a new container *paradigm*. W=
hat I=20
> want is a new container that=E2=80=99s identical to vector, except that i=
t can=20
> optionally use some storage in the object itself to avoid the allocator i=
n=20
> certain situations. That was what I suggested in the first place.=20
>
> But consequences of that are that either=20
>
> * You need to forbid people from creating small_vector/vararray with=
=20
> zero elements stack-reserved, or=20
>
> * You need to make vararray<T, 0> and vector<T> the same type, which=
=20
> implies a specialisation for vararray<bool, 0>, or
>
=20
>
* If you do neither of these, you need to accept that people will start=
=20
> using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D, simply because=
they can use it=20
> generically without worrying about the bool case.
>
On the one hand, the conceptual differences between `small_vector<T, 0>`=20
and `small_vector<T, *1*>` are minimal. Which means if you forbid the 0=20
case, or if you make the 0 case an alias of `vector` with its bool=20
specialization intact, people will just use `small_vector<T, 1>` to work=20
around it.
So `small_vector` is *going to* compete with `vector`, no matter what you=
=20
do.
However, there are substantive differences between `small_vector<T, 0>` and=
=20
`small_vector<T, 1>` Move behavior/iterator invalidation is a good example.=
=20
`small_vector<T, 0>` would function in every way exactly like `vector`,=20
while `small_vector<T, 1>` would function like a `small_vector<T, 20>`. Or=
=20
more to the point, like `string`. No matter how small the size is, as long=
=20
as it isn't zero, you can't guarantee the same move behavior.
Given these facts, we need to ask ourselves these questions:
1) Do we want to create a type that is intended to be special case, but=20
will compete with a fundamental library type beyond that special case, just=
=20
because of an idiotic decision made 20+ years ago?
2) If we do want that, do we want to encourage such competition by allowing=
=20
the new type to completely subsume all uses of the old?
After all, people are only supposed to use `small_vector` to be an=20
optimization. But the moment people brought up the fact that `small_vector`=
=20
wouldn't have a `bool` specialization, I started mentally doing a=20
find/replace for `vector` to `small_vector` in my code.
The correct answer to question 2 seems, to me, to be "yes". If there's=20
going to be competition, then the new type *ought to win*. It does nobody=
=20
any good to see template code using `small_vector<T, 1>` just to avoid the=
=20
`T =3D bool` case for `vector`. So `small_vector<T, 0>` should be in every=
=20
way equivalent to `vector`, and it should be interoperable with `vector`=20
(movement from one to the other). With the exception of `vector<bool>` of=
=20
course; `small_vector` shouldn't have that. If we're going to allow=20
`small_vector` to compete with `vector` outside of its particular=20
optimization domain, then just *replace it*.
So the big question is really #1: do we want to add a type, originally=20
proposed *solely* for a narrow case of optimization, that subsumes an=20
existing type which is widely used (not to mention promoted) in lots of C++=
?
I don't have an answer to that. My abject hatred for the `vector<bool>`=20
specialization (and my continued annoyance with the fact that nobody's put=
=20
forth any effort to fix it) makes me want to say "Hell yes!" At the same=20
time, I despise the idea of replacing a perfectly good class over some=20
idiotic experimental decision from 20+ years. I also hate the idea of using=
=20
a type outside of its intended purpose; `small_vector` is *supposed* to be=
=20
for a narrow optimization.
Plus, if there's going to be an eventual STL2 that includes containers, we=
=20
don't want to have to create a *third* dynamic array type. That's just too=
=20
confusing.
To me, the only viable solutions are:
1) Design `small_vector` so that it completely takes over `vector` in all=
=20
situations (except for people who like `vector<bool>`.
2) We don't have `small_vector` at all.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_263_1449359666.1452266322398
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
<br>> On 8/01/2016, at 3:41 AM, Nicol Bolas <<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"C2YSUHgkFAAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">jmck...@gmail.com</a>> wro=
te:
<br>> Also, if you're going to start saying "hey, new container=
paradigm!", then there are going to be a lot of people who want in on=
that conversation.
<br>
<br>Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I want is a new container that=E2=80=99s identical to vector, except =
that it can optionally use some storage in the object itself to avoid the a=
llocator in certain situations. That was what I suggested in the first plac=
e.
<br>
<br>But consequences of that are that either
<br>
<br>=C2=A0 =C2=A0 * You need to forbid people from creating small_vector/va=
rarray with zero elements stack-reserved, or
<br>
<br>=C2=A0 =C2=A0 * You need to make vararray<T, 0> and vector<T&g=
t; the same type, which implies a specialisation for vararray<bool, 0>=
;, or<br></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_qu=
ote"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
=C2=A0 =C2=A0 * If you do neither of these, you need to accept that people =
will start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D,=
simply because they can use it generically without worrying about the bool=
case.<br></blockquote><div><br>On the one hand, the conceptual differences=
between `small_vector<T, 0>` and `small_vector<T, <b>1</b>>` a=
re minimal. Which means if you forbid the 0 case, or if you make the 0 case=
an alias of `vector` with its bool specialization intact, people will just=
use `small_vector<T, 1>` to work around it.<br><br>So `small_vector`=
is <i>going to</i> compete with `vector`, no matter what you do.<br><br>Ho=
wever, there are substantive differences between `small_vector<T, 0>`=
and `small_vector<T, 1>` Move behavior/iterator invalidation is a go=
od example. `small_vector<T, 0>` would function in every way exactly =
like `vector`, while `small_vector<T, 1>` would function like a `smal=
l_vector<T, 20>`. Or more to the point, like `string`. No matter how =
small the size is, as long as it isn't zero, you can't guarantee th=
e same move behavior.<br><br>Given these facts, we need to ask ourselves th=
ese questions:<br><br>1) Do we want to create a type that is intended to be=
special case, but will compete with a fundamental library type beyond that=
special case, just because of an idiotic decision made 20+ years ago?<br><=
br>2) If we do want that, do we want to encourage such competition by allow=
ing the new type to completely subsume all uses of the old?<br><br>After al=
l, people are only supposed to use `small_vector` to be an optimization. Bu=
t the moment people brought up the fact that `small_vector` wouldn't ha=
ve a `bool` specialization, I started mentally doing a find/replace for `ve=
ctor` to `small_vector` in my code.<br><br>The correct answer to question 2=
seems, to me, to be "yes". If there's going to be competitio=
n, then the new type <i>ought to win</i>. It does nobody any good to see te=
mplate code using `small_vector<T, 1>` just to avoid the `T =3D bool`=
case for `vector`. So `small_vector<T, 0>` should be in every way eq=
uivalent to `vector`, and it should be interoperable with `vector` (movemen=
t from one to the other). With the exception of `vector<bool>` of cou=
rse; `small_vector` shouldn't have that. If we're going to allow `s=
mall_vector` to compete with `vector` outside of its particular optimizatio=
n domain, then just <i>replace it</i>.<br><br>So the big question is really=
#1: do we want to add a type, originally proposed <i>solely</i> for a narr=
ow case of optimization, that subsumes an existing type which is widely use=
d (not to mention promoted) in lots of C++?<br><br>I don't have an answ=
er to that. My abject hatred for the `vector<bool>` specialization (a=
nd my continued annoyance with the fact that nobody's put forth any eff=
ort to fix it) makes me want to say "Hell yes!" At the same time,=
I despise the idea of replacing a perfectly good class over some idiotic e=
xperimental decision from 20+ years. I also hate the idea of using a type o=
utside of its intended purpose; `small_vector` is <i>supposed</i> to be for=
a narrow optimization.<br><br>Plus, if there's going to be an eventual=
STL2 that includes containers, we don't want to have to create a <i>th=
ird</i> dynamic array type. That's just too confusing.<br><br>To me, th=
e only viable solutions are:<br><br>1) Design `small_vector` so that it com=
pletely takes over `vector` in all situations (except for people who like `=
vector<bool>`.<br><br>2) We don't have `small_vector` at all.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_263_1449359666.1452266322398--
------=_Part_262_1580747714.1452266322398--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 8 Jan 2016 09:48:19 -0600
Raw View
--001a11395ca89161c20528d486b4
Content-Type: text/plain; charset=UTF-8
On 8 January 2016 at 09:18, Nicol Bolas <jmckesson@gmail.com> wrote:
> I don't have an answer to that. My abject hatred for the `vector<bool>`
> specialization (and my continued annoyance with the fact that nobody's put
> forth any effort to fix it)
>
Since the problem with vector<bool> is that it is a good class with a bad
name, the only remotely palatable fix is to come up with a new class that
has a superset of the functionality of vector<bool>, give people some
compelling reason to move to it, then deprecate vector<bool> for a couple
of releases of the standard.
And if we try that, someone is bound to come along and say something like:
*I despise the idea of replacing a perfectly good class. `vector<bool>` is
supposed to be for a narrow optimization.*
*Plus, if there's going to be an eventual STL2 that includes containers, we
don't want to have to create a third dynamic bitset type. That's just too
confusing.*
:-)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11395ca89161c20528d486b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 8 January 2016 at 09:18, Nicol Bolas <span dir=3D"ltr">=
<<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>I don't have an answer to=
that. My abject hatred for the `vector<bool>` specialization (and my=
continued annoyance with the fact that nobody's put forth any effort t=
o fix it) </div></blockquote><div><br></div><div>Since the problem with vec=
tor<bool> is that it is a good class with a bad name, the only remote=
ly palatable fix is to come up with a new class that has a superset of the =
functionality of vector<bool>, give people some compelling reason to =
move to it, then deprecate vector<bool> for a couple of releases of t=
he standard.</div><div><br></div><div>And if we try that, someone is bound =
to come along and say something like:</div><div><i><br></i></div><div><i>I =
despise the idea of replacing a perfectly good class. =C2=A0`vector<bool=
>` is supposed to be for a narrow optimization.</i><br></div><i><br></i>=
<div><i>Plus, if there's going to be an eventual STL2 that includes con=
tainers, we don't want to have to create a third dynamic bitset type. T=
hat's just too confusing.</i></div><div><br></div><div>:-)</div></div>-=
- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"=
><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:=
nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11395ca89161c20528d486b4--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 8 Jan 2016 11:06:43 -0500
Raw View
--001a11401a8001677e0528d4c6fd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:
>>
>>
>> > On 8/01/2016, at 3:41 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > Also, if you're going to start saying "hey, new container paradigm!",
>> then there are going to be a lot of people who want in on that
>> conversation.
>>
>> Personally, I absolutely don=E2=80=99t want a new container *paradigm*. =
What I
>> want is a new container that=E2=80=99s identical to vector, except that =
it can
>> optionally use some storage in the object itself to avoid the allocator =
in
>> certain situations. That was what I suggested in the first place.
>>
>> But consequences of that are that either
>>
>> * You need to forbid people from creating small_vector/vararray with
>> zero elements stack-reserved, or
>>
>> * You need to make vararray<T, 0> and vector<T> the same type, which
>> implies a specialisation for vararray<bool, 0>, or
>>
>
>>
> * If you do neither of these, you need to accept that people will
>> start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D, simply =
because they can
>> use it generically without worrying about the bool case.
>>
>
> On the one hand, the conceptual differences between `small_vector<T, 0>`
> and `small_vector<T, *1*>` are minimal. Which means if you forbid the 0
> case, or if you make the 0 case an alias of `vector` with its bool
> specialization intact, people will just use `small_vector<T, 1>` to work
> around it.
>
> So `small_vector` is *going to* compete with `vector`, no matter what you
> do.
>
> However, there are substantive differences between `small_vector<T, 0>`
> and `small_vector<T, 1>` Move behavior/iterator invalidation is a good
> example. `small_vector<T, 0>` would function in every way exactly like
> `vector`, while `small_vector<T, 1>` would function like a `small_vector<=
T,
> 20>`. Or more to the point, like `string`. No matter how small the size i=
s,
> as long as it isn't zero, you can't guarantee the same move behavior.
>
small_vector<T,0> only behaves like vector<T> if we specify that behaviour.
ie if we specify that iterators are not invalidated, etc.
The typical implementation may allow for that, but I don't think we should
specify it.
ie let's not specialize the specification for the 0 case. Allow
small_vector<T,0>, but don't specify its behaviour (nor T's requirements)
differently that small_vector<T,1>.
Let's design small vector targeting usage like small_vector<T,20>, not to
replace vector. Let small_vector<T,0> fall out naturally, without special
casing it.
>
> Given these facts, we need to ask ourselves these questions:
>
> 1) Do we want to create a type that is intended to be special case, but
> will compete with a fundamental library type beyond that special case, ju=
st
> because of an idiotic decision made 20+ years ago?
>
> 2) If we do want that, do we want to encourage such competition by
> allowing the new type to completely subsume all uses of the old?
>
no.
>
> After all, people are only supposed to use `small_vector` to be an
> optimization. But the moment people brought up the fact that `small_vecto=
r`
> wouldn't have a `bool` specialization, I started mentally doing a
> find/replace for `vector` to `small_vector` in my code.
>
>
Let's fix vector<bool> separately. First, introduce a vector_bool class (or
whatever you want to call it), then deprecate vector<bool> specialization,
then remove the specialization in STL2.
Or remove vector<> altogether, replacing it with clone_ptr<T[]>. I find it
odd that vector<> acts like a value type, but we expose its pointer-based
implementation details (via iterators not invalidating, move semantics,
etc). If we expose its pointer details, maybe its name should reflect that=
..
> The correct answer to question 2 seems, to me, to be "yes". If there's
> going to be competition, then the new type *ought to win*. It does nobody
> any good to see template code using `small_vector<T, 1>` just to avoid th=
e
> `T =3D bool` case for `vector`. So `small_vector<T, 0>` should be in ever=
y
> way equivalent to `vector`, and it should be interoperable with `vector`
> (movement from one to the other). With the exception of `vector<bool>` of
> course; `small_vector` shouldn't have that. If we're going to allow
> `small_vector` to compete with `vector` outside of its particular
> optimization domain, then just *replace it*.
>
>
small_vector<T,1> has different properties than vector<T>. It is _mostly_
the same, but one handles move-only T (or unmovable even) better than the
other, etc.
> So the big question is really #1: do we want to add a type, originally
> proposed *solely* for a narrow case of optimization, that subsumes an
> existing type which is widely used (not to mention promoted) in lots of C=
++?
>
> I don't have an answer to that. My abject hatred for the `vector<bool>`
> specialization (and my continued annoyance with the fact that nobody's pu=
t
> forth any effort to fix it) makes me want to say "Hell yes!" At the same
> time, I despise the idea of replacing a perfectly good class over some
> idiotic experimental decision from 20+ years. I also hate the idea of usi=
ng
> a type outside of its intended purpose; `small_vector` is *supposed* to
> be for a narrow optimization.
>
>
While on the topic, just curious - I understand the idea behind the
vector<bool> "optimization", but what part of the spec _mandates_ the
optimization?
> Plus, if there's going to be an eventual STL2 that includes containers, w=
e
> don't want to have to create a *third* dynamic array type. That's just
> too confusing.
>
> To me, the only viable solutions are:
>
> 1) Design `small_vector` so that it completely takes over `vector` in all
> situations (except for people who like `vector<bool>`.
>
>
2) We don't have `small_vector` at all.
>
>
3) design small_vector to be a sbo_vector. Ignore whether it replaces
vector.
Tony
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a11401a8001677e0528d4c6fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto: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:1px #ccc solid;padding-left:1ex">On Thursday, January =
7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:<span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>> On 8/01/2016, at 3:41 AM, Nicol Bolas <<a rel=3D"nofollow">jmck=
....@gmail.com</a>> wrote:
<br>> Also, if you're going to start saying "hey, new container=
paradigm!", then there are going to be a lot of people who want in on=
that conversation.
<br>
<br>Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I want is a new container that=E2=80=99s identical to vector, except =
that it can optionally use some storage in the object itself to avoid the a=
llocator in certain situations. That was what I suggested in the first plac=
e.
<br>
<br>But consequences of that are that either
<br>
<br>=C2=A0 =C2=A0 * You need to forbid people from creating small_vector/va=
rarray with zero elements stack-reserved, or
<br>
<br>=C2=A0 =C2=A0 * You need to make vararray<T, 0> and vector<T&g=
t; the same type, which implies a specialisation for vararray<bool, 0>=
;, or<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 * If you do neither of these, you need to accept that people =
will start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D,=
simply because they can use it generically without worrying about the bool=
case.<br></blockquote></span><div><br>On the one hand, the conceptual diff=
erences between `small_vector<T, 0>` and `small_vector<T, <b>1</b>=
>` are minimal. Which means if you forbid the 0 case, or if you make the=
0 case an alias of `vector` with its bool specialization intact, people wi=
ll just use `small_vector<T, 1>` to work around it.<br><br>So `small_=
vector` is <i>going to</i> compete with `vector`, no matter what you do.<br=
><br>However, there are substantive differences between `small_vector<T,=
0>` and `small_vector<T, 1>` Move behavior/iterator invalidation =
is a good example. `small_vector<T, 0>` would function in every way e=
xactly like `vector`, while `small_vector<T, 1>` would function like =
a `small_vector<T, 20>`. Or more to the point, like `string`. No matt=
er how small the size is, as long as it isn't zero, you can't guara=
ntee the same move behavior.<br></div></blockquote><div><br></div><div>smal=
l_vector<T,0> only behaves like vector<T> if we specify that be=
haviour.<br>ie if we specify that iterators are not invalidated, etc.<br></=
div><div>The typical implementation may allow for that, but I don't thi=
nk we should specify it.<br></div><div>ie let's not specialize the spec=
ification for the 0 case. Allow small_vector<T,0>, but don't spec=
ify its behaviour (nor T's requirements) differently that small_vector&=
lt;T,1>.<br><br></div><div>Let's design small vector targeting usage=
like small_vector<T,20>, not to replace vector.=C2=A0 Let small_vect=
or<T,0> fall out naturally, without special casing it.<br></div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div><br>Given these facts, =
we need to ask ourselves these questions:<br><br>1) Do we want to create a =
type that is intended to be special case, but will compete with a fundament=
al library type beyond that special case, just because of an idiotic decisi=
on made 20+ years ago?<br><br>2) If we do want that, do we want to encourag=
e such competition by allowing the new type to completely subsume all uses =
of the old?<br></div></blockquote><div><br></div><div>no.<br>=C2=A0<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div><br>After all, people are only suppos=
ed to use `small_vector` to be an optimization. But the moment people broug=
ht up the fact that `small_vector` wouldn't have a `bool` specializatio=
n, I started mentally doing a find/replace for `vector` to `small_vector` i=
n my code.<br><br></div></blockquote><div><br></div><div>Let's fix vect=
or<bool> separately. First, introduce a vector_bool class (or whateve=
r you want to call it), then deprecate vector<bool> specialization, t=
hen remove the specialization in STL2.<br><br></div><div>Or remove vector&l=
t;> altogether, replacing it with clone_ptr<T[]>.=C2=A0 I find it =
odd that vector<> acts like a value type, but we expose its pointer-b=
ased implementation details (via iterators not invalidating, move semantics=
, etc).=C2=A0 If we expose its pointer details, maybe its name should refle=
ct that.<br><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div>The correct answer to question 2 seems, to me, to be "yes". I=
f there's going to be competition, then the new type <i>ought to win</i=
>. It does nobody any good to see template code using `small_vector<T, 1=
>` just to avoid the `T =3D bool` case for `vector`. So `small_vector<=
;T, 0>` should be in every way equivalent to `vector`, and it should be =
interoperable with `vector` (movement from one to the other). With the exce=
ption of `vector<bool>` of course; `small_vector` shouldn't have =
that. If we're going to allow `small_vector` to compete with `vector` o=
utside of its particular optimization domain, then just <i>replace it</i>.<=
br><br></div></blockquote><div><br></div><div>small_vector<T,1> has d=
ifferent properties than vector<T>.=C2=A0 It is _mostly_ the same, bu=
t one handles move-only T (or unmovable even) better than the other, etc.<b=
r>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So the big question i=
s really #1: do we want to add a type, originally proposed <i>solely</i> fo=
r a narrow case of optimization, that subsumes an existing type which is wi=
dely used (not to mention promoted) in lots of C++?<br><br>I don't have=
an answer to that. My abject hatred for the `vector<bool>` specializ=
ation (and my continued annoyance with the fact that nobody's put forth=
any effort to fix it) makes me want to say "Hell yes!" At the sa=
me time, I despise the idea of replacing a perfectly good class over some i=
diotic experimental decision from 20+ years. I also hate the idea of using =
a type outside of its intended purpose; `small_vector` is <i>supposed</i> t=
o be for a narrow optimization.<br><br></div></blockquote><div><br><br></di=
v><div>While on the topic, just curious - I understand the idea behind the =
vector<bool> "optimization", but what part of the spec _man=
dates_ the optimization?<br><br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div>Plus, if there's going to be an eventual STL2 that incl=
udes containers, we don't want to have to create a <i>third</i> dynamic=
array type. That's just too confusing.<br><br>To me, the only viable s=
olutions are:<br><br>1) Design `small_vector` so that it completely takes o=
ver `vector` in all situations (except for people who like `vector<bool&=
gt;`.<br>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>2) =
We don't have `small_vector` at all.<br></div><div class=3D"HOEnZb"><di=
v class=3D"h5">
<p></p>
</div></div></blockquote><div><br></div><div>3) design small_vector to be a=
sbo_vector.=C2=A0 Ignore whether it replaces vector.<br><br></div><div>Ton=
y<br><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11401a8001677e0528d4c6fd--
.
Author: Alisdair Meredith <alisdairm@icloud.com>
Date: Fri, 08 Jan 2016 13:37:00 -0500
Raw View
--Apple-Mail-029ABC5E-A32F-4417-84D0-FC1518AB0AE3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The vector<bool> optimization is permitted, but not mandated. However, the=
interface, complete with a specific proxy type, IS mandated, and that is s=
ufficient to cause problems, regardless of defining a meaning for 'data()'.
Sent from my iPhone
> On Jan 8, 2016, at 11:06 AM, Tony V E <tvaneerd@gmail.com> wrote:
>=20
>=20
>=20
>> On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>>> On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote=
:
>>>=20
>>> > On 8/01/2016, at 3:41 AM, Nicol Bolas <jmck...@gmail.com> wrote:=20
>>> > Also, if you're going to start saying "hey, new container paradigm!",=
then there are going to be a lot of people who want in on that conversatio=
n.=20
>>>=20
>>> Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I want is a new container that=E2=80=99s identical to vector, except =
that it can optionally use some storage in the object itself to avoid the a=
llocator in certain situations. That was what I suggested in the first plac=
e.=20
>>>=20
>>> But consequences of that are that either=20
>>>=20
>>> * You need to forbid people from creating small_vector/vararray wit=
h zero elements stack-reserved, or=20
>>>=20
>>> * You need to make vararray<T, 0> and vector<T> the same type, whic=
h implies a specialisation for vararray<bool, 0>, or
>>> =20
>>> * If you do neither of these, you need to accept that people will s=
tart using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D, simply beca=
use they can use it generically without worrying about the bool case.
>>=20
>>=20
>> On the one hand, the conceptual differences between `small_vector<T, 0>`=
and `small_vector<T, 1>` are minimal. Which means if you forbid the 0 case=
, or if you make the 0 case an alias of `vector` with its bool specializati=
on intact, people will just use `small_vector<T, 1>` to work around it.
>>=20
>> So `small_vector` is going to compete with `vector`, no matter what you =
do.
>>=20
>> However, there are substantive differences between `small_vector<T, 0>` =
and `small_vector<T, 1>` Move behavior/iterator invalidation is a good exam=
ple. `small_vector<T, 0>` would function in every way exactly like `vector`=
, while `small_vector<T, 1>` would function like a `small_vector<T, 20>`. O=
r more to the point, like `string`. No matter how small the size is, as lon=
g as it isn't zero, you can't guarantee the same move behavior.
>=20
> small_vector<T,0> only behaves like vector<T> if we specify that behaviou=
r.
> ie if we specify that iterators are not invalidated, etc.
> The typical implementation may allow for that, but I don't think we shoul=
d specify it.
> ie let's not specialize the specification for the 0 case. Allow small_vec=
tor<T,0>, but don't specify its behaviour (nor T's requirements) differentl=
y that small_vector<T,1>.
>=20
> Let's design small vector targeting usage like small_vector<T,20>, not to=
replace vector. Let small_vector<T,0> fall out naturally, without special=
casing it.
> =20
>>=20
>> Given these facts, we need to ask ourselves these questions:
>>=20
>> 1) Do we want to create a type that is intended to be special case, but =
will compete with a fundamental library type beyond that special case, just=
because of an idiotic decision made 20+ years ago?
>>=20
>> 2) If we do want that, do we want to encourage such competition by allow=
ing the new type to completely subsume all uses of the old?
>=20
> no.
> =20
>>=20
>> After all, people are only supposed to use `small_vector` to be an optim=
ization. But the moment people brought up the fact that `small_vector` woul=
dn't have a `bool` specialization, I started mentally doing a find/replace =
for `vector` to `small_vector` in my code.
>=20
> Let's fix vector<bool> separately. First, introduce a vector_bool class (=
or whatever you want to call it), then deprecate vector<bool> specializatio=
n, then remove the specialization in STL2.
>=20
> Or remove vector<> altogether, replacing it with clone_ptr<T[]>. I find =
it odd that vector<> acts like a value type, but we expose its pointer-base=
d implementation details (via iterators not invalidating, move semantics, e=
tc). If we expose its pointer details, maybe its name should reflect that.
>=20
> =20
>> The correct answer to question 2 seems, to me, to be "yes". If there's g=
oing to be competition, then the new type ought to win. It does nobody any =
good to see template code using `small_vector<T, 1>` just to avoid the `T =
=3D bool` case for `vector`. So `small_vector<T, 0>` should be in every way=
equivalent to `vector`, and it should be interoperable with `vector` (move=
ment from one to the other). With the exception of `vector<bool>` of course=
; `small_vector` shouldn't have that. If we're going to allow `small_vector=
` to compete with `vector` outside of its particular optimization domain, t=
hen just replace it.
>=20
> small_vector<T,1> has different properties than vector<T>. It is _mostly=
_ the same, but one handles move-only T (or unmovable even) better than the=
other, etc.
> =20
>> So the big question is really #1: do we want to add a type, originally p=
roposed solely for a narrow case of optimization, that subsumes an existing=
type which is widely used (not to mention promoted) in lots of C++?
>>=20
>> I don't have an answer to that. My abject hatred for the `vector<bool>` =
specialization (and my continued annoyance with the fact that nobody's put =
forth any effort to fix it) makes me want to say "Hell yes!" At the same ti=
me, I despise the idea of replacing a perfectly good class over some idioti=
c experimental decision from 20+ years. I also hate the idea of using a typ=
e outside of its intended purpose; `small_vector` is supposed to be for a n=
arrow optimization.
>=20
>=20
> While on the topic, just curious - I understand the idea behind the vecto=
r<bool> "optimization", but what part of the spec _mandates_ the optimizati=
on?
>=20
> =20
>> Plus, if there's going to be an eventual STL2 that includes containers, =
we don't want to have to create a third dynamic array type. That's just too=
confusing.
>>=20
>> To me, the only viable solutions are:
>>=20
>> 1) Design `small_vector` so that it completely takes over `vector` in al=
l situations (except for people who like `vector<bool>`.
>> =20
>> 2) We don't have `small_vector` at all.
>=20
> 3) design small_vector to be a sbo_vector. Ignore whether it replaces ve=
ctor.
>=20
> Tony
>=20
> --=20
>=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=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail-029ABC5E-A32F-4417-84D0-FC1518AB0AE3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>The vector<bool> optimizatio=
n is permitted, but not mandated. However, the interface, complete wi=
th a specific proxy type, IS mandated, and that is sufficient to cause prob=
lems, regardless of defining a meaning for 'data()'.<br><br>Sent from my iP=
hone</div><div><br>On Jan 8, 2016, at 11:06 AM, Tony V E <<a href=3D"mai=
lto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wrote:<br><br></div><blo=
ckquote type=3D"cite"><div><div dir=3D"ltr"><br><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas=
<span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_bl=
ank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wro=
te:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>> On 8/01/2016, at 3:41 AM, Nicol Bolas <<a rel=3D"nofollow">jmck=
....@gmail.com</a>> wrote:
<br>> Also, if you're going to start saying "hey, new container paradigm=
!", then there are going to be a lot of people who want in on that conversa=
tion.
<br>
<br>Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I want is a new container that=E2=80=99s identical to vector, except =
that it can optionally use some storage in the object itself to avoid the a=
llocator in certain situations. That was what I suggested in the first plac=
e.
<br>
<br>But consequences of that are that either
<br>
<br> * You need to forbid people from creating small_vector/va=
rarray with zero elements stack-reserved, or
<br>
<br> * You need to make vararray<T, 0> and vector<T&g=
t; the same type, which implies a specialisation for vararray<bool, 0>=
;, or<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v> </div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you do neither of these, you need to accept that people =
will start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D,=
simply because they can use it generically without worrying about the bool=
case.<br></blockquote></span><div><br>On the one hand, the conceptual diff=
erences between `small_vector<T, 0>` and `small_vector<T, <b>1</b>=
>` are minimal. Which means if you forbid the 0 case, or if you make the=
0 case an alias of `vector` with its bool specialization intact, people wi=
ll just use `small_vector<T, 1>` to work around it.<br><br>So `small_=
vector` is <i>going to</i> compete with `vector`, no matter what you do.<br=
><br>However, there are substantive differences between `small_vector<T,=
0>` and `small_vector<T, 1>` Move behavior/iterator invalidation =
is a good example. `small_vector<T, 0>` would function in every way e=
xactly like `vector`, while `small_vector<T, 1>` would function like =
a `small_vector<T, 20>`. Or more to the point, like `string`. No matt=
er how small the size is, as long as it isn't zero, you can't guarantee the=
same move behavior.<br></div></blockquote><div><br></div><div>small_vector=
<T,0> only behaves like vector<T> if we specify that behaviour.=
<br>ie if we specify that iterators are not invalidated, etc.<br></div><div=
>The typical implementation may allow for that, but I don't think we should=
specify it.<br></div><div>ie let's not specialize the specification for th=
e 0 case. Allow small_vector<T,0>, but don't specify its behaviour (n=
or T's requirements) differently that small_vector<T,1>.<br><br></div=
><div>Let's design small vector targeting usage like small_vector<T,20&g=
t;, not to replace vector. Let small_vector<T,0> fall out natur=
ally, without special casing it.<br></div><div> <br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div><br>Given these facts, we need to ask ourselves the=
se questions:<br><br>1) Do we want to create a type that is intended to be =
special case, but will compete with a fundamental library type beyond that =
special case, just because of an idiotic decision made 20+ years ago?<br><b=
r>2) If we do want that, do we want to encourage such competition by allowi=
ng the new type to completely subsume all uses of the old?<br></div></block=
quote><div><br></div><div>no.<br> <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div><br>After all, people are only supposed to use `small_vector` to =
be an optimization. But the moment people brought up the fact that `small_v=
ector` wouldn't have a `bool` specialization, I started mentally doing a fi=
nd/replace for `vector` to `small_vector` in my code.<br><br></div></blockq=
uote><div><br></div><div>Let's fix vector<bool> separately. First, in=
troduce a vector_bool class (or whatever you want to call it), then depreca=
te vector<bool> specialization, then remove the specialization in STL=
2.<br><br></div><div>Or remove vector<> altogether, replacing it with=
clone_ptr<T[]>. I find it odd that vector<> acts like a =
value type, but we expose its pointer-based implementation details (via ite=
rators not invalidating, move semantics, etc). If we expose its point=
er details, maybe its name should reflect that.<br><br></div><div> <br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div>The correct answer to question 2=
seems, to me, to be "yes". If there's going to be competition, then the ne=
w type <i>ought to win</i>. It does nobody any good to see template code us=
ing `small_vector<T, 1>` just to avoid the `T =3D bool` case for `vec=
tor`. So `small_vector<T, 0>` should be in every way equivalent to `v=
ector`, and it should be interoperable with `vector` (movement from one to =
the other). With the exception of `vector<bool>` of course; `small_ve=
ctor` shouldn't have that. If we're going to allow `small_vector` to compet=
e with `vector` outside of its particular optimization domain, then just <i=
>replace it</i>.<br><br></div></blockquote><div><br></div><div>small_vector=
<T,1> has different properties than vector<T>. It is _mos=
tly_ the same, but one handles move-only T (or unmovable even) better than =
the other, etc.<br> <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So =
the big question is really #1: do we want to add a type, originally propose=
d <i>solely</i> for a narrow case of optimization, that subsumes an existin=
g type which is widely used (not to mention promoted) in lots of C++?<br><b=
r>I don't have an answer to that. My abject hatred for the `vector<bool&=
gt;` specialization (and my continued annoyance with the fact that nobody's=
put forth any effort to fix it) makes me want to say "Hell yes!" At the sa=
me time, I despise the idea of replacing a perfectly good class over some i=
diotic experimental decision from 20+ years. I also hate the idea of using =
a type outside of its intended purpose; `small_vector` is <i>supposed</i> t=
o be for a narrow optimization.<br><br></div></blockquote><div><br><br></di=
v><div>While on the topic, just curious - I understand the idea behind the =
vector<bool> "optimization", but what part of the spec _mandates_ the=
optimization?<br><br></div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>Plus, if there's going to be an eventual STL2 that includes container=
s, we don't want to have to create a <i>third</i> dynamic array type. That'=
s just too confusing.<br><br>To me, the only viable solutions are:<br><br>1=
) Design `small_vector` so that it completely takes over `vector` in all si=
tuations (except for people who like `vector<bool>`.<br> </div><=
/blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>2) We don't have `small_vec=
tor` at all.<br></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
</div></div></blockquote><div><br></div><div>3) design small_vector to be a=
sbo_vector. Ignore whether it replaces vector.<br><br></div><div>Ton=
y<br><br></div></div></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 e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
</div></blockquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail-029ABC5E-A32F-4417-84D0-FC1518AB0AE3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jan 2016 14:32:05 -0800 (PST)
Raw View
------=_Part_616_1769334006.1452292325676
Content-Type: multipart/alternative;
boundary="----=_Part_617_1971200574.1452292325682"
------=_Part_617_1971200574.1452292325682
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:
>
> On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Thursday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:
>>>
>>>
>>> > On 8/01/2016, at 3:41 AM, Nicol Bolas <jmck...@gmail.com> wrote:=20
>>> > Also, if you're going to start saying "hey, new container paradigm!",=
=20
>>> then there are going to be a lot of people who want in on that=20
>>> conversation.=20
>>>
>>> Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I=20
>>> want is a new container that=E2=80=99s identical to vector, except that=
it can=20
>>> optionally use some storage in the object itself to avoid the allocator=
in=20
>>> certain situations. That was what I suggested in the first place.=20
>>>
>>> But consequences of that are that either=20
>>>
>>> * You need to forbid people from creating small_vector/vararray wit=
h=20
>>> zero elements stack-reserved, or=20
>>>
>>> * You need to make vararray<T, 0> and vector<T> the same type, whic=
h=20
>>> implies a specialisation for vararray<bool, 0>, or
>>>
>> =20
>>>
>> * If you do neither of these, you need to accept that people will=20
>>> start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D, simply=
because they can=20
>>> use it generically without worrying about the bool case.
>>>
>>
>> On the one hand, the conceptual differences between `small_vector<T, 0>`=
=20
>> and `small_vector<T, *1*>` are minimal. Which means if you forbid the 0=
=20
>> case, or if you make the 0 case an alias of `vector` with its bool=20
>> specialization intact, people will just use `small_vector<T, 1>` to work=
=20
>> around it.
>>
>> So `small_vector` is *going to* compete with `vector`, no matter what=20
>> you do.
>>
>> However, there are substantive differences between `small_vector<T, 0>`=
=20
>> and `small_vector<T, 1>` Move behavior/iterator invalidation is a good=
=20
>> example. `small_vector<T, 0>` would function in every way exactly like=
=20
>> `vector`, while `small_vector<T, 1>` would function like a `small_vector=
<T,=20
>> 20>`. Or more to the point, like `string`. No matter how small the size =
is,=20
>> as long as it isn't zero, you can't guarantee the same move behavior.
>>
>
> small_vector<T,0> only behaves like vector<T> if we specify that behaviou=
r.
> ie if we specify that iterators are not invalidated, etc.
> The typical implementation may allow for that, but I don't think we shoul=
d=20
> specify it.=20
>
ie let's not specialize the specification for the 0 case. Allow=20
> small_vector<T,0>, but don't specify its behaviour (nor T's requirements)=
=20
> differently that small_vector<T,1>.
>
So what you're saying is that, if I have a `small_vector<T, 4>` which=20
contains 12 elements, and I move it to another `small_vector<T, 4>`, you're=
=20
telling me that the specification of `small_vector` *should not* allow me=
=20
to keep the iterators?
`string` doesn't let iterators work because the number of characters in the=
=20
small buffer is implementation defined and not user-accessible. And of=20
course because SSO is not required, so the user has no way to develop code=
=20
where they know it will work. But with `small_vector`:
small_vector<int, 4> v(12, 2220);
small_vector<int, 4> v2(std::move(v));
We know that `v` allocated memory for (at least) 12 values. We know that=20
`v2` received the memory from `v` directly; it didn't copy into its own=20
buffer. And so forth.
There is no reason that iterators should be invalidated with this=20
operation. Similarly:
void func(small_vector<int, 4> &&v)
{
if(v.size() > v.buffer_size())
v.reserve(v.buffer_size() * 1.5);
small_vector<int, 4> v2(std::move(v));
}
This would not be the first instance of such a runtime-defined invalidation=
=20
system. After all, `vector` permits you to retain iterators on insertion,=
=20
so long as you insert at the end and so long as your insertions didn't blow=
=20
the capacity. This `small_vector` movement is the same thing: iterators=20
work, conditioned on certain runtime-defined facts.
This requirement would not place an undue burden on implementations, since=
=20
it's exactly what they have to do now with `vector`. It wouldn't require=20
them to do anything special to support it. It would just work.
Of course, once you permit this, `small_vector<T, 0>` starts behaving=20
almost exactly like `vector<T>`. So by simply doing the right thing for=20
`small_vector<T, N>` we're suddenly rewriting `vector<T>`.
Oops...
Let's design small vector targeting usage like small_vector<T,20>, not to=
=20
> replace vector. Let small_vector<T,0> fall out naturally, without specia=
l=20
> casing it.
>
And if the most "natural" design for `small_vector<T, 0>` turns it into=20
`vector<T>` without the bool specialization?
=20
> The correct answer to question 2 seems, to me, to be "yes". If there's=20
>> going to be competition, then the new type *ought to win*. It does=20
>> nobody any good to see template code using `small_vector<T, 1>` just to=
=20
>> avoid the `T =3D bool` case for `vector`. So `small_vector<T, 0>` should=
be=20
>> in every way equivalent to `vector`, and it should be interoperable with=
=20
>> `vector` (movement from one to the other). With the exception of=20
>> `vector<bool>` of course; `small_vector` shouldn't have that. If we're=
=20
>> going to allow `small_vector` to compete with `vector` outside of its=20
>> particular optimization domain, then just *replace it*.
>>
>>
> small_vector<T,1> has different properties than vector<T>. It is _mostly=
_=20
> the same, but one handles move-only T (or unmovable even) better than the=
=20
> other, etc.
>
std::deque<T> has far more different properties from vector<T>, but I've=20
seen C++ books that recommend using it when `T` might need to be bool. Why=
=20
would such books not simply switch their suggestion to=20
`std::small_vector<T, 0>`? And after a while, I could see them simply=20
switching their recommendation to use `small_vector<T, 0>`, with `vector`=
=20
being for specialized cases (maybe even just `vector<bool>`.
Plus, if there's going to be an eventual STL2 that includes containers, we=
=20
>> don't want to have to create a *third* dynamic array type. That's just=
=20
>> too confusing.
>>
>> To me, the only viable solutions are:
>>
>> 1) Design `small_vector` so that it completely takes over `vector` in al=
l=20
>> situations (except for people who like `vector<bool>`.
>> =20
>>
> 2) We don't have `small_vector` at all.
>>
>>
> 3) design small_vector to be a sbo_vector. Ignore whether it replaces=20
> vector.
>
So it is OK if it complete takes over `vector` by accident?
I don't believe that the effects of `small_vector` on `vector` should be=20
ignored or glossed over. If for no other reason than that I doubt the=20
standards committee will ignore it. I think they're going to notice when=20
you've added a type that's identical to something they already have that's=
=20
widely used.
At the very least, any proposal for small_vector it needs to *acknowledge*=
=20
the replacement issue.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_617_1971200574.1452292325682
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote">On Fri, Jan 8, 2016 at 10:18 AM, Nicol Bolas <span dir=3D"ltr"><=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qIOtPS1R=
FAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck.=
...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu=
rsday, January 7, 2016 at 9:27:30 PM UTC-5, Tristan Brindle wrote:<span><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<br>> On 8/01/2016, at 3:41 AM, Nicol Bolas <<a rel=3D"nofollow">jmck=
....@gmail.com</a>> wrote:
<br>> Also, if you're going to start saying "hey, new container=
paradigm!", then there are going to be a lot of people who want in on=
that conversation.
<br>
<br>Personally, I absolutely don=E2=80=99t want a new container *paradigm*.=
What I want is a new container that=E2=80=99s identical to vector, except =
that it can optionally use some storage in the object itself to avoid the a=
llocator in certain situations. That was what I suggested in the first plac=
e.
<br>
<br>But consequences of that are that either
<br>
<br>=C2=A0 =C2=A0 * You need to forbid people from creating small_vector/va=
rarray with zero elements stack-reserved, or
<br>
<br>=C2=A0 =C2=A0 * You need to make vararray<T, 0> and vector<T&g=
t; the same type, which implies a specialisation for vararray<bool, 0>=
;, or<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 * If you do neither of these, you need to accept that people =
will start using vararray<T, 0> as a =E2=80=9Cbetter vector=E2=80=9D,=
simply because they can use it generically without worrying about the bool=
case.<br></blockquote></span><div><br>On the one hand, the conceptual diff=
erences between `small_vector<T, 0>` and `small_vector<T, <b>1</b>=
>` are minimal. Which means if you forbid the 0 case, or if you make the=
0 case an alias of `vector` with its bool specialization intact, people wi=
ll just use `small_vector<T, 1>` to work around it.<br><br>So `small_=
vector` is <i>going to</i> compete with `vector`, no matter what you do.<br=
><br>However, there are substantive differences between `small_vector<T,=
0>` and `small_vector<T, 1>` Move behavior/iterator invalidation =
is a good example. `small_vector<T, 0>` would function in every way e=
xactly like `vector`, while `small_vector<T, 1>` would function like =
a `small_vector<T, 20>`. Or more to the point, like `string`. No matt=
er how small the size is, as long as it isn't zero, you can't guara=
ntee the same move behavior.<br></div></blockquote><div><br></div><div>smal=
l_vector<T,0> only behaves like vector<T> if we specify that be=
haviour.<br>ie if we specify that iterators are not invalidated, etc.<br></=
div><div>The typical implementation may allow for that, but I don't thi=
nk we should specify it.=C2=A0</div></div></div></div></blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><div></div><div>ie let's not specialize the specification fo=
r the 0 case. Allow small_vector<T,0>, but don't specify its beha=
viour (nor T's requirements) differently that small_vector<T,1>.<=
br></div></div></div></div></blockquote><div><br>So what you're saying =
is that, if I have a `small_vector<T, 4>` which contains 12 elements,=
and I move it to another `small_vector<T, 4>`, you're telling me=
that the specification of `small_vector` <i>should not</i> allow me to kee=
p the iterators?<br><br>`string` doesn't let iterators work because the=
number of characters in the small buffer is implementation defined and not=
user-accessible. And of course because SSO is not required, so the user ha=
s no way to develop code where they know it will work. But with `small_vect=
or`:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
small_vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">12</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">2220</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>small_vector</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> v2</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">move</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">));</span></div></code></div><br>We know that=
`v` allocated memory for (at least) 12 values. We know that `v2` received =
the memory from `v` directly; it didn't copy into its own buffer. And s=
o forth.<br><br>There is no reason that iterators should be invalidated wit=
h this operation. Similarly:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">small_vector</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&&</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</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"styled-by-prett=
ify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">buffer_size<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">reserve</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">buffer_size</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-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.5=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 sma=
ll_vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><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: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> v2</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mov=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>This would not =
be the first instance of such a runtime-defined invalidation system. After =
all, `vector` permits you to retain iterators on insertion, so long as you =
insert at the end and so long as your insertions didn't blow the capaci=
ty. This `small_vector` movement is the same thing: iterators work, conditi=
oned on certain runtime-defined facts.<br><br>This requirement would not pl=
ace an undue burden on implementations, since it's exactly what they ha=
ve to do now with `vector`. It wouldn't require them to do anything spe=
cial to support it. It would just work.<br><br>Of course, once you permit t=
his, `small_vector<T, 0>` starts behaving almost exactly like `vector=
<T>`. So by simply doing the right thing for `small_vector<T, N>=
;` we're suddenly rewriting `vector<T>`.<br><br>Oops...<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 dir=3D"ltr"><div><div=
><div>Let's design small vector targeting usage like small_vector<T,=
20>, not to replace vector.=C2=A0 Let small_vector<T,0> fall out n=
aturally, without special casing it.<br></div></div></div></div></blockquot=
e><div><br>And if the most "natural" design for `small_vector<=
T, 0>` turns it into `vector<T>` without the bool specialization?<=
br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div><div></div></div></div></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>The correct answer to question=
2 seems, to me, to be "yes". If there's going to be competit=
ion, then the new type <i>ought to win</i>. It does nobody any good to see =
template code using `small_vector<T, 1>` just to avoid the `T =3D boo=
l` case for `vector`. So `small_vector<T, 0>` should be in every way =
equivalent to `vector`, and it should be interoperable with `vector` (movem=
ent from one to the other). With the exception of `vector<bool>` of c=
ourse; `small_vector` shouldn't have that. If we're going to allow =
`small_vector` to compete with `vector` outside of its particular optimizat=
ion domain, then just <i>replace it</i>.<br><br></div></blockquote><div><br=
></div><div>small_vector<T,1> has different properties than vector<=
;T>.=C2=A0 It is _mostly_ the same, but one handles move-only T (or unmo=
vable even) better than the other, etc.<br></div></div></div></div></blockq=
uote><div><br>std::deque<T> has far more different properties from ve=
ctor<T>, but I've seen C++ books that recommend using it when `T`=
might need to be bool. Why would such books not simply switch their sugges=
tion to=20
`std::small_vector<T, 0>`? And after a while, I could see them simply=
switching their recommendation to use `small_vector<T, 0>`, with `ve=
ctor` being for specialized cases (maybe even just `vector<bool>`.<br=
><br></div><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><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"><di=
v>Plus, if there's going to be an eventual STL2 that includes container=
s, we don't want to have to create a <i>third</i> dynamic array type. T=
hat's just too confusing.<br><br>To me, the only viable solutions are:<=
br><br>1) Design `small_vector` so that it completely takes over `vector` i=
n all situations (except for people who like `vector<bool>`.<br>=C2=
=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>2) We don't h=
ave `small_vector` at all.<br></div><div><div>
<p></p>
</div></div></blockquote><div><br></div><div>3) design small_vector to be a=
sbo_vector.=C2=A0 Ignore whether it replaces vector.<br></div></div></div>=
</div></blockquote><div><br>So it is OK if it complete takes over `vector` =
by accident?<br><br>I don't believe that the effects of `small_vector` =
on `vector` should be ignored or glossed over. If for no other reason than =
that I doubt the standards committee will ignore it. I think they're go=
ing to notice when you've added a type that's identical to somethin=
g they already have that's widely used.<br><br>At the very least, any p=
roposal for small_vector it needs to <i>acknowledge</i> the replacement iss=
ue.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_617_1971200574.1452292325682--
------=_Part_616_1769334006.1452292325676--
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Sat, 9 Jan 2016 04:12:57 -0600
Raw View
--001a11409fc20e8bf30528e3f537
Content-Type: text/plain; charset=UTF-8
On 8 January 2016 at 16:32, Nicol Bolas <jmckesson@gmail.com> wrote:
> So it is OK if it complete takes over `vector` by accident?
>
Sure. If a better type wins, so be it.
First you complain that the committee never fixes the vector<bool> wart.
This will fix that wart. All we have to do afterwards is deprecate
std::vector except for the bool specialization. (Some might say that was my
secret plan all along :-))
For some reason, you no longer want it fixed. You would rather wait
decades (C++95?) for the mythical STL2 beast (after all, you told us we
shouldn't even start on it until there has been much user experience with
concepts and ranges, and I'm sure by that time we'll find another excuse
why we should endlessly delay it), which will, of course, *have exactly the
same problem of competing types*. Your great-great-great grandchildren
will probably bring up the same objection.
There just isn't pleasing some people...
:-)
Tongue and cheek aside, boost::container::small_vector allows 0. I suspect
(but haven't looked) that the other existing ones do also. The whole point
of standardizing this is because people keep inventing this type; if the
committee goes and creates a type that is less useful than the ones in
existing practice, we will have failed and wasted both committee time and
implementor time.
I consider not allowing 0 to be as bad a wart as specializing vector for
bool. I also consider under specifying things like iterator invalidation
to be ridiculous, as people are going to discover and use it anyway. For
instance, people discovered and used the fact that vectors had contiguous
data long before the standard mandated it (IIRC C++98 did not while C++03
did). And you already have my negative opinion on combining vector and
small_vector.
--
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
+1-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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11409fc20e8bf30528e3f537
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 8 January 2016 at 16:32, Nic=
ol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targe=
t=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div>So it is OK if it complete takes over `vect=
or` by accident?<br></div></blockquote></div><br>Sure.=C2=A0 If a better ty=
pe wins, so be it.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><br></div><div class=3D"gmail_extra">First you complain that t=
he committee never fixes the vector<bool> wart.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">This will fix that wart.=C2=
=A0 All we have to do afterwards is deprecate std::vector except for the bo=
ol specialization. (Some might say that was my secret plan all along :-))</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">For som=
e reason, you no longer want it fixed.=C2=A0 You would rather wait decades =
(C++95?) for the mythical STL2 beast (after all, you told us we shouldn'=
;t even start on it until there has been much user experience with concepts=
and ranges, and I'm sure by that time we'll find another excuse wh=
y we should endlessly delay it), which will, of course, <i>have exactly the=
same problem of competing types</i>.=C2=A0 Your great-great-great grandchi=
ldren will probably bring up the same objection.</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">There just isn't pleasing so=
me people...</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">:-)</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">Tongue and cheek aside, boost::co=
ntainer::small_vector allows 0.=C2=A0 I suspect (but haven't looked) th=
at the other existing ones do also.=C2=A0 The whole point of standardizing =
this is because people keep inventing this type; if the committee goes and =
creates a type that is less useful than the ones in existing practice, we w=
ill have failed and wasted both committee time and implementor time.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I consider n=
ot allowing 0 to be as bad a wart as specializing vector for bool.=C2=A0 I =
also consider under specifying things like iterator invalidation to be ridi=
culous, as people are going to discover and use it anyway.=C2=A0 For instan=
ce, people discovered and used the fact that vectors had contiguous data lo=
ng before the standard mandated it (IIRC C++98 did not while C++03 did).=C2=
=A0 And you already have my negative opinion on combining vector and small_=
vector.<br>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr">=C2=A0Nev=
in ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank">nevin@cplusplusguy.com</a>>=C2=A0 +1-847-691-=
1404<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11409fc20e8bf30528e3f537--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 9 Jan 2016 06:48:06 -0800 (PST)
Raw View
------=_Part_792_1011435154.1452350887073
Content-Type: multipart/alternative;
boundary="----=_Part_793_1934924904.1452350887084"
------=_Part_793_1934924904.1452350887084
Content-Type: text/plain; charset=UTF-8
On Saturday, January 9, 2016 at 5:13:40 AM UTC-5, Nevin Liber wrote:
>
> On 8 January 2016 at 16:32, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> So it is OK if it complete takes over `vector` by accident?
>>
>
> Sure. If a better type wins, so be it.
>
>
> First you complain that the committee never fixes the vector<bool> wart.
>
> This will fix that wart. All we have to do afterwards is deprecate
> std::vector except for the bool specialization. (Some might say that was my
> secret plan all along :-))
>
> For some reason, you no longer want it fixed.
>
I didn't say that. I'm saying that, if `small_vector` progresses forward as
it is, it will replace `vector`. And that fact needs to be recognized and
discussed for its implications.
Not to mention, as others have suggested, if `small_vector` is going to
completely replace `vector`, if `small_vector`, is really just vector
2.0... maybe it should have a more appropriate name. I hate to get all
bikesheddy here, but that's not an unreasonable point to make. So again,
the issue of `vector` replacement is important.
Tongue and cheek aside, boost::container::small_vector allows 0. I suspect
> (but haven't looked) that the other existing ones do also. The whole point
> of standardizing this is because people keep inventing this type; if the
> committee goes and creates a type that is less useful than the ones in
> existing practice, we will have failed and wasted both committee time and
> implementor time.
>
Actually, that brings up an interesting point. Boost's documentation for
small_vector is decidedly lacking. As in... there isn't any
<http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html>.
So it's not clear whether `boost::small_vector` invalidates iterators on
movement or not.
Granted, that doesn't mean that we ought to always invalidate iterators,
for previously covered reasons. But it's hard to use existing practice as a
justification when existing practice is not well-specified.
I consider not allowing 0 to be as bad a wart as specializing vector for
> bool.
>
There's no workaround for `vector<bool>`. If you need an actual contiguous,
growing array of actual `bool` types, you're SOL unless you write your own.
Whereas `small_vector<T, 1>` is almost as good as `small_vector<T, 0>`.
Now, I'm not saying we *should* disallow 0; that' would be silly and
accomplish nothing, if for no other reason than the ease of the
aforementioned workaround.
My point is simply that a problem which can be worked around is never as
bad as a problem which *cannot*.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_793_1934924904.1452350887084
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 9, 2016 at 5:13:40 AM UTC-5, Nevin Liber wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>On 8 January 20=
16 at 16:32, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"XtZTBn2MFAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">jmck...@gmail.com</a>></span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div>So it is OK if i=
t complete takes over `vector` by accident?<br></div></blockquote></div><br=
>Sure.=C2=A0 If a better type wins, so be it.</div><div><br></div><div><br>=
</div><div>First you complain that the committee never fixes the vector<=
bool> wart.</div><div><br></div><div>This will fix that wart.=C2=A0 All =
we have to do afterwards is deprecate std::vector except for the bool speci=
alization. (Some might say that was my secret plan all along :-))</div><div=
><br></div><div>For some reason, you no longer want it fixed.</div></div></=
blockquote><div><br>I didn't say that. I'm saying that, if `small_v=
ector` progresses forward as it is, it will replace `vector`. And that fact=
needs to be recognized and discussed for its implications.<br><br>Not to m=
ention, as others have suggested, if `small_vector` is going to completely =
replace `vector`, if `small_vector`, is really just vector 2.0... maybe it =
should have a more appropriate name. I hate to get all bikesheddy here, but=
that's not an unreasonable point to make. So again, the issue of `vect=
or` replacement is important.<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 dir=3D"ltr"><div></div><div>Tongue and cheek aside, boost=
::container::small_vector allows 0.=C2=A0 I suspect (but haven't looked=
) that the other existing ones do also.=C2=A0 The whole point of standardiz=
ing this is because people keep inventing this type; if the committee goes =
and creates a type that is less useful than the ones in existing practice, =
we will have failed and wasted both committee time and implementor time.</d=
iv></div></blockquote><div><br>Actually, that brings up an interesting poin=
t. Boost's documentation for small_vector is decidedly lacking. As in..=
.. <a href=3D"http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/=
small_vector.html">there isn't any</a>. So it's not clear whether `=
boost::small_vector` invalidates iterators on movement or not.<br><br>Grant=
ed, that doesn't mean that we ought to always invalidate iterators, for=
previously covered reasons. But it's hard to use existing practice as =
a justification when existing practice is not well-specified.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><d=
iv>I consider not allowing 0 to be as bad a wart as specializing vector for=
bool.</div></div></blockquote><div><br>There's no workaround for `vect=
or<bool>`. If you need an actual contiguous, growing array of actual =
`bool` types, you're SOL unless you write your own.<br><br>Whereas `sma=
ll_vector<T, 1>` is almost as good as `small_vector<T, 0>`. Now=
, I'm not saying we <i>should</i> disallow 0; that' would be silly =
and accomplish nothing, if for no other reason than the ease of the aforeme=
ntioned workaround.<br><br>My point is simply that a problem which can be w=
orked around is never as bad as a problem which <i>cannot</i>.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_793_1934924904.1452350887084--
------=_Part_792_1011435154.1452350887073--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Sat, 9 Jan 2016 14:49:22 +0000
Raw View
On 8 January 2016 at 22:32, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:
>
> So what you're saying is that, if I have a `small_vector<T, 4>` which
> contains 12 elements, and I move it to another `small_vector<T, 4>`, you're
> telling me that the specification of `small_vector` should not allow me to
> keep the iterators?
>
Here is one reason to forbid keeping the iterators.
In my implementation of small_vector, sizeof(small_vector<char, 3>) ==
sizeof(small_vector<char, 8>), because of padding. Giving the space is
already used, small_vector<char, 3> stores 8 elements before it
allocates from the heap.
Of course, I could (I haven't bothered) add a member telling users
when heap allocation will (or has) occurred.
Chris
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 9 Jan 2016 23:50:21 +0800
Raw View
--Apple-Mail=_C418F14F-F77E-47BB-A90A-433E8BED59ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9301=E2=80=9309, at 10:48 PM, Nicol Bolas <jmckesson@gmail.=
com> wrote:
>=20
> I didn't say that. I'm saying that, if `small_vector` progresses forward =
as it is, it will replace `vector`. And that fact needs to be recognized an=
d discussed for its implications.
small_vector is more complex (prone to bloat) and less capable (no iterator=
transfers, at least not reliably). Some folks used to say that deque would=
displace vector, and it has better iterator stability.
Note that a typical layout of std::vector is three machine-words: {begin, e=
nd, capacity_end}. When small_vector storage is local, begin and capacity_e=
nd become redundant. Implementations will likely want to recycle at least o=
ne of those words for the storage block. Whether or not the user cares abou=
t bloat, implementation commonality (such as class inheritance) may involve=
performance trade-offs in both small_vector and vector.
Also, just a note, one use-case would be forbidding heap allocation and let=
ting the local capacity be an upper bound on the size. This could be done b=
y a custom allocator which always throws or asserts on allocation. Unless t=
here=E2=80=99s a better means to the end, the standard library should provi=
de such an allocator.
Just a bikeshed suggestion: =E2=80=9Csmall=E2=80=9D describes the precondit=
ion to optimization, not the class. Typically sizeof(small_vector<T>) > siz=
eof(vector<T>). Perhaps consider local_vector.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_C418F14F-F77E-47BB-A90A-433E8BED59ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9301=
=E2=80=9309, at 10:48 PM, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail=
..com" class=3D"">jmckesson@gmail.com</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><span style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !impo=
rtant;" class=3D"">I didn't say that. I'm saying that, if `small_vector` pr=
ogresses forward as it is, it will replace `vector`. And that fact needs to=
be recognized and discussed for its implications.</span><br style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div=
></blockquote></div><br class=3D""><div class=3D""><font face=3D"Courier" c=
lass=3D"">small_vector</font> is more complex (prone to bloat) and less cap=
able (no iterator transfers, at least not reliably). Some folks used to say=
that <font face=3D"Courier" class=3D"">deque</font> would displace <font f=
ace=3D"Courier" class=3D"">vector</font>, and it has <i class=3D"">better</=
i> iterator stability.</div><div class=3D""><br class=3D""></div><div class=
=3D"">Note that a typical layout of <font face=3D"Courier" class=3D"">std::=
vector</font> is three machine-words: <font face=3D"Courier" class=3D"">{be=
gin, end, capacity_end}</font>. When <span style=3D"font-family: Couri=
er;" class=3D"">small_vector</span> storage is local, <font face=3D"Co=
urier" class=3D"">begin</font> and <font face=3D"Courier" class=3D"">capaci=
ty_end</font> become redundant. Implementations will likely want to recycle=
at least one of those words for the storage block. Whether or not the user=
cares about bloat, implementation commonality (such as class inheritance) =
may involve performance trade-offs in both <font face=3D"Courier" class=3D"=
">small_vector</font> and <font face=3D"Courier" class=3D"">vector</font>.<=
/div><div class=3D""><br class=3D""></div><div class=3D""><div class=3D"">A=
lso, just a note, one use-case would be forbidding heap allocation and lett=
ing the local capacity be an upper bound on the size. This could be done by=
a custom allocator which always throws or asserts on allocation. Unless th=
ere=E2=80=99s a better means to the end, the standard library should provid=
e such an allocator.</div></div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Just a bikeshed suggestion: =E2=80=9Csmall=E2=80=9D describes the=
precondition to optimization, not the class. Typically <font face=3D"Couri=
er" class=3D"">sizeof(small_vector<T>) > sizeof(vector<T>)</=
font>. Perhaps consider <font face=3D"Courier" class=3D"">local_vector=
</font>.</div><div class=3D""><br class=3D""></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_C418F14F-F77E-47BB-A90A-433E8BED59ED--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 09 Jan 2016 12:30:28 -0500
Raw View
Also, once a small vector allocates, then gets small again, does it free th=
e allocation and go back to local memory? I would guess not. So checking th=
e number of elements doesn't tell you if iterators will be maintained. I gu=
ess you need to check capacity or we offer an explicit function?
=C2=A0I imagine code trying to work with maybe-valid-if-this-or-that terato=
rs=E2=80=8E is going to be convoluted and error-prone.=C2=A0
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Christopher Jefferson
Sent: Saturday, January 9, 2016 9:49 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Views on a small_vector<T, N>?
On 8 January 2016 at 22:32, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:
>
> So what you're saying is that, if I have a `small_vector<T, 4>` which
> contains 12 elements, and I move it to another `small_vector<T, 4>`, you'=
re
> telling me that the specification of `small_vector` should not allow me t=
o
> keep the iterators?
>
Here is one reason to forbid keeping the iterators.
In my implementation of small_vector, sizeof(small_vector<char, 3>) =3D=3D
sizeof(small_vector<char, 8>), because of padding. Giving the space is
already used, small_vector<char, 3> stores 8 elements before it
allocates from the heap.
Of course, I could (I haven't bothered) add a member telling users
when heap allocation will (or has) occurred.
Chris
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 9 Jan 2016 13:43:45 -0800 (PST)
Raw View
------=_Part_932_465096121.1452375826004
Content-Type: multipart/alternative;
boundary="----=_Part_933_1466475624.1452375826004"
------=_Part_933_1466475624.1452375826004
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 9, 2016 at 12:30:32 PM UTC-5, Tony V E wrote:
>
> Also, once a small vector allocates, then gets small again, does it free=
=20
> the allocation and go back to local memory? I would guess not. So checkin=
g=20
> the number of elements doesn't tell you if iterators will be maintained. =
I=20
> guess you need to check capacity or we offer an explicit function?=20
>
It should be no different from doing this:
small_vector<int, 6> v;
v.reserve(12);
This should be required to allocate memory.
`vector` is not allowed to reallocate just because you reduce the size. The=
=20
*only* operations that are allowed to reallocate are insertions, explicit=
=20
`reserve`, and explicit `shrink_to_fit` calls. The same should be true of=
=20
`small_vector`.
A `small_vector` is only small when its capacity is less than the requested=
=20
size.
I imagine code trying to work with maybe-valid-if-this-or-that terators=E2=
=80=8E=20
> is going to be convoluted and error-prone.
>
To be honest, it's no more convoluted than `vector'`s already convoluted=20
rules for invalidation. As long as you can put a check in the code that=20
expresses when invalidation will and won't happen, it's fine.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_933_1466475624.1452375826004
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, January 9, 2016 at 12:30:32 PM UTC-5, Tony V =
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Also, once a small vec=
tor allocates, then gets small again, does it free the allocation and go ba=
ck to local memory? I would guess not. So checking the number of elements d=
oesn't tell you if iterators will be maintained. I guess you need to ch=
eck capacity or we offer an explicit function?
<br></blockquote><div><br>It should be no different from doing 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; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">small_vecto=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</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: #=
066;" class=3D"styled-by-prettify">6</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">reserve</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">12</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br=
>This should be required to allocate memory.<br><br>`vector` is not allowed=
to reallocate just because you reduce the size. The <i>only</i> operations=
that are allowed to reallocate are insertions, explicit `reserve`, and exp=
licit `shrink_to_fit` calls. The same should be true of `small_vector`.<br>=
<br>A `small_vector` is only small when its capacity is less than the reque=
sted size.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=C2=A0I imagine code trying to work with maybe-valid-if-this-or-that terato=
rs=E2=80=8E is going to be convoluted and error-prone.<br></blockquote><div=
><br>To be honest, it's no more convoluted than `vector'`s already =
convoluted rules for invalidation. As long as you can put a check in the co=
de that expresses when invalidation will and won't happen, it's fin=
e.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_933_1466475624.1452375826004--
------=_Part_932_465096121.1452375826004--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 9 Jan 2016 13:53:13 -0800 (PST)
Raw View
------=_Part_996_1676378656.1452376393962
Content-Type: multipart/alternative;
boundary="----=_Part_997_11994987.1452376393963"
------=_Part_997_11994987.1452376393963
Content-Type: text/plain; charset=UTF-8
On Saturday, January 9, 2016 at 9:49:27 AM UTC-5, Chris Jefferson wrote:
>
> On 8 January 2016 at 22:32, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:
>
> >
> > So what you're saying is that, if I have a `small_vector<T, 4>` which
> > contains 12 elements, and I move it to another `small_vector<T, 4>`,
> you're
> > telling me that the specification of `small_vector` should not allow me
> to
> > keep the iterators?
> >
>
> Here is one reason to forbid keeping the iterators.
>
> In my implementation of small_vector, sizeof(small_vector<char, 3>) ==
> sizeof(small_vector<char, 8>), because of padding. Giving the space is
> already used, small_vector<char, 3> stores 8 elements before it
> allocates from the heap.
>
I would never use such a small_vector.
If I ask for a `small_vector<T, 3>`, then I mean for it to allocate memory
once the capacity goes past 4. Regardless of what T is.
We tolerate this behavior from std::string because it's not required to use
small allocations and we aren't allowed to specify them. That's not the
case for small_vector. It should do *exactly* what it is told to do.
The small_vector buffer size is not a recommendation; it's a requirement.
If you want your kind of behavior, we can have a metafunction that computes
a minimum small element count, based on the size of `T` and the size of
`small_vector`. Perhaps we could have the default size calculate such an
optimal, implementation-dependent size.
But some of us want the type to do *exactly* what we tell it to do.
Personally, I've had enough of implementations being able to weasel around
`reserve` behavior and such, and I hope N4524 (enforced capacity
requirements) gets in for exactly this reason.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_997_11994987.1452376393963
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 9, 2016 at 9:49:27 AM UTC-5, Chris Jefferson wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On 8 January 2016 at 22:32, Nicol=
Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"a4PfoImbFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">jmck...@gmail.com</a>> wrote:
<br>> On Friday, January 8, 2016 at 11:06:46 AM UTC-5, Tony V E wrote:
<br>
<br>>
<br>> So what you're saying is that, if I have a `small_vector<T,=
4>` which
<br>> contains 12 elements, and I move it to another `small_vector<T,=
4>`, you're
<br>> telling me that the specification of `small_vector` should not all=
ow me to
<br>> keep the iterators?
<br>>
<br>
<br>Here is one reason to forbid keeping the iterators.
<br>
<br>In my implementation of small_vector, sizeof(small_vector<char, 3>=
;) =3D=3D
<br>sizeof(small_vector<char, 8>), because of padding. Giving the spa=
ce is
<br>already used, small_vector<char, 3> stores 8 elements before it
<br>allocates from the heap.<br></blockquote><div><br>I would never use suc=
h a small_vector.<br><br>If I ask for a `small_vector<T, 3>`, then I =
mean for it to allocate memory once the capacity goes past 4. Regardless of=
what T is.<br><br>We tolerate this behavior from std::string because it=
9;s not required to use small allocations and we aren't allowed to spec=
ify them. That's not the case for small_vector. It should do <i>exactly=
</i> what it is told to do.<br><br>The small_vector buffer size is not a re=
commendation; it's a requirement. If you want your kind of behavior, we=
can have a metafunction that computes a minimum small element count, based=
on the size of `T` and the size of `small_vector`. Perhaps we could have t=
he default size calculate such an optimal, implementation-dependent size.<b=
r><br>But some of us want the type to do <i>exactly</i> what we tell it to =
do. Personally, I've had enough of implementations being able to weasel=
around `reserve` behavior and such, and I hope N4524 (enforced capacity re=
quirements) gets in for exactly this reason.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_997_11994987.1452376393963--
------=_Part_996_1676378656.1452376393962--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 9 Jan 2016 14:05:10 -0800 (PST)
Raw View
------=_Part_668_810128948.1452377110637
Content-Type: multipart/alternative;
boundary="----=_Part_669_2097205305.1452377110637"
------=_Part_669_2097205305.1452377110637
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 9, 2016 at 10:50:32 AM UTC-5, David Krauss wrote:
>
> On 2016=E2=80=9301=E2=80=9309, at 10:48 PM, Nicol Bolas <jmck...@gmail.co=
m <javascript:>>=20
> wrote:
>
> I didn't say that. I'm saying that, if `small_vector` progresses forward=
=20
> as it is, it will replace `vector`. And that fact needs to be recognized=
=20
> and discussed for its implications.
>
>
> small_vector is more complex (prone to bloat) and less capable (no=20
> iterator transfers, at least not reliably).
>
When people talk about `small_vector` replacing `vector`, it would be=20
`small_vector<T, 0>` that does the replacing. Which by all rights ought to=
=20
be functionally identical to `vector`, since it has no small buffer size.
Indeed, if `small_vector<T, 0>` is allowed, it's going to have to, at some=
=20
level, do some specialization of the implementation. After all, you can't=
=20
have zero-sized arrays in C++, so the usual method of having a memory=20
buffer that is one thing or the other doesn't work. So by specializing it a=
=20
bit more, all implementation overhead goes away, and `small_vector<T, 0>`=
=20
is just `vector<T>` with a different name and a few extraneous functions.
=20
> Also, just a note, one use-case would be forbidding heap allocation and=
=20
> letting the local capacity be an upper bound on the size.
>
No, that's a different class. A *useful* one to be sure, but different.
`small_vector` is for when I know that I will mostly live within a certain=
=20
reasonable boundary, but sometimes will blow past it. It is purely an=20
optimization of `vector` for certain specific use cases.
What you're talking about is Boost's `static_vector`=20
<http://www.boost.org/doc/libs/1_60_0/doc/html/container/non_standard_conta=
iners.html#container.non_standard_containers.static_vector>,=20
which is for when I *know* I won't exceed a certain limit, and I want that=
=20
object to live entirely on the stack. I think `static_vector` is, while=20
useful, a much more narrow use case.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_669_2097205305.1452377110637
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 9, 2016 at 10:50:32 AM UTC-5, David Krauss wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"=
><div><blockquote type=3D"cite"><div>On 2016=E2=80=9301=E2=80=9309, at 10:4=
8 PM, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"qELA_96eFAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">jmck...@gmail.com</a>> wrote:</div><br><div><span style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px;float:none;displ=
ay:inline!important">I didn't say that. I'm saying that, if `small_=
vector` progresses forward as it is, it will replace `vector`. And that fac=
t needs to be recognized and discussed for its implications.</span><br styl=
e=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:no=
rmal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockq=
uote></div><br><div><font face=3D"Courier">small_vector</font> is more comp=
lex (prone to bloat) and less capable (no iterator transfers, at least not =
reliably).</div></div></blockquote><div><br>When people talk about `small_v=
ector` replacing `vector`, it would be `small_vector<T, 0>` that does=
the replacing. Which by all rights ought to be functionally identical to `=
vector`, since it has no small buffer size.<br><br>Indeed, if `small_vector=
<T, 0>` is allowed, it's going to have to, at some level, do some=
specialization of the implementation. After all, you can't have zero-s=
ized arrays in C++, so the usual method of having a memory buffer that is o=
ne thing or the other doesn't work. So by specializing it a bit more, a=
ll implementation overhead goes away, and `small_vector<T, 0>` is jus=
t `vector<T>` with a different name and a few extraneous functions.<b=
r>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><div></div><div><div>Also, just a note, one use-c=
ase would be forbidding heap allocation and letting the local capacity be a=
n upper bound on the size.</div></div></div></blockquote><div><br>No, that&=
#39;s a different class. A <i>useful</i> one to be sure, but different.<br>=
<br>`small_vector` is for when I know that I will mostly live within a cert=
ain reasonable boundary, but sometimes will blow past it. It is purely an o=
ptimization of `vector` for certain specific use cases.<br><br>What you'=
;re talking about is <a href=3D"http://www.boost.org/doc/libs/1_60_0/doc/ht=
ml/container/non_standard_containers.html#container.non_standard_containers=
..static_vector">Boost's `static_vector`</a>, which is for when I <i>kno=
w</i> I won't exceed a certain limit, and I want that object to live en=
tirely on the stack. I think `static_vector` is, while useful, a much more =
narrow use case.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_669_2097205305.1452377110637--
------=_Part_668_810128948.1452377110637--
.
Author: Ross Smith <ross.smith@otoy.com>
Date: Mon, 11 Jan 2016 08:57:41 +1300
Raw View
On 2016-01-08 00:02, Tristan Brindle wrote:
>
> ii. Declaring vector<T>to be an alias for vararray<T, 0>today would
> require vararray<bool, 0>to be specialised, due to (i).
You can get around that:
template <typename T, size_t N> class vararray;
class bitarray; // = current vector<bool>
template <typename T, size_t N> class vector_helper {
using type = vararray<T, N>;
};
template <> class vector_helper<bool, 0> {
using type = bitarray;
};
template <typename T, size_t N> using vector
= typename vector_helper<T, N>::type;
Ross Smith
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Sun, 10 Jan 2016 17:14:35 -0300
Raw View
On 1/10/2016 4:57 PM, Ross Smith wrote:
> On 2016-01-08 00:02, Tristan Brindle wrote:
>>
>> ii. Declaring vector<T>to be an alias for vararray<T, 0>today would
>> require vararray<bool, 0>to be specialised, due to (i).
>
> You can get around that:
Not transparently, no.
> template <typename T, size_t N> class vararray;
> class bitarray; // =3D current vector<bool>
>
> template <typename T, size_t N> class vector_helper {
> using type =3D vararray<T, N>;
> };
>
> template <> class vector_helper<bool, 0> {
> using type =3D bitarray;
> };
Those nested `type`s are private.
> template <typename T, size_t N> using vector
> =3D typename vector_helper<T, N>::type;
This alias being dependent means you'll lose deductive powers. You'd=20
probably still want the following snippet to work:
template <typename T, std::size_t N>
void foo(vector<T, N> const& vs) {}
vector<int, 42> vs;
foo(vs); // error: couldn't infer template argument
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.