------=_Part_2981_2022360537.1490709929652
Content-Type: multipart/alternative;
 boundary="----=_Part_2982_1102476508.1490709929652"

------=_Part_2982_1102476508.1490709929652
Content-Type: text/plain; charset=UTF-8

Specifcally, should it be:  template <typename, size_t> class allocator

The size_t parameter is the fixed size of each allocation.  I've never
tried to implement STL containers, but my speculation is that this would
enable a variety of allocator implementations with different trade-offs
appropriate for different situations.  One could have faster allocation,
and less dynamic allocation overhead space, at the expense of not returning
as much memory for general allocation upon deallocation (in some cases).

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

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

<div dir=3D"ltr">Specifcally, should it be: =C2=A0template &lt;typename, si=
ze_t&gt; class allocator<div><br></div><div>The size_t parameter is the fix=
ed size of each allocation. =C2=A0I&#39;ve never tried to implement STL con=
tainers, but my speculation is that this would enable a variety of allocato=
r implementations with different trade-offs appropriate for different situa=
tions. =C2=A0One could have faster allocation, and less dynamic allocation =
overhead space, at the expense of not returning as much memory for general =
allocation upon deallocation (in some cases).</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/1248d8aa-10cc-4453-b1b7-987cbdbab545%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1248d8aa-10cc-4453-b1b7-987cbdbab545=
%40isocpp.org</a>.<br />

------=_Part_2982_1102476508.1490709929652--

------=_Part_2981_2022360537.1490709929652--

.

On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 07:05:29 PDT 'Walt Karas' via=
 ISO C++=20
Standard - Future Proposals wrote:
> Specifcally, should it be:  template <typename, size_t> class allocator
>=20
> The size_t parameter is the fixed size of each allocation.

What is the fixed size of each allocation for the containers? std::vector (=
for=20
example) does not have a fixed size allocation..

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/1847876.uju8QHzUcx%40tjmaciei-mobl1.

.

------=_Part_3359_284773617.1490720964689
Content-Type: multipart/alternative;
 boundary="----=_Part_3360_2095802254.1490720964689"

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



On Tuesday, March 28, 2017 at 12:26:13 PM UTC-4, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 07:05:29 PDT 'Walt Karas' v=
ia ISO C++=20
> Standard - Future Proposals wrote:=20
> > Specifcally, should it be:  template <typename, size_t> class allocator=
=20
> >=20
> > The size_t parameter is the fixed size of each allocation.=20
>
> What is the fixed size of each allocation for the containers? std::vector=
=20
> (for=20
> example) does not have a fixed size allocation..=20
>
> --=20


> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>
OK, that's a good point.  So it seems a better strategy that the allocator=
=20
remain a class parameter, but be required to have the public members:

template <size_t> pointer fixed_size_alloc();
template <size_t> void fixed_size_dealloc(pointer p);

(Except that, for reasons I don't understand, allocate/deallocate currently=
=20
use T* rather then pointer for the raw memory pointers.)

One could write short definitions of these that simply call allocate and=20
deallocate if no optimization for certain constant sizes was useful.

vector and deque would get no benefit from this.  But list, the associative=
=20
containers, and the unordered associative containers (if using chained=20
collision buckets) I think could benefit from dedicated allocators for=20
particular allocation sizes.

--=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/c861802e-22aa-45ac-91c4-d8a9e45d4e72%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 28, 2017 at 12:26:13 PM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=
=A7a-feira, 28 de mar=C3=A7o de 2017 07:05:29 PDT &#39;Walt Karas&#39; via =
ISO C++=20
<br>Standard - Future Proposals wrote:
<br>&gt; Specifcally, should it be: =C2=A0template &lt;typename, size_t&gt;=
 class allocator
<br>&gt;=20
<br>&gt; The size_t parameter is the fixed size of each allocation.
<br>
<br>What is the fixed size of each allocation for the containers? std::vect=
or (for=20
<br>example) does not have a fixed size allocation..
<br>
<br>--=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>OK, that&#39;s a good point. =C2=A0So =
it seems a better strategy that the allocator remain a class parameter, but=
 be required to have the public members:</div><div><br></div><div>template =
&lt;size_t&gt; pointer fixed_size_alloc();</div><div>template &lt;size_t&gt=
; void fixed_size_dealloc(pointer p);</div><div><br></div><div>(Except that=
, for reasons I don&#39;t understand, allocate/deallocate currently use T* =
rather then pointer for the raw memory pointers.)</div><div><br></div><div>=
One could write short definitions of these that simply call allocate and de=
allocate if no optimization for certain constant sizes was useful.</div><di=
v><br></div><div>vector and deque would get no benefit from this. =C2=A0But=
 list, the associative containers, and the unordered associative containers=
 (if using chained collision buckets) I think could benefit from dedicated =
allocators for particular allocation sizes.</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/c861802e-22aa-45ac-91c4-d8a9e45d4e72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c861802e-22aa-45ac-91c4-d8a9e45d4e72=
%40isocpp.org</a>.<br />

------=_Part_3360_2095802254.1490720964689--

------=_Part_3359_284773617.1490720964689--

.

On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 10:09:24 PDT 'Walt Karas' via=
 ISO C++=20
Standard - Future Proposals wrote:
> OK, that's a good point.  So it seems a better strategy that the allocato=
r
> remain a class parameter, but be required to have the public members:
>=20
> template <size_t> pointer fixed_size_alloc();
> template <size_t> void fixed_size_dealloc(pointer p);
>=20
> (Except that, for reasons I don't understand, allocate/deallocate current=
ly
> use T* rather then pointer for the raw memory pointers.)
>=20
> One could write short definitions of these that simply call allocate and
> deallocate if no optimization for certain constant sizes was useful.
>=20
> vector and deque would get no benefit from this.  But list, the associati=
ve
> containers, and the unordered associative containers (if using chained
> collision buckets) I think could benefit from dedicated allocators for
> particular allocation sizes.

That sounds like a good plan.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/22948465.VzVPTbfYfK%40tjmaciei-mobl1.

.

------=_Part_13286_1133213288.1490723274381
Content-Type: multipart/alternative;
 boundary="----=_Part_13287_662859792.1490723274381"

------=_Part_13287_662859792.1490723274381
Content-Type: text/plain; charset=UTF-8

I think this is all rather wrongheaded. I think what we really need is the
ability to have the allocator more effectively know about what the
container is allocating.

There are several patterns of allocations:

* Array of T: The container allocates arrays of the element type `T`.
`vector` uses these.
* Array of U: The container allocates arrays of some type `U`, which may or
may not be related to the element type `T`. `deque` and the various
unordered container uses these. `deque` implementations generally use two
separate `U` types: the array of pointers to block and the block type
itself.
* Individual node related to T: The container allocates some node type
which explicitly depends on `T`. `list`, `forward_list`, and the
associative containers use these.

Allocators should be able to specifically support particular patterns, and
containers need to be able to communicate the explicit patterns they
support. Preferably at a static level.

So you should be able to create an allocator that only supports "node
related to T" allocations, and the allocator/user can ask exactly what this
type's size/alignment will be for the container. The container will be
bound not to request any allocations of different sizes/alignments.

--
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/65ede068-2183-4e2b-a9f3-52bc9c666abc%40isocpp.org.

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

<div dir=3D"ltr">I think this is all rather wrongheaded. I think what we re=
ally need is the ability to have the allocator more effectively know about =
what the container is allocating.<br><br>There are several patterns of allo=
cations:<br><br>* Array of T: The container allocates arrays of the element=
 type `T`. `vector` uses these.<br>* Array of U: The container allocates ar=
rays of some type `U`, which may or may not be related to the element type =
`T`. `deque` and the various unordered container uses these. `deque` implem=
entations generally use two separate `U` types: the array of pointers to bl=
ock and the block type itself.<br>* Individual node related to T: The conta=
iner allocates some node type which explicitly depends on `T`. `list`, `for=
ward_list`, and the associative containers use these.<br><br>Allocators sho=
uld be able to specifically support particular patterns, and containers nee=
d to be able to communicate the explicit patterns they support. Preferably =
at a static level.<br><br>So you should be able to create an allocator that=
 only supports &quot;node related to T&quot; allocations, and the allocator=
/user can ask exactly what this type&#39;s size/alignment will be for the c=
ontainer. The container will be bound not to request any allocations of dif=
ferent sizes/alignments.<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/65ede068-2183-4e2b-a9f3-52bc9c666abc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/65ede068-2183-4e2b-a9f3-52bc9c666abc=
%40isocpp.org</a>.<br />

------=_Part_13287_662859792.1490723274381--

------=_Part_13286_1133213288.1490723274381--

.

------=_Part_4416_211914109.1490723646469
Content-Type: multipart/alternative;
 boundary="----=_Part_4417_1537479931.1490723646469"

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



On Tuesday, March 28, 2017 at 1:33:36 PM UTC-4, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 10:09:24 PDT 'Walt Karas' v=
ia ISO C++=20
> Standard - Future Proposals wrote:=20
> > OK, that's a good point.  So it seems a better strategy that the=20
> allocator=20
> > remain a class parameter, but be required to have the public members:=
=20
> >=20
> > template <size_t> pointer fixed_size_alloc();=20
> > template <size_t> void fixed_size_dealloc(pointer p);=20
> >=20
> > (Except that, for reasons I don't understand, allocate/deallocate=20
> currently=20
> > use T* rather then pointer for the raw memory pointers.)=20
> >=20
> > One could write short definitions of these that simply call allocate an=
d=20
> > deallocate if no optimization for certain constant sizes was useful.=20
> >=20
> > vector and deque would get no benefit from this.  But list, the=20
> associative=20
> > containers, and the unordered associative containers (if using chained=
=20
> > collision buckets) I think could benefit from dedicated allocators for=
=20
> > particular allocation sizes.=20
>
> That sounds like a good plan.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>
I think also it might be good if the container could somehow pass a=20
"move(pointer_to_empty_spot, pointer_to_live_obj)" callback type thingy to=
=20
the fixed sized allocator.  This would be helpful if the fixed sized=20
allocator was allocating small things in contiguous blocks from the more=20
general dynamic memory allocator.  It could then perhaps move in-use small=
=20
things into available spots in a different block, so it could release=20
blocks back to the general memory pool more efficiently. But then the rules=
=20
about invalidation of iterators and pointer/references into the container=
=20
would get much more complicated.

--=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/45be9c85-7244-416b-a5c7-a59c94000d80%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 28, 2017 at 1:33:36 PM UTC-4, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=
=A7a-feira, 28 de mar=C3=A7o de 2017 10:09:24 PDT &#39;Walt Karas&#39; via =
ISO C++=20
<br>Standard - Future Proposals wrote:
<br>&gt; OK, that&#39;s a good point. =C2=A0So it seems a better strategy t=
hat the allocator
<br>&gt; remain a class parameter, but be required to have the public membe=
rs:
<br>&gt;=20
<br>&gt; template &lt;size_t&gt; pointer fixed_size_alloc();
<br>&gt; template &lt;size_t&gt; void fixed_size_dealloc(pointer p);
<br>&gt;=20
<br>&gt; (Except that, for reasons I don&#39;t understand, allocate/dealloc=
ate currently
<br>&gt; use T* rather then pointer for the raw memory pointers.)
<br>&gt;=20
<br>&gt; One could write short definitions of these that simply call alloca=
te and
<br>&gt; deallocate if no optimization for certain constant sizes was usefu=
l.
<br>&gt;=20
<br>&gt; vector and deque would get no benefit from this. =C2=A0But list, t=
he associative
<br>&gt; containers, and the unordered associative containers (if using cha=
ined
<br>&gt; collision buckets) I think could benefit from dedicated allocators=
 for
<br>&gt; particular allocation sizes.
<br>
<br>That sounds like a good plan.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote><div><br></div><div>I think also it might be good if the c=
ontainer could somehow pass a &quot;move(pointer_to_empty_spot, pointer_to_=
live_obj)&quot; callback type thingy to the fixed sized allocator. =C2=A0Th=
is would be helpful if the fixed sized allocator was allocating small thing=
s in contiguous blocks from the more general dynamic memory allocator. =C2=
=A0It could then perhaps move in-use small things into available spots in a=
 different block, so it could release blocks back to the general memory poo=
l more efficiently. But then the rules about invalidation of iterators and =
pointer/references into the container would get much more complicated.</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/45be9c85-7244-416b-a5c7-a59c94000d80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45be9c85-7244-416b-a5c7-a59c94000d80=
%40isocpp.org</a>.<br />

------=_Part_4417_1537479931.1490723646469--

------=_Part_4416_211914109.1490723646469--

.

On 2017-03-28 19:09, 'Walt Karas' via ISO C++ Standard - Future=20
Proposals wrote:
>
>
> On Tuesday, March 28, 2017 at 12:26:13 PM UTC-4, Thiago Macieira wrote:
>
>     On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 07:05:29 PDT 'Walt Kara=
s' via
>     ISO C++
>     Standard - Future Proposals wrote:
>     > Specifcally, should it be:  template <typename, size_t> class
>     allocator
>     >
>     > The size_t parameter is the fixed size of each allocation.
>
>     What is the fixed size of each allocation for the containers?
>     std::vector (for
>     example) does not have a fixed size allocation..
>
>     --
>
>
>     Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> -
>     thiago (AT) kde.org <http://kde.org>
>        Software Architect - Intel Open Source Technology Center
>
>
> OK, that's a good point.  So it seems a better strategy that the
> allocator remain a class parameter, but be required to have the public
> members:
>
> template <size_t> pointer fixed_size_alloc();
> template <size_t> void fixed_size_dealloc(pointer p);
>
> (Except that, for reasons I don't understand, allocate/deallocate
> currently use T* rather then pointer for the raw memory pointers.)
>
> One could write short definitions of these that simply call allocate and
> deallocate if no optimization for certain constant sizes was useful.
>

Can't we just have a node_allocator<T> and use that with std::list? Then=20
we can have that allocator assume that it will **always** be called with=20
allocate(1), and optimize for that.


     Bo Persson



--=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/obefqo%249dj%241%40blaine.gmane.org.

.