------=_Part_229_13685758.1364913897738
Content-Type: text/plain; charset=ISO-8859-1

In my personal experience, one of the most common reasons that external
authors have re-invented Standard containers is because they wish to have a
small-data optimization- similar to what is permitted on std::string, but
on other containers as well. I've been considering whether this could be
made a general allocator, but so far, my conclusion is that it would have
to be a partial specialization of the containers, as they only store one
allocator and it's not parameterised on the correct type to know how much
space to allocate within the object.

Any further suggestions on such a thing?

--

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



------=_Part_229_13685758.1364913897738
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In my personal experience, one of the most common reasons that external aut=
hors have re-invented Standard containers is because they wish to have a sm=
all-data optimization- similar to what is permitted on std::string, but on =
other containers as well. I've been considering whether this could be made =
a general allocator, but so far, my conclusion is that it would have to be =
a partial specialization of the containers, as they only store one allocato=
r and it's not parameterised on the correct type to know how much space to =
allocate within the object.<div><br></div><div>Any further suggestions on s=
uch a thing?</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_229_13685758.1364913897738--

.

On Apr 2, 2013, at 10:44 AM, DeadMG <wolfeinstein@gmail.com> wrote:

> In my personal experience, one of the most common reasons that external a=
uthors have re-invented Standard containers is because they wish to have a =
small-data optimization- similar to what is permitted on std::string, but o=
n other containers as well. I've been considering whether this could be mad=
e a general allocator, but so far, my conclusion is that it would have to b=
e a partial specialization of the containers, as they only store one alloca=
tor and it's not parameterised on the correct type to know how much space t=
o allocate within the object.
>=20
> Any further suggestions on such a thing?

http://home.roadrunner.com/~hinnant/stack_alloc.html

Howard

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

--001a11c2a348d4741b04d963eddd
Content-Type: text/plain; charset=ISO-8859-1

On 2 April 2013 09:49, Howard Hinnant <howard.hinnant@gmail.com> wrote:

> On Apr 2, 2013, at 10:44 AM, DeadMG <wolfeinstein@gmail.com> wrote:
>
> > In my personal experience, one of the most common reasons that external
> authors have re-invented Standard containers is because they wish to have a
> small-data optimization- similar to what is permitted on std::string, but
> on other containers as well. I've been considering whether this could be
> made a general allocator, but so far, my conclusion is that it would have
> to be a partial specialization of the containers, as they only store one
> allocator and it's not parameterised on the correct type to know how much
> space to allocate within the object.
> >
> > Any further suggestions on such a thing?
>
> http://home.roadrunner.com/~hinnant/stack_alloc.html
>

But that doesn't embed the data into the vector, which is problematic when
you want to copy/move the vector, because the lifetime of the arena is not
tied to the lifetime of the vector.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



--001a11c2a348d4741b04d963eddd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2 April 2013 09:49, Howard Hinnant <span dir=3D"ltr">&lt;<a href=3D"mail=
to:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnant@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div class=3D"im">On Apr 2, 2013, at 10:44 AM, DeadMG &lt;<a href=3D"mailto=
:wolfeinstein@gmail.com">wolfeinstein@gmail.com</a>&gt; wrote:<br>
<br>
&gt; In my personal experience, one of the most common reasons that externa=
l authors have re-invented Standard containers is because they wish to have=
 a small-data optimization- similar to what is permitted on std::string, bu=
t on other containers as well. I&#39;ve been considering whether this could=
 be made a general allocator, but so far, my conclusion is that it would ha=
ve to be a partial specialization of the containers, as they only store one=
 allocator and it&#39;s not parameterised on the correct type to know how m=
uch space to allocate within the object.<br>


&gt;<br>
&gt; Any further suggestions on such a thing?<br>
<br>
</div><a href=3D"http://home.roadrunner.com/~hinnant/stack_alloc.html" targ=
et=3D"_blank">http://home.roadrunner.com/~hinnant/stack_alloc.html</a><br><=
/blockquote><div><br>But that doesn&#39;t embed the data into the vector, w=
hich is problematic when you want to copy/move the vector, because the life=
time of the arena is not tied to the lifetime of the vector.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2a348d4741b04d963eddd--

.

On Apr 2, 2013, at 1:17 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 2 April 2013 09:49, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> On Apr 2, 2013, at 10:44 AM, DeadMG <wolfeinstein@gmail.com> wrote:
>=20
> > In my personal experience, one of the most common reasons that external=
 authors have re-invented Standard containers is because they wish to have =
a small-data optimization- similar to what is permitted on std::string, but=
 on other containers as well. I've been considering whether this could be m=
ade a general allocator, but so far, my conclusion is that it would have to=
 be a partial specialization of the containers, as they only store one allo=
cator and it's not parameterised on the correct type to know how much space=
 to allocate within the object.
> >
> > Any further suggestions on such a thing?
>=20
> http://home.roadrunner.com/~hinnant/stack_alloc.html
>=20
> But that doesn't embed the data into the vector, which is problematic whe=
n you want to copy/move the vector, because the lifetime of the arena is no=
t tied to the lifetime of the vector.

True.  If you want to move the vector out of the current scope you must pla=
ce the arena such that it is viable from both scopes.

Embedding the arena within the allocator is problematic too.  This makes it=
 difficult to meet the requirement that copies of allocators are equal to e=
ach other (can deallocate each other's pointers).

Interestingly enough, the places I find myself most in need of this type of=
 optimization is when I'm trying to emulate a C99 run-time-sized array.  I =
just need a fast buffer on the local stack, and it "almost always" will hav=
e size <=3D N.  I usually don't need to transfer the buffer out of scope.  =
Or the buffer is embedded in a non-copyable-non-movable object, and so neve=
r gets transferred out of scope.

When the object is going to be moved out of scope, there's a natural and st=
rong tradeoff with move semantics:  The bigger you make the "short buffer",=
 the more expensive the move.  So there's a strong motivation to size the i=
nternal buffer on the short side in that use case.  For example, if I need =
an array of size_t that is going to be moved out of scope, I can't imagine =
wanting to have an internal buffer bigger than a few size_t.  Otherwise the=
 move becomes the expensive part.  Especially if there are many moves, not =
just one (as in a sequence-permuting algorithm).

Yet another way I deal with this problem is to have a raw pointer that eith=
er points to a small C array, or to memory held by a unique_ptr, with the l=
atter only allocated in the rare case it is needed:

void
foo(int n)
{
    size_t small_buf[10];
    size_t* p =3D small_buf;
    std::unique_ptr< size_t[]> big_buf;
    if (n > end(small_buf)-begin(small_buf))
    {
        big_buf.reset(new size_t[n]);
        p =3D big_buf.get();
    }
    // use p[n] here
}

Like the other solutions, this one is only good if you aren't planning on t=
ransferring out of scope.  If you are, it is often best to put the buffer o=
n the heap no matter what its size.

Arrays of char can be a motivating exception to this rule though, because y=
ou can often fit a useful number of char in a relatively small space (e.g. =
libc++ default constructed std::string on a 64 bit machine has capacity =3D=
=3D 22 and sizeof =3D=3D 3 words).

>> In my personal experience, one of the most common reasons that external =
authors have re-invented Standard containers is because they wish to have a=
 small-data optimization

I would be curious to know what the move characteristics of these container=
s are, and how often they are moved (or copied) out of scope.  I think that=
 would be important data to help us determine if there is a general purpose=
 solution that should be standardized.

Howard

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_593_3850936.1364926179314
Content-Type: text/plain; charset=ISO-8859-1

It is not off the local stack, it is embedded within the container- exactly
how the existing std::string small string optimization functions.

I would be curious to know what the move characteristics of these
> containers are, and how often they are moved (or copied) out of scope.


Copying isn't really an issue. The move and swap characteristics are the
issue, as they do not retain iterators/pointers/references in this case,
unlike in other cases. In my experience, it is common for them to inherit
from a base class which is type-erased over the "small" size, permitting
references to any derived class, making copies rare- if they are even
copyable in the first place. It could instead be implemented by mandating
SCARY iterators, which I feel to be the superior solution.

Ultimately, the Standard already recognizes the need for this optimization
for std::basic_string, it's simply a question of generalizing it for the
other containers and permitting the user to set the value. It is
unfortunate that the existing allocator system is not sufficiently flexible
to deal with this.

--

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



------=_Part_593_3850936.1364926179314
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is not off the local stack, it is embedded within the container- exactly=
 how the existing std::string small string optimization functions.<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;">I would be curious to know what the move=
 characteristics of these containers are, and how often they are moved (or =
copied) out of scope.</blockquote><div><br></div><div>Copying isn't really =
an issue. The move and swap characteristics are the issue, as they do not r=
etain iterators/pointers/references in this case, unlike in other cases. In=
 my experience, it is common for them to inherit from a base class which is=
 type-erased over the "small" size, permitting references to any derived cl=
ass, making copies rare- if they are even copyable in the first place. It c=
ould instead be implemented by mandating SCARY iterators, which I feel to b=
e the superior solution.</div><div><br></div><div>Ultimately, the Standard =
already recognizes the need for this optimization for std::basic_string, it=
's simply a question of generalizing it for the other containers and permit=
ting the user to set the value. It is unfortunate that the existing allocat=
or system is not sufficiently flexible to deal with this.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_593_3850936.1364926179314--

.

On Apr 2, 2013, at 2:09 PM, DeadMG <wolfeinstein@gmail.com> wrote:

> It is not off the local stack, it is embedded within the container- exact=
ly how the existing std::string small string optimization functions.
>=20
>> I would be curious to know what the move characteristics of these contai=
ners are, and how often they are moved (or copied) out of scope.
>>=20
> Copying isn't really an issue. The move and swap characteristics are the =
issue, as they do not retain iterators/pointers/references in this case, un=
like in other cases. In my experience, it is common for them to inherit fro=
m a base class which is type-erased over the "small" size, permitting refer=
ences to any derived class, making copies rare- if they are even copyable i=
n the first place. It could instead be implemented by mandating SCARY itera=
tors, which I feel to be the superior solution.
>=20
> Ultimately, the Standard already recognizes the need for this optimizatio=
n for std::basic_string, it's simply a question of generalizing it for the =
other containers and permitting the user to set the value. It is unfortunat=
e that the existing allocator system is not sufficiently flexible to deal w=
ith this.

I'm afraid I obscured my point:

This is a completely desirable optimization for std::string (because I can =
move strings with an internal buffer of up to 10 or 20 char pretty fast).  =
libc++ moves such a string by moving only 3 words.

This is a completely undesirable optimization for std::map<std::string, std=
::string>, *unless* the use case for the map is to never be moved out of sc=
ope.  This is because of the significant expense of moving an internal buff=
er that held as little as one element.  libc++ would have to move at least =
10 words just to move such a container with only a 1 element internal buffe=
r.  And a map with only 1 element is lot less useful than a string with 20 =
char.  If the map had a mere 20 element buffer, we're looking at moving at =
least 200 words to move the container.  Today libc++ moves a std::map<std::=
string, std::string> (of any size()) by moving only 3 words.  This is 3 tim=
es faster than moving 10 words and well over 60 times faster than moving 20=
0 words.

There is a large grey area between std::string and std::map<std::string, st=
d::string>.  And I don't claim to know where to draw the line about when th=
is is a worthwhile optimization.  But drawing it just around basic_string i=
s at the very least not entirely unreasonable.

This is why:

> I would be curious to know what the move characteristics of these contain=
ers are, and how often they are moved (or copied) out of scope.

If the use-cases of these 3rd party containers are that they are never move=
d out of scope, then custom allocators do this optimization today, with no =
need to standardize another library of containers.

If the use-cases of these 3rd party containers are that they are often move=
d out of scope, I question the effectiveness of the optimization, and am cu=
rious how big their internal buffers are, and how expensive it is to move s=
uch containers.  Naturally if their containers were designed prior to the i=
ntroduction of move semantics, they would only have to compete with the per=
formance of copying.  But today they need to compete with the performance o=
f moving.

3rd party authors may continue to write custom containers of course.  But i=
mho they would be smarter to write custom allocators and gain from code reu=
se of the existing std::containers.

Howard

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_3536_23205193.1364950763037
Content-Type: text/plain; charset=ISO-8859-1

There are other considerations as well, such as locality- the in-place
additions do not require additional indirections to be accessed, and in the
case of something like a map or set, then flattening the data holds lots of
cache advantages. In addition, your cost of moving 200 words sounds high-
although, given the vectorized implementations of memcpy around today, I
suspect that it would not be substantial. But more significantly, I expect
that the cost of dynamically allocating those objects from the heap would
be higher, especially if there are many erasures and insertions.

 If the map had a mere 20 element buffer


This is generally far larger than the size at which people look for this
feature. In addition, you're usually talking about smaller elements like
pointer types. Particularly, I can say that in my own codebase, at least, I
would look for maybe 2 or 3 as the stored buffer size in the most common
cases. A heap allocation to store 2 objects, whose size is only 2 words
each, is a total waste. The default setting I have seen in some other
codebases are values like 8. And some containers like std::vector would not
suffer anywhere near so much memory requirement as the std::map.

The fact that it is not ideal for every use case is immaterial. The user
can make a well-informed choice about whether or not his specific
requirements are a good fit. The important points are:

   - Don't pay for what you don't use- if you don't use the feature, you
   don't pay any cost.
   - The use case this feature is intended to address exists and cannot be
   addressed by any existing Standard mechanism, beyond replacing the Standard
   Library.
   - The proposed feature meets that need.

--

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



------=_Part_3536_23205193.1364950763037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There are other considerations as well, such as locality- the in-place addi=
tions do not require additional indirections to be accessed, and in the cas=
e of something like a map or set, then flattening the data holds lots of ca=
che advantages. In addition, your cost of moving 200 words sounds high- alt=
hough, given the vectorized implementations of memcpy around today, I suspe=
ct that it would not be substantial. But more significantly, I expect that =
the cost of dynamically allocating those objects from the heap would be hig=
her, especially if there are many erasures and insertions.<div><br></div><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;">&nbsp;If the map had a mere 20 element buff=
er</blockquote><div><br></div><div>This is generally far larger than the si=
ze at which people look for this feature. In addition, you're usually talki=
ng about smaller elements like pointer types. Particularly, I can say that =
in my own codebase, at least, I would look for maybe 2 or 3 as the stored b=
uffer size in the most common cases.&nbsp;A heap allocation to store 2 obje=
cts, whose size is only 2 words each, is a total waste.&nbsp;The default se=
tting I have seen in some other codebases are values like 8. And some conta=
iners like std::vector would not suffer anywhere near so much memory requir=
ement as the std::map.</div></div><div><br></div><div>The fact that it is n=
ot ideal for every use case is immaterial. The user can make a well-informe=
d choice about whether or not his specific requirements are a good fit. The=
 important points are:</div><div><ul><li><span style=3D"line-height: normal=
;">Don't pay for what you don't use- if you don't use the feature, you don'=
t pay any cost.</span></li><li><span style=3D"line-height: normal;">The use=
 case this feature is intended to address </span><span style=3D"line-height=
: normal;">exists and cannot be addressed by any existing Standard mechanis=
m, beyond replacing the Standard Library.</span></li><li><span style=3D"lin=
e-height: normal;">The proposed feature meets that need.</span></li></ul></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3536_23205193.1364950763037--

.

------=_Part_3163_29295805.1364951290251
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, April 2, 2013 5:59:22 PM UTC-7, DeadMG wrote:
>
> There are other considerations as well, such as locality- the in-place
> additions do not require additional indirections to be accessed, and in the
> case of something like a map or set, then flattening the data holds lots of
> cache advantages. In addition, your cost of moving 200 words sounds high-
> although, given the vectorized implementations of memcpy around today, I
> suspect that it would not be substantial. But more significantly, I expect
> that the cost of dynamically allocating those objects from the heap would
> be higher, especially if there are many erasures and insertions.
>
>  If the map had a mere 20 element buffer
>
>
> This is generally far larger than the size at which people look for this
> feature. In addition, you're usually talking about smaller elements like
> pointer types. Particularly, I can say that in my own codebase, at least, I
> would look for maybe 2 or 3 as the stored buffer size in the most common
> cases. A heap allocation to store 2 objects, whose size is only 2 words
> each, is a total waste. The default setting I have seen in some other
> codebases are values like 8. And some containers like std::vector would not
> suffer anywhere near so much memory requirement as the std::map.
>
> The fact that it is not ideal for every use case is immaterial. The user
> can make a well-informed choice about whether or not his specific
> requirements are a good fit. The important points are:
>
>    - Don't pay for what you don't use- if you don't use the feature, you
>    don't pay any cost.
>    - The use case this feature is intended to address exists and cannot
>    be addressed by any existing Standard mechanism, beyond replacing the
>    Standard Library.
>    - The proposed feature meets that need.
>
> It's not like standardizing things is *free*. There's a cost to adding
anything to the standard: time the committee spends discussing it is time
they're not spending on other things.

Stuff in the *standard* should be *generally* useful. Special-case code is
special-case, and we shouldn't have really special cases in the standard.
Things like `flat_map` and such are far more generally useful than this.

Yes, the use case exists. But is it important enough, affecting enough
users to warrant the effort of standardizing something? Or more to the
point, if Boost doesn't even have one of these in their special containers
(which include more generally useful `flat_map` and the like), if there are
no other libraries that provide this functionality... why should the
standard? Obviously the use case doesn't affect enough people for there to
be a public library available that handles it.

As far as the suggested implementation, I wouldn't want it to be an
allocator trick or something. You're talking about changing the very
definition of how a class operates. You're saying that I can no longer rely
on O(1) moves from std::vector. That's not acceptable.

Yes, you can use partial specialization based on some allocator type, but I
would much rather see such classes as specialized classes with different
expected behavior and different *names*. We've already seen what happens
when you try to use partial specialization to create new functionality (see
`vector<bool>`); it's not a good thing.

--

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



------=_Part_3163_29295805.1364951290251
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 2, 2013 5:59:22 PM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">There are other considerations as well, such as=
 locality- the in-place additions do not require additional indirections to=
 be accessed, and in the case of something like a map or set, then flatteni=
ng the data holds lots of cache advantages. In addition, your cost of movin=
g 200 words sounds high- although, given the vectorized implementations of =
memcpy around today, I suspect that it would not be substantial. But more s=
ignificantly, I expect that the cost of dynamically allocating those object=
s from the heap would be higher, especially if there are many erasures and =
insertions.<div><br></div><div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex">&nbsp;If the map had a mere=
 20 element buffer</blockquote><div><br></div><div>This is generally far la=
rger than the size at which people look for this feature. In addition, you'=
re usually talking about smaller elements like pointer types. Particularly,=
 I can say that in my own codebase, at least, I would look for maybe 2 or 3=
 as the stored buffer size in the most common cases.&nbsp;A heap allocation=
 to store 2 objects, whose size is only 2 words each, is a total waste.&nbs=
p;The default setting I have seen in some other codebases are values like 8=
.. And some containers like std::vector would not suffer anywhere near so mu=
ch memory requirement as the std::map.</div></div><div><br></div><div>The f=
act that it is not ideal for every use case is immaterial. The user can mak=
e a well-informed choice about whether or not his specific requirements are=
 a good fit. The important points are:</div><div><ul><li><span style=3D"lin=
e-height:normal">Don't pay for what you don't use- if you don't use the fea=
ture, you don't pay any cost.</span></li><li><span style=3D"line-height:nor=
mal">The use case this feature is intended to address </span><span style=3D=
"line-height:normal">exists and cannot be addressed by any existing Standar=
d mechanism, beyond replacing the Standard Library.</span></li><li><span st=
yle=3D"line-height:normal">The proposed feature meets that need.</span></li=
></ul></div></blockquote><div>It's not like standardizing things is <i>free=
</i>. There's a cost to adding anything to the standard: time the committee=
 spends discussing it is time they're not spending on other things.<br><br>=
Stuff in the <i>standard</i> should be <i>generally</i> useful. Special-cas=
e code is special-case, and we shouldn't have really special cases in the s=
tandard. Things like `flat_map` and such are far more generally useful than=
 this.<br><br>Yes, the use case exists. But is it important enough, affecti=
ng enough users to warrant the effort of standardizing something? Or more t=
o the point, if Boost doesn't even have one of these in their special conta=
iners (which include more generally useful `flat_map` and the like), if the=
re are no other libraries that provide this functionality... why should the=
 standard? Obviously the use case doesn't affect enough people for there to=
 be a public library available that handles it.<br><br>As far as the sugges=
ted implementation, I wouldn't want it to be an allocator trick or somethin=
g. You're talking about changing the very definition of how a class operate=
s. You're saying that I can no longer rely on O(1) moves from std::vector. =
That's not acceptable.<br><br>Yes, you can use partial specialization based=
 on some allocator type, but I would much rather see such classes as specia=
lized classes with different expected behavior and different <i>names</i>. =
We've already seen what happens when you try to use partial specialization =
to create new functionality (see `vector&lt;bool&gt;`); it's not a good thi=
ng.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3163_29295805.1364951290251--

.

------=_Part_5888_2624995.1364980177714
Content-Type: text/plain; charset=ISO-8859-1

I have long been wanting a vector with a "small-vector-optimization", in
the end I don't think it's nearly as useful as I once thought.

Howard's point about the increased cost of moving is valid, but in my case
I wanted it mostly for classes with value-semantics, they'd be copied
around much more often than moved. In one class I saved millions of little
allocs by using a std::array<int> (instead of vector<int>) that would be
large enough for all my cases (with some room to spare, in my case 11; 7
would have been good enough for 99% of my cases), it would have been my
primary case for a small vector to do this without wasting that much space
(and having a hard limit). But using a small vector my class would also not
be trivially copyable/moveable anymore, so while it would waste less
memory, performance (in my case) would definitely get hit. Impossible to
say by how much without profiling, it would probably even itself out enough
to not matter.

Since you brought up flat_map: I am using Loki::AssocVector (same thing)
and my other use-case for a small vector is a mapping char->string with
very few entries (usually just 2). Here a flat_map with small vector
optimization would be perfect, no doubt about it, it would save a lot of
memory allocations. But from all the containers I have ever used this is
the only one where I can say that, in all other cases I would have to
profile and that means that the usefulness of it is not general but is
different for each use-case.

Some time ago I noticed LLVMs SmallVector
(http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVector.html) which is
exactly what I wanted, but faced with actually putting work into it I
thought long and hard where I could possibly use it and what gains I can
reasonably expect; it's still on my list to test "someday", but I am in no
hurry. For me it would be something nice to have but there are more
important things that should come first.

I agree with Nicol, a flat_map is incredibly useful in a lot of places (why
isn't something like it in the standard?), a small vector optimization by
comparison sounds really nice but is too specialised.

--

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



------=_Part_5888_2624995.1364980177714
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have long been wanting a vector with a "small-vector-optimization", in th=
e end I don't think it's nearly as useful as I once thought.<div><br></div>=
<div>Howard's point about the increased cost of moving is valid, but in my =
case I wanted it mostly for classes with value-semantics, they'd be copied =
around much more often than moved. In one class I saved millions of little =
allocs by using a std::array&lt;int&gt; (instead of vector&lt;int&gt;) that=
 would be large enough for all my cases (with some room to spare, in my cas=
e 11; 7 would have been good enough for 99% of my cases), it would have bee=
n my primary case for a small vector to do this without wasting that much s=
pace (and having a hard limit). But using a small vector my class would als=
o not be trivially copyable/moveable anymore, so while it would waste less =
memory, performance (in my case) would definitely get hit. Impossible to sa=
y by how much without profiling, it would probably even itself out enough t=
o not matter.</div><div><br></div><div>Since you brought up flat_map: I am =
using Loki::AssocVector (same thing) and my other use-case for a small vect=
or is a mapping char-&gt;string with very few entries (usually just 2). Her=
e a flat_map with small vector optimization would be perfect, no doubt abou=
t it, it would save a lot of memory allocations. But from all the container=
s I have ever used this is the only one where I can say that, in all other =
cases I would have to profile and that means that the usefulness of it is n=
ot general but is different for each use-case.</div><div><br></div><div>Som=
e time ago I noticed LLVMs SmallVector (http://llvm.org/docs/doxygen/html/c=
lassllvm_1_1SmallVector.html) which is exactly what I wanted, but faced wit=
h actually putting work into it I thought long and hard where I could possi=
bly use it and what gains I can reasonably expect; it's still on my list to=
 test "someday", but I am in no hurry. For me it would be something nice to=
 have but there are more important things that should come first.</div><div=
><br></div><div>I agree with Nicol, a flat_map is incredibly useful in a lo=
t of places (why isn't something like it in the standard?), a small vector =
optimization by comparison sounds really nice but is too specialised.</div>=
<div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5888_2624995.1364980177714--

.

--047d7b621b142f27a004d9714cf5
Content-Type: text/plain; charset=ISO-8859-1

Can boost pool library help?
http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/index.html

--

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



--047d7b621b142f27a004d9714cf5
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">Can boost pool library help?<br><a href="http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/index.html">http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/index.html</a></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b621b142f27a004d9714cf5--

.

------=_Part_4703_28147505.1364983848685
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, April 3, 2013 2:09:37 AM UTC-7, dixl...@gmail.com wrote:
>
> I agree with Nicol, a flat_map is incredibly useful in a lot of places
> (why isn't something like it in the standard?)
>

Because nobody has proposed it for standardization.

--

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



------=_Part_4703_28147505.1364983848685
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 3, 2013 2:09:37 AM UTC-7, dixl...@gmail.com 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></div><div>I agree with Nicol,=
 a flat_map is incredibly useful in a lot of places (why isn't something li=
ke it in the standard?)</div></blockquote><div><br>Because nobody has propo=
sed it for standardization. <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4703_28147505.1364983848685--

.

------=_Part_4432_20700611.1364985876957
Content-Type: text/plain; charset=ISO-8859-1


>
> It's not like standardizing things is *free*. There's a cost to adding
> anything to the standard: time the committee spends discussing it is time
> they're not spending on other things.


I absolutely agree. But that's why I'm discussing it here before Bristol :P


> Stuff in the *standard* should be *generally* useful. Special-case code
> is special-case, and we shouldn't have really special cases in the
> standard. Things like `flat_map` and such are far more generally useful
> than this.
>
> Yes, the use case exists. But is it important enough, affecting enough
> users to warrant the effort of standardizing something? Or more to the
> point, if Boost doesn't even have one of these in their special containers
> (which include more generally useful `flat_map` and the like), if there are
> no other libraries that provide this functionality... why should the
> standard? Obviously the use case doesn't affect enough people for there to
> be a public library available that handles it.
>

There are *many* useful libraries not in Boost. A simple example of
necessary functionality which isn't really offered by Boost is Unicode
support, or a decent concurrency library. The simple fact is that what
Boost libraries are available are effectively determined by who could be
bothered to create one. If I wished to go through the process I could
author one myself and place it in Boost. If the kind of people who find
themselves needing a class are not the kind of people who accept their
codebase depending on Boost, they have no reason to submit it.


> As far as the suggested implementation, I wouldn't want it to be an
> allocator trick or something. You're talking about changing the very
> definition of how a class operates. You're saying that I can no longer rely
> on O(1) moves from std::vector. That's not acceptable.
>
> Yes, you can use partial specialization based on some allocator type, but
> I would much rather see such classes as specialized classes with different
> expected behavior and different *names*. We've already seen what happens
> when you try to use partial specialization to create new functionality (see
> `vector<bool>`); it's not a good thing.
>

That's not the same. Using a small allocator or not is a tradeoff one way
or another, which I would grant to the user a choice as to which they want.
vector<bool> is also a tradeoff, except the decision is forced on you, and
it's also implicit. You have to explicitly ask for a small allocator, so
you should know what it is that you are getting. The only reason to pass a
small_allocator as the allocator is because *you explicitly desire this
behaviour*. It is totally unlike vector<bool>.

 You're saying that I can no longer rely on O(1) moves from std::vector.
> That's not acceptable.


Actually, it is still O(1), since the "small" size is capped at
compile-time. But secondly, as I said to Howard, if you make a really large
buffer and you repeatedly move it then that's obviously not going to
produce a performance win, and this isn't a concern for me. The small is
intended for only a, well, small number of elements, where the cost of
dynamic allocation far outweighs the cost of moving a couple of extra
bytes.

--

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



------=_Part_4432_20700611.1364985876957
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">It's not like standardizing things is <i>free<=
/i>. There's a cost to adding anything to the standard: time the committee =
spends discussing it is time they're not spending on other things.</blockqu=
ote><div><br></div><div>I absolutely agree. But that's why I'm discussing i=
t here before Bristol :P</div><div>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div>Stuff in the <i>standard</i> should be <i>generally</=
i> useful. Special-case code is special-case, and we shouldn't have really =
special cases in the standard. Things like `flat_map` and such are far more=
 generally useful than this.<br><br>Yes, the use case exists. But is it imp=
ortant enough, affecting enough users to warrant the effort of standardizin=
g something? Or more to the point, if Boost doesn't even have one of these =
in their special containers (which include more generally useful `flat_map`=
 and the like), if there are no other libraries that provide this functiona=
lity... why should the standard? Obviously the use case doesn't affect enou=
gh people for there to be a public library available that handles it.<br></=
div></blockquote><div><br></div><div>There are *many* useful libraries not =
in Boost. A simple example of necessary functionality which isn't really of=
fered by Boost is Unicode support, or a decent concurrency library. The sim=
ple fact is that what Boost libraries are available are effectively determi=
ned by who could be bothered to create one. If I wished to go through the p=
rocess I could author one myself and place it in Boost. If the kind of peop=
le who find themselves needing a class are not the kind of people who accep=
t their codebase depending on Boost, they have no reason to submit it.</div=
><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>As far =
as the suggested implementation, I wouldn't want it to be an allocator tric=
k or something. You're talking about changing the very definition of how a =
class operates. You're saying that I can no longer rely on O(1) moves from =
std::vector. That's not acceptable.<br><br>Yes, you can use partial special=
ization based on some allocator type, but I would much rather see such clas=
ses as specialized classes with different expected behavior and different <=
i>names</i>. We've already seen what happens when you try to use partial sp=
ecialization to create new functionality (see `vector&lt;bool&gt;`); it's n=
ot a good thing.<br></div></blockquote><div><br></div><div>That's not the s=
ame. Using a small allocator or not is a tradeoff one way or another, which=
 I would grant to the user a choice as to which they want. vector&lt;bool&g=
t; is also a tradeoff, except the decision is forced on you, and it's also =
implicit. You have to explicitly ask for a small allocator, so you should k=
now what it is that you are getting. The only reason to pass a small_alloca=
tor as the allocator is because *you explicitly desire this behaviour*. It =
is totally unlike vector&lt;bool&gt;.&nbsp;</div><div><br></div><blockquote=
 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; pa=
dding-left: 1ex;">&nbsp;You're saying that I can no longer rely on O(1) mov=
es from std::vector. That's not acceptable.</blockquote><div><br></div><div=
>Actually, it is still O(1), since the "small" size is capped at compile-ti=
me. But secondly, as I said to Howard, if you make a really large buffer an=
d you repeatedly move it then that's obviously not going to produce a perfo=
rmance win, and this isn't a concern for me. The small is intended for only=
 a, well, small number of elements, where the cost of dynamic allocation fa=
r outweighs the cost of moving a couple of extra bytes.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4432_20700611.1364985876957--

.

------=_Part_387_17402440.1365035827600
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, April 3, 2013 3:44:36 AM UTC-7, DeadMG wrote:
>
> Stuff in the *standard* should be *generally* useful. Special-case code
>> is special-case, and we shouldn't have really special cases in the
>> standard. Things like `flat_map` and such are far more generally useful
>> than this.
>>
>> Yes, the use case exists. But is it important enough, affecting enough
>> users to warrant the effort of standardizing something? Or more to the
>> point, if Boost doesn't even have one of these in their special containers
>> (which include more generally useful `flat_map` and the like), if there are
>> no other libraries that provide this functionality... why should the
>> standard? Obviously the use case doesn't affect enough people for there to
>> be a public library available that handles it.
>>
>
> There are *many* useful libraries not in Boost. A simple example of
> necessary functionality which isn't really offered by Boost is Unicode
> support, or a decent concurrency library. The simple fact is that what
> Boost libraries are available are effectively determined by who could be
> bothered to create one. If I wished to go through the process I could
> author one myself and place it in Boost. If the kind of people who find
> themselves needing a class are not the kind of people who accept their
> codebase depending on Boost, they have no reason to submit it.
>

The difference being of course that there *are* libraries that provide
Unicode support. As I said, "if there are no other libraries that provide
this functionality... why should the standard?" If nobody is bothered
enough by not having this functionality to actually implement it in some
way, then it's probably not a significant enough problem.

--

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



------=_Part_387_17402440.1365035827600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, April 3, 2013 3:44:36 AM UTC-7, DeadMG wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div>Stuff in the <i>standard</i> should be <i>generally</i> useful. Spec=
ial-case code is special-case, and we shouldn't have really special cases i=
n the standard. Things like `flat_map` and such are far more generally usef=
ul than this.<br><br>Yes, the use case exists. But is it important enough, =
affecting enough users to warrant the effort of standardizing something? Or=
 more to the point, if Boost doesn't even have one of these in their specia=
l containers (which include more generally useful `flat_map` and the like),=
 if there are no other libraries that provide this functionality... why sho=
uld the standard? Obviously the use case doesn't affect enough people for t=
here to be a public library available that handles it.<br></div></blockquot=
e><div><br></div><div>There are *many* useful libraries not in Boost. A sim=
ple example of necessary functionality which isn't really offered by Boost =
is Unicode support, or a decent concurrency library. The simple fact is tha=
t what Boost libraries are available are effectively determined by who coul=
d be bothered to create one. If I wished to go through the process I could =
author one myself and place it in Boost. If the kind of people who find the=
mselves needing a class are not the kind of people who accept their codebas=
e depending on Boost, they have no reason to submit it.</div></blockquote><=
div><br>The difference being of course that there <i>are</i> libraries that=
 provide Unicode support. As I said, "if there are no other libraries that =
provide this functionality... why should the standard?" If nobody is bother=
ed enough by not having this functionality to actually implement it in some=
 way, then it's probably not a significant enough problem.</div><br>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_387_17402440.1365035827600--

.

--047d7b6775aaef004704d97e8a9a
Content-Type: text/plain; charset=ISO-8859-1

On 3 April 2013 19:37, Nicol Bolas <jmckesson@gmail.com> wrote:

> As I said, "if there are no other libraries that provide this
> functionality... why should the standard?" If nobody is bothered enough by
> not having this functionality to actually implement it in some way, then
> it's probably not a significant enough problem.
>

Are you sure you want us to use that as the criterion for all proposals?

In another thread, you wrote:

>But I want to make this note: if the make_unique taking a `default_init`
parameter goes through, can we please get that into standard library
containers too?

What widely available library uses default_init?  I don't remember seeing
it in Boost, and it isn't like this can't be solved in 99% of the use cases
by just changing the allocator.


The Committee does weigh implementation experience when deciding what to
standardize.

The rules are simple:  write a proposal, come to a meeting to present it
(or find a champion), and we will consider it.  If you wish to change those
rules, bring it up in person (or find a champion) at Bristol.


Back to the subject at hand, a vector-like container with the small object
optimization has been proposed a number of times on the Boost list; I do
not know the status of the current crop of developers trying to implement
it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



--047d7b6775aaef004704d97e8a9a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 3 April 2013 19:37, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>As I said, &quot;if there are no other libraries that=
 provide this functionality... why should the standard?&quot; If nobody is =
bothered enough by not having this functionality to actually implement it i=
n some way, then it&#39;s probably not a significant enough problem.</div>

</blockquote><div><br></div><div style>Are you sure you want us to use that=
 as the criterion for all proposals?</div><div style><br></div><div style>I=
n another thread, you wrote:</div><div style><br></div><div style><span sty=
le=3D"font-family:arial,sans-serif;font-size:13px">&gt;But I want to make t=
his note: if the make_unique taking a `</span><span class=3D"" style=3D"fon=
t-family:arial,sans-serif;font-size:13px">default_init</span><span style=3D=
"font-family:arial,sans-serif;font-size:13px">` parameter goes through, can=
 we please get that into standard library containers too?</span></div>

<div style><br></div><div style>What widely available library uses default_=
init? =A0I don&#39;t remember seeing it in Boost, and it isn&#39;t like thi=
s can&#39;t be solved in 99% of the use cases by just changing the allocato=
r.=A0</div>

<div style><br></div><div style><br></div><div style><div>The Committee doe=
s weigh implementation experience when deciding what to standardize.</div><=
div><br></div><div><div>The rules are simple: =A0write a proposal, come to =
a meeting to present it (or find a champion), and we will consider it. =A0I=
f you wish to change those rules, bring it up in person (or find a champion=
) at Bristol.</div>

</div></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra"><br></div>Back to the subject at hand, a vector-like container with =
the small object optimization=A0has been proposed a number of times on the =
Boost list; I do not know the status of the current crop of developers tryi=
ng to implement it.</div>

<div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:=
nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0=
 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6775aaef004704d97e8a9a--

.

------=_Part_541_20595438.1365049717990
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, April 3, 2013 6:03:05 PM UTC-7, Nevin ":-)" Liber wrote:
>
>
> On 3 April 2013 19:37, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>> As I said, "if there are no other libraries that provide this
>> functionality... why should the standard?" If nobody is bothered enough by
>> not having this functionality to actually implement it in some way, then
>> it's probably not a significant enough problem.
>>
>
> Are you sure you want us to use that as the criterion for all proposals?
>
> In another thread, you wrote:
>
> >But I want to make this note: if the make_unique taking a `default_init`
> parameter goes through, can we please get that into standard library
> containers too?
>
> What widely available library uses default_init?  I don't remember seeing
> it in Boost, and it isn't like this can't be solved in 99% of the use cases
> by just changing the allocator.
>

I don't recall predicating the library on being "widely available". Also, I
wasn't suggesting that it be made "the criterion for all proposals". My
point is that the lack of such a library suggests that it's not something
that a lot of people need.

We're not talking about something unusual here; there have been *numerous*variations of `vector`. Some
let you define a fixed maximum size <https://github.com/take-cheeze/EASTL>. Some
of them <http://qt-project.org/doc/qt-4.8/qvector.html> default-construct
empty elements instead of value-constructing them (so your attempt to be
clever fails). And so on. Just about every framework has its own dynamic
array with its own special behavior.

And yet, I have yet to see a version of `vector` that does what is being
asked for here. I'm not saying that it doesn't exist. But with all of these
variations of the concept of a `vector`, if a small-size optimized vector
was something people wanted, you would think that we'd have seen one by 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 http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_541_20595438.1365049717990
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, April 3, 2013 6:03:05 PM UTC-7, Nevin ":-)" Liber wro=
te:<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><br><=
div class=3D"gmail_quote">On 3 April 2013 19:37, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
-QrjXnimSXsJ">jmck...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>As I said, "if there are no other libraries that prov=
ide this functionality... why should the standard?" If nobody is bothered e=
nough by not having this functionality to actually implement it in some way=
, then it's probably not a significant enough problem.</div>

</blockquote><div><br></div><div>Are you sure you want us to use that as th=
e criterion for all proposals?</div><div><br></div><div>In another thread, =
you wrote:</div><div><br></div><div><span style=3D"font-family:arial,sans-s=
erif;font-size:13px">&gt;But I want to make this note: if the make_unique t=
aking a `</span><span style=3D"font-family:arial,sans-serif;font-size:13px"=
>default_init</span><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">` parameter goes through, can we please get that into standard library=
 containers too?</span></div>

<div><br></div><div>What widely available library uses default_init? &nbsp;=
I don't remember seeing it in Boost, and it isn't like this can't be solved=
 in 99% of the use cases by just changing the allocator.</div></div></div><=
/div></blockquote><div><br>I don't recall predicating the library on being =
"widely available". Also, I wasn't suggesting that it be made "the criterio=
n for all proposals". My point is that the lack of such a library suggests =
that it's not something that a lot of people need.<br><br>We're not talking=
 about something unusual here; there have been <i>numerous</i> variations o=
f `vector`. <a href=3D"https://github.com/take-cheeze/EASTL">Some let you d=
efine a fixed maximum size</a>. <a href=3D"http://qt-project.org/doc/qt-4.8=
/qvector.html">Some of them</a> default-construct empty elements instead of=
 value-constructing them (so your attempt to be clever fails). And so on. J=
ust about every framework has its own dynamic array with its own special be=
havior.<br><br>And yet, I have yet to see a version of `vector` that does w=
hat is being asked for here. I'm not saying that it doesn't exist. But with=
 all of these variations of the concept of a `vector`, if a small-size opti=
mized vector was something people wanted, you would think that we'd have se=
en one by now.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_541_20595438.1365049717990--

.

--047d7b6775aa13f9d704d981e21f
Content-Type: text/plain; charset=ISO-8859-1

On 3 April 2013 23:28, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Wednesday, April 3, 2013 6:03:05 PM UTC-7, Nevin ":-)" Liber wrote:
>
>>
>> On 3 April 2013 19:37, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> As I said, "if there are no other libraries that provide this
>>> functionality... why should the standard?" If nobody is bothered enough by
>>> not having this functionality to actually implement it in some way, then
>>> it's probably not a significant enough problem.
>>>
>>
>> Are you sure you want us to use that as the criterion for all proposals?
>>
>> In another thread, you wrote:
>>
>> >But I want to make this note: if the make_unique taking a `default_init`
>> parameter goes through, can we please get that into standard library
>> containers too?
>>
>> What widely available library uses default_init?  I don't remember seeing
>> it in Boost, and it isn't like this can't be solved in 99% of the use cases
>> by just changing the allocator.
>>
>
> I don't recall predicating the library on being "widely available".
>

So, what existing library is it in??


>  Also, I wasn't suggesting that it be made "the criterion for all
> proposals". My point is that the lack of such a library suggests that it's
> not something that a lot of people need.
>

Again, what existing library do I find default_init in??


>
> Some of them <http://qt-project.org/doc/qt-4.8/qvector.html>default-construct empty elements instead of value-constructing them (so
> your attempt to be clever fails).
>

I can do that *now* with an allocator.  The only case that default_init
covers that changing the allocator doesn't is when one wants to allow both
in the same container.  How common is *that* case?


> And yet, I have yet to see a version of `vector` that does what is being
> asked for here. I'm not saying that it doesn't exist. But with all of these
> variations of the concept of a `vector`, if a small-size optimized vector
> was something people wanted, you would think that we'd have seen one by now.
>
> Same argument seems to apply to default_init...


Like I said, the Committee weighs implementation experience, but does not
dismiss the lack of it out of hand.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



--047d7b6775aa13f9d704d981e21f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 3 April 2013 23:28, Nicol Bo=
las <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"=
_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">

<br><br>On Wednesday, April 3, 2013 6:03:05 PM UTC-7, Nevin &quot;:-)&quot;=
 Liber wrote:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">

<div><br><div class=3D"gmail_quote">On 3 April 2013 19:37, Nicol Bolas <spa=
n dir=3D"ltr">&lt;<a>jmck...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>As I said, &quot;if there are no other libraries that=
 provide this functionality... why should the standard?&quot; If nobody is =
bothered enough by not having this functionality to actually implement it i=
n some way, then it&#39;s probably not a significant enough problem.</div>



</blockquote><div><br></div><div>Are you sure you want us to use that as th=
e criterion for all proposals?</div><div><br></div><div>In another thread, =
you wrote:</div><div><br></div><div><span style=3D"font-family:arial,sans-s=
erif;font-size:13px">&gt;But I want to make this note: if the make_unique t=
aking a `</span><span style=3D"font-family:arial,sans-serif;font-size:13px"=
>default_init</span><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">` parameter goes through, can we please get that into standard library=
 containers too?</span></div>



<div><br></div><div>What widely available library uses default_init? =A0I d=
on&#39;t remember seeing it in Boost, and it isn&#39;t like this can&#39;t =
be solved in 99% of the use cases by just changing the allocator.</div></di=
v>

</div></div></blockquote></div><div><br>I don&#39;t recall predicating the =
library on being &quot;widely available&quot;.</div></blockquote><div>=A0</=
div><div>So, what existing library is it in??</div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

<div> Also, I wasn&#39;t suggesting that it be made &quot;the criterion for=
 all proposals&quot;. My point is that the lack of such a library suggests =
that it&#39;s not something that a lot of people need.<br></div></blockquot=
e>

<div><br></div><div>Again, what existing library do I find default_init in?=
?</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><a href=3D"htt=
p://qt-project.org/doc/qt-4.8/qvector.html" target=3D"_blank">Some of them<=
/a> default-construct empty elements instead of value-constructing them (so=
 your attempt to be clever fails).</div>

</blockquote><div><br></div><div>I can do that *now* with an allocator. =A0=
The only case that default_init covers that changing the allocator doesn&#3=
9;t is when one wants to allow both in the same container. =A0How common is=
 *that* case?</div>

<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And yet, I have yet t=
o see a version of `vector` that does what is being asked for here. I&#39;m=
 not saying that it doesn&#39;t exist. But with all of these variations of =
the concept of a `vector`, if a small-size optimized vector was something p=
eople wanted, you would think that we&#39;d have seen one by now.</div>

<div class=3D"HOEnZb"><div class=3D"h5">

<p></p></div></div></blockquote></div>Same argument seems to apply to defau=
lt_init...<br clear=3D"all"><div><br></div><div><br></div><div>Like I said,=
 the Committee weighs implementation experience, but does not dismiss the l=
ack of it out of hand.</div>

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6775aa13f9d704d981e21f--

.

------=_Part_665_11114359.1365059737230
Content-Type: text/plain; charset=ISO-8859-1


>
> And yet, I have yet to see a version of `vector` that does what is being
> asked for here. I'm not saying that it doesn't exist. But with all of these
> variations of the concept of a `vector`, if a small-size optimized vector
> was something people wanted, you would think that we'd have seen one by now.


There's SmallVector in LLVM, along with SmallSet and a few others. I've
also witnessed it a few times in the personal projects of friends.

--

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



------=_Part_665_11114359.1365059737230
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">And yet, I have yet to see a version of `vecto=
r` that does what is being asked for here. I'm not saying that it doesn't e=
xist. But with all of these variations of the concept of a `vector`, if a s=
mall-size optimized vector was something people wanted, you would think tha=
t we'd have seen one by now.</blockquote><div><br></div><div>There's SmallV=
ector in LLVM, along with SmallSet and a few others. I've also witnessed it=
 a few times in the personal projects of friends.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_665_11114359.1365059737230--

.