------=_Part_2885_1638680542.1488044460814
Content-Type: multipart/alternative;
 boundary="----=_Part_2886_1821907842.1488044460814"

------=_Part_2886_1821907842.1488044460814
Content-Type: text/plain; charset=UTF-8

There have been a lot of proposals and ideas thrown about for various
`vector` classes that have identical interfaces but different behaviors.
I'm wondering if it might not be better to have them all aggregated into
some `omni_vector` type that uses a template parameter to pick which
particular options you want.

A necessary first step is to figure out what all of the options such an
`omni_vector` might provide. Here are the ones I know about:

* Small storage buffer (SSB) space: 0 to arbitrary number.
* Maximum size: compile-time
static/runtime-upon-construction/always-unbounded

One of the advantages of having all of these variances in one type is to
more easily require movement between them. So an `omni_vector` with SSB/16
and an `omni_vector` that has no SSB but has a fixed size can still be
efficiently moved between so long as the allocators are the same (and if
the SSB vector's current size is greater than its SSB size).

Also, by putting them all in one type, you can create useful combinations.
Like a vector that never allocates memory, because the SSB size is equal to
the compile-time maximum size.

Instantiating such a type might look like this: `omni_vector<Typename,
ov_params<ov_ssb<32>, ov_max_static<32>>`. The order of such parameters
would not be fixed; it would use template metaprogramming to pick the first
parameter from the list for a particular option.

What are the other variances that people want?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/38052307-8ef9-4d41-b902-826f56630c10%40isocpp.org.

------=_Part_2886_1821907842.1488044460814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There have been a lot of proposals and ideas thrown about =
for various `vector` classes that have identical interfaces but different b=
ehaviors. I&#39;m wondering if it might not be better to have them all aggr=
egated into some `omni_vector` type that uses a template parameter to pick =
which particular options you want.<br><br>A necessary first step is to figu=
re out what all of the options such an `omni_vector` might provide. Here ar=
e the ones I know about:<br><br>* Small storage buffer (SSB) space: 0 to ar=
bitrary number.<br>* Maximum size: compile-time static/runtime-upon-constru=
ction/always-unbounded<br><br>One of the advantages of having all of these =
variances in one type is to more easily require movement between them. So a=
n `omni_vector` with SSB/16 and an `omni_vector` that has no SSB but has a =
fixed size can still be efficiently moved between so long as the allocators=
 are the same (and if the SSB vector&#39;s current size is greater than its=
 SSB size).<br><br>Also, by putting them all in one type, you can create us=
eful combinations. Like a vector that never allocates memory, because the S=
SB size is equal to the compile-time maximum size.<br><br>Instantiating suc=
h a type might look like this: `omni_vector&lt;Typename, ov_params&lt;ov_ss=
b&lt;32&gt;, ov_max_static&lt;32&gt;&gt;`. The order of such parameters wou=
ld not be fixed; it would use template metaprogramming to pick the first pa=
rameter from the list for a particular option.<br><br>What are the other va=
riances that people want?<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/38052307-8ef9-4d41-b902-826f56630c10%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/38052307-8ef9-4d41-b902-826f56630c10=
%40isocpp.org</a>.<br />

------=_Part_2886_1821907842.1488044460814--

------=_Part_2885_1638680542.1488044460814--

.

------=_Part_515_973129612.1488104742005
Content-Type: multipart/alternative;
 boundary="----=_Part_516_371680355.1488104742005"

------=_Part_516_371680355.1488104742005
Content-Type: text/plain; charset=UTF-8



On Saturday, February 25, 2017 at 6:41:01 PM UTC+1, Nicol Bolas wrote:
>
> There have been a lot of proposals and ideas thrown about for various
> `vector` classes that have identical interfaces but different behaviors.
> I'm wondering if it might not be better to have them all aggregated into
> some `omni_vector` type that uses a template parameter to pick which
> particular options you want.
>
> A necessary first step is to figure out what all of the options such an
> `omni_vector` might provide. Here are the ones I know about:
>
> * Small storage buffer (SSB) space: 0 to arbitrary number.
> * Maximum size: compile-time
> static/runtime-upon-construction/always-unbounded
>
> One of the advantages of having all of these variances in one type is to
> more easily require movement between them. So an `omni_vector` with SSB/16
> and an `omni_vector` that has no SSB but has a fixed size can still be
> efficiently moved between so long as the allocators are the same (and if
> the SSB vector's current size is greater than its SSB size).
>
> Also, by putting them all in one type, you can create useful combinations.
> Like a vector that never allocates memory, because the SSB size is equal to
> the compile-time maximum size.
>
> Instantiating such a type might look like this: `omni_vector<Typename,
> ov_params<ov_ssb<32>, ov_max_static<32>>`. The order of such parameters
> would not be fixed; it would use template metaprogramming to pick the first
> parameter from the list for a particular option.
>
> What are the other variances that people want?
>

This could fix problem with `std::vector<bool>`, current vector would be:
`omni_vector<Typename, ov_compress_bool>` and if you want "normal" behavior
you will use directly `omni_vector<bool>`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dc2e850c-4cf4-450c-948c-5510ee88f622%40isocpp.org.

------=_Part_516_371680355.1488104742005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, February 25, 2017 at 6:41:01 PM UTC+1=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">There have been a lot of proposals and ideas thrown about for vari=
ous `vector` classes that have identical interfaces but different behaviors=
.. I&#39;m wondering if it might not be better to have them all aggregated i=
nto some `omni_vector` type that uses a template parameter to pick which pa=
rticular options you want.<br><br>A necessary first step is to figure out w=
hat all of the options such an `omni_vector` might provide. Here are the on=
es I know about:<br><br>* Small storage buffer (SSB) space: 0 to arbitrary =
number.<br>* Maximum size: compile-time static/runtime-upon-<wbr>constructi=
on/always-unbounded<br><br>One of the advantages of having all of these var=
iances in one type is to more easily require movement between them. So an `=
omni_vector` with SSB/16 and an `omni_vector` that has no SSB but has a fix=
ed size can still be efficiently moved between so long as the allocators ar=
e the same (and if the SSB vector&#39;s current size is greater than its SS=
B size).<br><br>Also, by putting them all in one type, you can create usefu=
l combinations. Like a vector that never allocates memory, because the SSB =
size is equal to the compile-time maximum size.<br><br>Instantiating such a=
 type might look like this: `omni_vector&lt;Typename, ov_params&lt;ov_ssb&l=
t;32&gt;, ov_max_static&lt;32&gt;&gt;`. The order of such parameters would =
not be fixed; it would use template metaprogramming to pick the first param=
eter from the list for a particular option.<br><br>What are the other varia=
nces that people want?<br></div></blockquote><div><br>This could fix proble=
m with `std::vector&lt;bool&gt;`, current vector would be: `omni_vector&lt;=
Typename, ov_compress_bool&gt;` and if you want &quot;normal&quot; behavior=
 you will use directly `omni_vector&lt;bool&gt;`.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dc2e850c-4cf4-450c-948c-5510ee88f622%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc2e850c-4cf4-450c-948c-5510ee88f622=
%40isocpp.org</a>.<br />

------=_Part_516_371680355.1488104742005--

------=_Part_515_973129612.1488104742005--

.

2017-02-26 11:25 GMT+01:00  <inkwizytoryankes@gmail.com>:
>> What are the other variances that people want?
>
> This could fix problem with `std::vector<bool>`, current vector would be:
> `omni_vector<Typename, ov_compress_bool>` and if you want "normal" behavior
> you will use directly `omni_vector<bool>`.

It is very unlikely that this will happen, because that would break
current valid usages of std::vector as template template parameter.
For exactly that reason (That is: Don't change template parameter
lists of existing Library components), Library implementations are not
allowed to add further template parameters with default parameters,
see

http://cplusplus.github.io/LWG/lwg-closed.html#94

- Daniel

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgD_UM_11iqky8oefsmVxx9gQ8qUShsHK_MxLz9bRrKTrQ%40mail.gmail.com.

.

On 02/25/17 20:41, Nicol Bolas wrote:
> There have been a lot of proposals and ideas thrown about for various
> `vector` classes that have identical interfaces but different behaviors.
> I'm wondering if it might not be better to have them all aggregated into
> some `omni_vector` type that uses a template parameter to pick which
> particular options you want.
>
> A necessary first step is to figure out what all of the options such an
> `omni_vector` might provide. Here are the ones I know about:
>
> * Small storage buffer (SSB) space: 0 to arbitrary number.
> * Maximum size: compile-time
> static/runtime-upon-construction/always-unbounded
>
> One of the advantages of having all of these variances in one type is to
> more easily require movement between them. So an `omni_vector` with
> SSB/16 and an `omni_vector` that has no SSB but has a fixed size can
> still be efficiently moved between so long as the allocators are the
> same (and if the SSB vector's current size is greater than its SSB size).
>
> Also, by putting them all in one type, you can create useful
> combinations. Like a vector that never allocates memory, because the SSB
> size is equal to the compile-time maximum size.
>
> Instantiating such a type might look like this: `omni_vector<Typename,
> ov_params<ov_ssb<32>, ov_max_static<32>>`. The order of such parameters
> would not be fixed; it would use template metaprogramming to pick the
> first parameter from the list for a particular option.
>
> What are the other variances that people want?

As a reference, see a few vector variants provided by Boost.Container:

http://www.boost.org/doc/libs/1_63_0/doc/html/container/non_standard_containers.html

Personally, I don't see the benefit of unification of various flavors of
vector under the common name. Having specialized names, actually, makes
more sense for code readability and searchability. I'm sure, it will
also be better for compile times as there's no need for metaprogramming
layer for sorting out policy template parameters.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3fcee1aa-2092-20c0-ee9c-7b81f1f81d0f%40gmail.com.

.

------=_Part_4139_677269076.1488120297200
Content-Type: multipart/alternative;
 boundary="----=_Part_4140_244571798.1488120297200"

------=_Part_4140_244571798.1488120297200
Content-Type: text/plain; charset=UTF-8



On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev wrote:
>
> On 02/25/17 20:41, Nicol Bolas wrote:
> > There have been a lot of proposals and ideas thrown about for various
> > `vector` classes that have identical interfaces but different behaviors.
> > I'm wondering if it might not be better to have them all aggregated into
> > some `omni_vector` type that uses a template parameter to pick which
> > particular options you want.
> >
> > A necessary first step is to figure out what all of the options such an
> > `omni_vector` might provide. Here are the ones I know about:
> >
> > * Small storage buffer (SSB) space: 0 to arbitrary number.
> > * Maximum size: compile-time
> > static/runtime-upon-construction/always-unbounded
> >
> > One of the advantages of having all of these variances in one type is to
> > more easily require movement between them. So an `omni_vector` with
> > SSB/16 and an `omni_vector` that has no SSB but has a fixed size can
> > still be efficiently moved between so long as the allocators are the
> > same (and if the SSB vector's current size is greater than its SSB
> size).
> >
> > Also, by putting them all in one type, you can create useful
> > combinations. Like a vector that never allocates memory, because the SSB
> > size is equal to the compile-time maximum size.
> >
> > Instantiating such a type might look like this: `omni_vector<Typename,
> > ov_params<ov_ssb<32>, ov_max_static<32>>`. The order of such parameters
> > would not be fixed; it would use template metaprogramming to pick the
> > first parameter from the list for a particular option.
> >
> > What are the other variances that people want?
>
> As a reference, see a few vector variants provided by Boost.Container:
>
>
> http://www.boost.org/doc/libs/1_63_0/doc/html/container/non_standard_containers.html
>
> Personally, I don't see the benefit of unification of various flavors of
> vector under the common name. Having specialized names, actually, makes
> more sense for code readability and searchability. I'm sure, it will
> also be better for compile times as there's no need for metaprogramming
> layer for sorting out policy template parameters.
>

The benefit of putting them under a common name is not to have a common
name. It's to allow users to mix and match behavior as they see fit, with
*guaranteed* interoperability.

Here are all of the possibilities that someone might genuinely want:

static_vector: compile-time maximum size, but allocates memory up to that
size.
static_small_vector: compile-time maximum size with an internal buffer
store.
dynamic_vector: runtime maximum size.
dynamic_small_vector: runtime maximum size with an internal buffer store.
vector: grows as needed.
small_vector: grows as needed, with an internal buffer store.

Each of those combinations has just as much justification as the others. An
allocating `static_vector` really is useful in some cases; you want it to
allocate, but you don't want it to grow beyond that allocation. A
`static_small_vector` that stores its data internally is also useful; it
does no allocations. For the dynamic case, having small buffer optimization
is useful, but it's also useful to have guarantees of pointer stability on
move operations. And vector vs. small_vector is similarly well understood.

So it is clear that there is a need for each and every such combination.
And thus, we should have each and every one of those classes. But what
happens if we add another domain to that, like `stability` from
`boost:stable_vector`? Now all of a sudden, we need *twelve* classes, not
6. Why shouldn't someone be able to have a `static_stable_vector`? Why not
a `dynamic_small_stable_vector`?

See the problem? The multiplicative explosion of vectors makes this
unworkable. This leaves us either with lots and lots of vector classes, or
we only provide the lowest common denominator: `vector`, `small_vector`,
`static_vector`, `dynamic_vector` and `stable_vector`. No combinations of
any of those features with each other.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81ec3e8e-c380-416d-8f02-6f3c5180728f%40isocpp.org.

------=_Part_4140_244571798.1488120297200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, =
Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 02/25=
/17 20:41, Nicol Bolas wrote:
<br>&gt; There have been a lot of proposals and ideas thrown about for vari=
ous
<br>&gt; `vector` classes that have identical interfaces but different beha=
viors.
<br>&gt; I&#39;m wondering if it might not be better to have them all aggre=
gated into
<br>&gt; some `omni_vector` type that uses a template parameter to pick whi=
ch
<br>&gt; particular options you want.
<br>&gt;
<br>&gt; A necessary first step is to figure out what all of the options su=
ch an
<br>&gt; `omni_vector` might provide. Here are the ones I know about:
<br>&gt;
<br>&gt; * Small storage buffer (SSB) space: 0 to arbitrary number.
<br>&gt; * Maximum size: compile-time
<br>&gt; static/runtime-upon-<wbr>construction/always-unbounded
<br>&gt;
<br>&gt; One of the advantages of having all of these variances in one type=
 is to
<br>&gt; more easily require movement between them. So an `omni_vector` wit=
h
<br>&gt; SSB/16 and an `omni_vector` that has no SSB but has a fixed size c=
an
<br>&gt; still be efficiently moved between so long as the allocators are t=
he
<br>&gt; same (and if the SSB vector&#39;s current size is greater than its=
 SSB size).
<br>&gt;
<br>&gt; Also, by putting them all in one type, you can create useful
<br>&gt; combinations. Like a vector that never allocates memory, because t=
he SSB
<br>&gt; size is equal to the compile-time maximum size.
<br>&gt;
<br>&gt; Instantiating such a type might look like this: `omni_vector&lt;Ty=
pename,
<br>&gt; ov_params&lt;ov_ssb&lt;32&gt;, ov_max_static&lt;32&gt;&gt;`. The o=
rder of such parameters
<br>&gt; would not be fixed; it would use template metaprogramming to pick =
the
<br>&gt; first parameter from the list for a particular option.
<br>&gt;
<br>&gt; What are the other variances that people want?
<br>
<br>As a reference, see a few vector variants provided by Boost.Container:
<br>
<br><a href=3D"http://www.boost.org/doc/libs/1_63_0/doc/html/container/non_=
standard_containers.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org=
%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%2Fnon_standard_containers.h=
tml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFzWlE16khK9YM4MF8EJ31qxDmDwQ&#3=
9;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_63_0%2Fdoc%2Fhtml%2Fcontainer%=
2Fnon_standard_containers.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFzWl=
E16khK9YM4MF8EJ31qxDmDwQ&#39;;return true;">http://www.boost.org/doc/libs/<=
wbr>1_63_0/doc/html/container/non_<wbr>standard_containers.html</a>
<br>
<br>Personally, I don&#39;t see the benefit of unification of various flavo=
rs of=20
<br>vector under the common name. Having specialized names, actually, makes=
=20
<br>more sense for code readability and searchability. I&#39;m sure, it wil=
l=20
<br>also be better for compile times as there&#39;s no need for metaprogram=
ming=20
<br>layer for sorting out policy template parameters.<br></blockquote><div>=
<br>The benefit of putting them under a common name is not to have a common=
 name. It&#39;s to allow users to mix and match behavior as they see fit, w=
ith <i>guaranteed</i> interoperability.<br><br>Here are all of the possibil=
ities that someone might genuinely want:<br><br>static_vector: compile-time=
 maximum size, but allocates memory up to that size.<br>static_small_vector=
: compile-time maximum size with an internal buffer store.<br>dynamic_vecto=
r: runtime maximum size.<br>dynamic_small_vector: runtime maximum size with=
 an internal buffer store.<br>vector: grows as needed.<br>small_vector: gro=
ws as needed, with an internal buffer store.<br><br>Each of those combinati=
ons has just as much justification as the others. An allocating `static_vec=
tor` really is useful in some cases; you want it to allocate, but you don&#=
39;t want it to grow beyond that allocation. A `static_small_vector` that s=
tores its data internally is also useful; it does no allocations. For the d=
ynamic case, having small buffer optimization is useful, but it&#39;s also =
useful to have guarantees of pointer stability on move operations. And vect=
or vs. small_vector is similarly well understood.<br><br>So it is clear tha=
t there is a need for each and every such combination. And thus, we should =
have each and every one of those classes. But what happens if we add anothe=
r domain to that, like `stability` from `boost:stable_vector`? Now all of a=
 sudden, we need <i>twelve</i> classes, not 6. Why shouldn&#39;t someone be=
 able to have a `static_stable_vector`? Why not a `dynamic_small_stable_vec=
tor`?<br><br>See the problem? The multiplicative explosion of vectors makes=
 this unworkable. This leaves us either with lots and lots of vector classe=
s, or we only provide the lowest common denominator: `vector`, `small_vecto=
r`, `static_vector`, `dynamic_vector` and `stable_vector`. No combinations =
of any of those features with each other.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81ec3e8e-c380-416d-8f02-6f3c5180728f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81ec3e8e-c380-416d-8f02-6f3c5180728f=
%40isocpp.org</a>.<br />

------=_Part_4140_244571798.1488120297200--

------=_Part_4139_677269076.1488120297200--

.

On 02/26/17 17:44, Nicol Bolas wrote:
> On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev wrote:
>
>     Personally, I don't see the benefit of unification of various
>     flavors of
>     vector under the common name. Having specialized names, actually, makes
>     more sense for code readability and searchability. I'm sure, it will
>     also be better for compile times as there's no need for metaprogramming
>     layer for sorting out policy template parameters.
>
> The benefit of putting them under a common name is not to have a common
> name. It's to allow users to mix and match behavior as they see fit,
> with /guaranteed/ interoperability.
>
> Here are all of the possibilities that someone might genuinely want:
>
> static_vector: compile-time maximum size, but allocates memory up to
> that size.
> static_small_vector: compile-time maximum size with an internal buffer
> store.
> dynamic_vector: runtime maximum size.
> dynamic_small_vector: runtime maximum size with an internal buffer store.
> vector: grows as needed.
> small_vector: grows as needed, with an internal buffer store.
>
> Each of those combinations has just as much justification as the others.
> An allocating `static_vector` really is useful in some cases; you want
> it to allocate, but you don't want it to grow beyond that allocation. A
> `static_small_vector` that stores its data internally is also useful; it
> does no allocations. For the dynamic case, having small buffer
> optimization is useful, but it's also useful to have guarantees of
> pointer stability on move operations. And vector vs. small_vector is
> similarly well understood.
>
> So it is clear that there is a need for each and every such combination.
> And thus, we should have each and every one of those classes. But what
> happens if we add another domain to that, like `stability` from
> `boost:stable_vector`? Now all of a sudden, we need /twelve/ classes,
> not 6. Why shouldn't someone be able to have a `static_stable_vector`?
> Why not a `dynamic_small_stable_vector`?

Thing is, some combinations are not possible or practical. For instance,
`stable_vector` allocates each element separately, which would prohibit
using a local storage for it. Well, you could preallocate storage for
max number of elements *and* the table of pointers to them, but that's a
different amount of storage than a different kind of `vector` would
require, which means the user's code can't predict the amount of storage
needed.

And internally, these vectors may be very very different - so different
in fact that the common name and interface would only complicate the
implementation by having to dispatch between the different backends.
This also means that anyone who needs only one of those backends must
bring in the other ones as well as dependencies.

> See the problem? The multiplicative explosion of vectors makes this
> unworkable. This leaves us either with lots and lots of vector classes,
> or we only provide the lowest common denominator: `vector`,
> `small_vector`, `static_vector`, `dynamic_vector` and `stable_vector`.
> No combinations of any of those features with each other.

Well, I'm not convinced that every combination would be useful in
practice, and that the problem you describe needs solving.

I guess, if you limit your proposal to only allocation strategies, the
ones from your list above, it would make more sense. But then I would
rather see a different design based on allocators, something along these
lines:

   template< typename T, typename... Allocators = std::allocator< T > >
   class multistorage_vector;

   template< typename T, typename Allocator = std::allocator< T > >
   using vector = multistorage_vector< T, Allocator >;

The `multistorage_vector` container would attempt to use storage
provided by the first allocator in the `Allocators` list that succeeds.
This way one would be able to specify first an allocator with a static
local buffer and then an allocator that uses heap.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8f092e67-d3d2-b1c2-a20a-6b4bcfd9417c%40gmail.com.

.

------=_Part_4524_329792716.1488125321067
Content-Type: multipart/alternative;
 boundary="----=_Part_4525_1493802673.1488125321067"

------=_Part_4525_1493802673.1488125321067
Content-Type: text/plain; charset=UTF-8

On Sunday, February 26, 2017 at 10:24:19 AM UTC-5, Andrey Semashev wrote:
>
> On 02/26/17 17:44, Nicol Bolas wrote:
> > On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev wrote:
> >
> >     Personally, I don't see the benefit of unification of various
> >     flavors of
> >     vector under the common name. Having specialized names, actually,
> makes
> >     more sense for code readability and searchability. I'm sure, it will
> >     also be better for compile times as there's no need for
> metaprogramming
> >     layer for sorting out policy template parameters.
> >
> > The benefit of putting them under a common name is not to have a common
> > name. It's to allow users to mix and match behavior as they see fit,
> > with /guaranteed/ interoperability.
> >
> > Here are all of the possibilities that someone might genuinely want:
> >
> > static_vector: compile-time maximum size, but allocates memory up to
> > that size.
> > static_small_vector: compile-time maximum size with an internal buffer
> > store.
> > dynamic_vector: runtime maximum size.
> > dynamic_small_vector: runtime maximum size with an internal buffer
> store.
> > vector: grows as needed.
> > small_vector: grows as needed, with an internal buffer store.
> >
> > Each of those combinations has just as much justification as the others.
> > An allocating `static_vector` really is useful in some cases; you want
> > it to allocate, but you don't want it to grow beyond that allocation. A
> > `static_small_vector` that stores its data internally is also useful; it
> > does no allocations. For the dynamic case, having small buffer
> > optimization is useful, but it's also useful to have guarantees of
> > pointer stability on move operations. And vector vs. small_vector is
> > similarly well understood.
> >
> > So it is clear that there is a need for each and every such combination.
> > And thus, we should have each and every one of those classes. But what
> > happens if we add another domain to that, like `stability` from
> > `boost:stable_vector`? Now all of a sudden, we need /twelve/ classes,
> > not 6. Why shouldn't someone be able to have a `static_stable_vector`?
> > Why not a `dynamic_small_stable_vector`?
>
> Thing is, some combinations are not possible or practical. For instance,
> `stable_vector` allocates each element separately, which would prohibit
> using a local storage for it. Well, you could preallocate storage for
> max number of elements *and* the table of pointers to them, but that's a
> different amount of storage than a different kind of `vector` would
> require, which means the user's code can't predict the amount of storage
> needed.
>

By asking for a stable vector of any sort, you explicitly requested the
class to take up more space than a non-stable one would. So adding small
storage on top of that wouldn't change that fact. You gave up the
assumption of `sizeof(T)*capacity` when you asked for stability.

Besides, the point of small storage is not to be able to predict exactly
how big that vector instance will be (the standard won't guarantee that
anyway). It's to prevent dynamic allocation outside of circumstances that
would be exceptional for your needs.

And internally, these vectors may be very very different - so different
> in fact that the common name and interface would only complicate the
> implementation by having to dispatch between the different backends.
> This also means that anyone who needs only one of those backends must
> bring in the other ones as well as dependencies.
>

>
> See the problem? The multiplicative explosion of vectors makes this
> > unworkable. This leaves us either with lots and lots of vector classes,
> > or we only provide the lowest common denominator: `vector`,
> > `small_vector`, `static_vector`, `dynamic_vector` and `stable_vector`.
> > No combinations of any of those features with each other.
>
> Well, I'm not convinced that every combination would be useful in
> practice, and that the problem you describe needs solving.
>
> I guess, if you limit your proposal to only allocation strategies, the
> ones from your list above, it would make more sense. But then I would
> rather see a different design based on allocators, something along these
> lines:
>
>    template< typename T, typename... Allocators = std::allocator< T > >
>    class multistorage_vector;
>
>    template< typename T, typename Allocator = std::allocator< T > >
>    using vector = multistorage_vector< T, Allocator >;
>
> The `multistorage_vector` container would attempt to use storage
> provided by the first allocator in the `Allocators` list that succeeds.
> This way one would be able to specify first an allocator with a static
> local buffer and then an allocator that uses heap.
>

That would needlessly bloat the `vector`. After all, the `vector` still
needs its own 3 pointers. So it would have to have its own storage plus the
storage of the allocator.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2c5567a-5ece-486c-855b-156caad4b0fc%40isocpp.org.

------=_Part_4525_1493802673.1488125321067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, February 26, 2017 at 10:24:19 AM UTC-5, Andrey =
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 02/26/17 17:=
44, Nicol Bolas wrote:
<br>&gt; On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev =
wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Personally, I don&#39;t see the benefit of unificati=
on of various
<br>&gt; =C2=A0 =C2=A0 flavors of
<br>&gt; =C2=A0 =C2=A0 vector under the common name. Having specialized nam=
es, actually, makes
<br>&gt; =C2=A0 =C2=A0 more sense for code readability and searchability. I=
&#39;m sure, it will
<br>&gt; =C2=A0 =C2=A0 also be better for compile times as there&#39;s no n=
eed for metaprogramming
<br>&gt; =C2=A0 =C2=A0 layer for sorting out policy template parameters.
<br>&gt;
<br>&gt; The benefit of putting them under a common name is not to have a c=
ommon
<br>&gt; name. It&#39;s to allow users to mix and match behavior as they se=
e fit,
<br>&gt; with /guaranteed/ interoperability.
<br>&gt;
<br>&gt; Here are all of the possibilities that someone might genuinely wan=
t:
<br>&gt;
<br>&gt; static_vector: compile-time maximum size, but allocates memory up =
to
<br>&gt; that size.
<br>&gt; static_small_vector: compile-time maximum size with an internal bu=
ffer
<br>&gt; store.
<br>&gt; dynamic_vector: runtime maximum size.
<br>&gt; dynamic_small_vector: runtime maximum size with an internal buffer=
 store.
<br>&gt; vector: grows as needed.
<br>&gt; small_vector: grows as needed, with an internal buffer store.
<br>&gt;
<br>&gt; Each of those combinations has just as much justification as the o=
thers.
<br>&gt; An allocating `static_vector` really is useful in some cases; you =
want
<br>&gt; it to allocate, but you don&#39;t want it to grow beyond that allo=
cation. A
<br>&gt; `static_small_vector` that stores its data internally is also usef=
ul; it
<br>&gt; does no allocations. For the dynamic case, having small buffer
<br>&gt; optimization is useful, but it&#39;s also useful to have guarantee=
s of
<br>&gt; pointer stability on move operations. And vector vs. small_vector =
is
<br>&gt; similarly well understood.
<br>&gt;
<br>&gt; So it is clear that there is a need for each and every such combin=
ation.
<br>&gt; And thus, we should have each and every one of those classes. But =
what
<br>&gt; happens if we add another domain to that, like `stability` from
<br>&gt; `boost:stable_vector`? Now all of a sudden, we need /twelve/ class=
es,
<br>&gt; not 6. Why shouldn&#39;t someone be able to have a `static_stable_=
vector`?
<br>&gt; Why not a `dynamic_small_stable_vector`?
<br>
<br>Thing is, some combinations are not possible or practical. For instance=
,=20
<br>`stable_vector` allocates each element separately, which would prohibit=
=20
<br>using a local storage for it. Well, you could preallocate storage for=
=20
<br>max number of elements *and* the table of pointers to them, but that&#3=
9;s a=20
<br>different amount of storage than a different kind of `vector` would=20
<br>require, which means the user&#39;s code can&#39;t predict the amount o=
f storage=20
<br>needed.<br></blockquote><div><br>By asking for a stable vector of any s=
ort, you explicitly requested the class to take up more space than a non-st=
able one would. So adding small storage on top of that wouldn&#39;t change =
that fact. You gave up the assumption of `sizeof(T)*capacity` when you aske=
d for stability.<br><br>Besides, the point of small storage is not to be ab=
le to predict exactly how big that vector instance will be (the standard wo=
n&#39;t guarantee that anyway). It&#39;s to prevent dynamic allocation outs=
ide of circumstances that would be exceptional for your needs.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">And internally, these vectors=
 may be very very different - so different=20
<br>in fact that the common name and interface would only complicate the=20
<br>implementation by having to dispatch between the different backends.=20
<br>This also means that anyone who needs only one of those backends must=
=20
<br>bring in the other ones as well as dependencies.<br></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>=C2=A0</div></bloc=
kquote><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; See the=
 problem? The multiplicative explosion of vectors makes this
<br>&gt; unworkable. This leaves us either with lots and lots of vector cla=
sses,
<br>&gt; or we only provide the lowest common denominator: `vector`,
<br>&gt; `small_vector`, `static_vector`, `dynamic_vector` and `stable_vect=
or`.
<br>&gt; No combinations of any of those features with each other.
<br>
<br>Well, I&#39;m not convinced that every combination would be useful in=
=20
<br>practice, and that the problem you describe needs solving.
<br>
<br>I guess, if you limit your proposal to only allocation strategies, the=
=20
<br>ones from your list above, it would make more sense. But then I would=
=20
<br>rather see a different design based on allocators, something along thes=
e=20
<br>lines:
<br>
<br>=C2=A0 =C2=A0template&lt; typename T, typename... Allocators =3D std::a=
llocator&lt; T &gt; &gt;
<br>=C2=A0 =C2=A0class multistorage_vector;
<br>
<br>=C2=A0 =C2=A0template&lt; typename T, typename Allocator =3D std::alloc=
ator&lt; T &gt; &gt;
<br>=C2=A0 =C2=A0using vector =3D multistorage_vector&lt; T, Allocator &gt;=
;
<br>
<br>The `multistorage_vector` container would attempt to use storage=20
<br>provided by the first allocator in the `Allocators` list that succeeds.=
=20
<br>This way one would be able to specify first an allocator with a static=
=20
<br>local buffer and then an allocator that uses heap.
<br></blockquote><div><br>That would needlessly bloat the `vector`. After a=
ll, the `vector` still needs its own 3 pointers. So it would have to have i=
ts own storage plus the storage of the allocator.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2c5567a-5ece-486c-855b-156caad4b0fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2c5567a-5ece-486c-855b-156caad4b0fc=
%40isocpp.org</a>.<br />

------=_Part_4525_1493802673.1488125321067--

------=_Part_4524_329792716.1488125321067--

.

On 02/26/17 19:08, Nicol Bolas wrote:
> On Sunday, February 26, 2017 at 10:24:19 AM UTC-5, Andrey Semashev wrote:
>
>     I guess, if you limit your proposal to only allocation strategies, the
>     ones from your list above, it would make more sense. But then I would
>     rather see a different design based on allocators, something along
>     these
>     lines:
>
>        template< typename T, typename... Allocators = std::allocator< T > >
>        class multistorage_vector;
>
>        template< typename T, typename Allocator = std::allocator< T > >
>        using vector = multistorage_vector< T, Allocator >;
>
>     The `multistorage_vector` container would attempt to use storage
>     provided by the first allocator in the `Allocators` list that succeeds.
>     This way one would be able to specify first an allocator with a static
>     local buffer and then an allocator that uses heap.
>
> That would needlessly bloat the `vector`. After all, the `vector` still
> needs its own 3 pointers. So it would have to have its own storage plus
> the storage of the allocator.

I'm not sure there's a way around that. The vector has to have the
members required to obtain begin/end/size/capacity regardless of the
source of the storage. If the storage comes from heap, the local storage
becomes unused, however you implement the 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f3a70e6-0112-7c8e-8d22-aa2d0ddf2905%40gmail.com.

.

------=_Part_647_354021713.1488128777349
Content-Type: multipart/alternative;
 boundary="----=_Part_648_1857871506.1488128777349"

------=_Part_648_1857871506.1488128777349
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Sunday, February 26, 2017 at 8:18:41 PM UTC+8, Daniel Kr=C3=BCgler wrote=
:
>
> 2017-02-26 11:25 GMT+01:00  <inkwizyt...@gmail.com <javascript:>>:=20
> >> What are the other variances that people want?=20
> >=20
> > This could fix problem with `std::vector<bool>`, current vector would=
=20
> be:=20
> > `omni_vector<Typename, ov_compress_bool>` and if you want "normal"=20
> behavior=20
> > you will use directly `omni_vector<bool>`.=20
>
> It is very unlikely that this will happen, because that would break=20
> current valid usages of std::vector as template template parameter.=20
> For exactly that reason (That is: Don't change template parameter=20
> lists of existing Library components), Library implementations are not=20
> allowed to add further template parameters with default parameters,=20
> see=20
>
> http://cplusplus.github.io/LWG/lwg-closed.html#94=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Fl=
wg-closed.html%2394&sa=3DD&sntz=3D1&usg=3DAFQjCNFm-LmwgrlATZR39JTATmh_86RrZ=
A>=20
>
> - Daniel=20
>

P0522R0, resolving Core issue 150, should significantly alleviate the code=
=20
breakage aspect of this problem. But it certainly breaks ABI all over the=
=20
place.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/449d2b1f-5a52-428b-b5d8-54f7c47014bc%40isocpp.or=
g.

------=_Part_648_1857871506.1488128777349
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, February 26, 2017 at 8:18:41 PM UTC+8, =
Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2017=
-02-26 11:25 GMT+01:00 =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"5cAPWymfAgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">inkwizyt...@gmail.com</a>&gt;:
<br>&gt;&gt; What are the other variances that people want?
<br>&gt;
<br>&gt; This could fix problem with `std::vector&lt;bool&gt;`, current vec=
tor would be:
<br>&gt; `omni_vector&lt;Typename, ov_compress_bool&gt;` and if you want &q=
uot;normal&quot; behavior
<br>&gt; you will use directly `omni_vector&lt;bool&gt;`.
<br>
<br>It is very unlikely that this will happen, because that would break
<br>current valid usages of std::vector as template template parameter.
<br>For exactly that reason (That is: Don&#39;t change template parameter
<br>lists of existing Library components), Library implementations are not
<br>allowed to add further template parameters with default parameters,
<br>see
<br>
<br><a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fcplusplus.github.=
io%2FLWG%2Flwg-closed.html%2394&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFm-=
LmwgrlATZR39JTATmh_86RrZA" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcplusplus.=
github.io%2FLWG%2Flwg-closed.html%2394\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNFm-LmwgrlATZR39JTATmh_86RrZA&#39;;return true;" onclick=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%=
2Flwg-closed.html%2394\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFm-LmwgrlATZ=
R39JTATmh_86RrZA&#39;;return true;">http://cplusplus.github.io/<wbr>LWG/lwg=
-closed.html#94</a>
<br>
<br>- Daniel
<br></blockquote><div><br></div>P0522R0, resolving Core issue 150, should s=
ignificantly alleviate the code breakage aspect of this problem. But it cer=
tainly breaks ABI all over the place.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/449d2b1f-5a52-428b-b5d8-54f7c47014bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/449d2b1f-5a52-428b-b5d8-54f7c47014bc=
%40isocpp.org</a>.<br />

------=_Part_648_1857871506.1488128777349--

------=_Part_647_354021713.1488128777349--

.

------=_Part_1060_1292457284.1488230522534
Content-Type: multipart/alternative;
 boundary="----=_Part_1061_1017512527.1488230522534"

------=_Part_1061_1017512527.1488230522534
Content-Type: text/plain; charset=UTF-8

On Saturday, February 25, 2017 at 6:41:01 PM UTC+1, Nicol Bolas wrote:

> What are the other variances that people want?
>

A variant that I find useful is vector optimized for the empty case: the
class contains just one pointer, which is 0 in the empty case, and
otherwise points to a buffer that includes both the regular elements of the
vector and size/capacity. IIRC mozilla also has a container like that (but
limited to POD). I believe that is a valid implementation of std::vector,
no functional difference, so it may be hard to specify such a variant...

For the variants you propose, whenever I've needed them, using
std::vector<T, suitable_allocator> was close to what I needed (they were
local variables so I didn't mind a couple unnecessary pointers), and it
might make sense to try and fix those details (in particular let the
allocator say how much memory it actually allocated, I think there is
already a proposal about it).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046%40isocpp.org.

------=_Part_1061_1017512527.1488230522534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 25, 2017 at 6:41:01 PM UTC+1, Nicol =
Bolas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">What are the other variances that people want?<br></div></blockquote><di=
v><br>A variant that I find useful is vector optimized for the empty case: =
the class contains just one pointer, which is 0 in the empty case, and othe=
rwise points to a buffer that includes both the regular elements of the vec=
tor and size/capacity. IIRC mozilla also has a container like that (but lim=
ited to POD). I believe that is a valid implementation of std::vector, no f=
unctional difference, so it may be hard to specify such a variant...<br><br=
>For the variants you propose, whenever I&#39;ve needed them, using std::ve=
ctor&lt;T, suitable_allocator&gt; was close to what I needed (they were loc=
al variables so I didn&#39;t mind a couple unnecessary pointers), and it mi=
ght make sense to try and fix those details (in particular let the allocato=
r say how much memory it actually allocated, I think there is already a pro=
posal about it).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046=
%40isocpp.org</a>.<br />

------=_Part_1061_1017512527.1488230522534--

------=_Part_1060_1292457284.1488230522534--

.