------=_Part_1008_28661684.1363648410550
Content-Type: text/plain; charset=ISO-8859-1

Now that we can have stateful allocators, a problem still remains:
containers are allowed to rebind allocators, so that they don't allocate
`T`'s anymore. This effectively makes it impossible to implement a
slot/pool allocator for a node container in a cross-platform way<http://stackoverflow.com/questions/15488527/rebinding-in-a-custom-stl-allocator-with-pre-allocated-block>
..

What we need is for node-based containers to provide a member type that is
a `std::aligned_storage` for a particular size and alignment. This
container is then required to allocate only allocations of that particular
size and alignment. Note that this doesn't have to be one "node" in size;
if a node container like to allocate groups of 4 nodes at once, then the
`aligned_storage` type will be for 4 nodes.

Is there a better way to handle this? Or is this sufficient?

--

---
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_1008_28661684.1363648410550
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Now that we can have stateful allocators, a problem still remains: containe=
rs are allowed to rebind allocators, so that they don't allocate `T`'s anym=
ore. This <a href=3D"http://stackoverflow.com/questions/15488527/rebinding-=
in-a-custom-stl-allocator-with-pre-allocated-block">effectively makes it im=
possible to implement a slot/pool allocator for a node container in a cross=
-platform way</a>.<br><br>What we need is for node-based containers to prov=
ide a member type that is a `std::aligned_storage` for a particular size an=
d alignment. This container is then required to allocate only allocations o=
f that particular size and alignment. Note that this doesn't have to be one=
 "node" in size; if a node container like to allocate groups of 4 nodes at =
once, then the `aligned_storage` type will be for 4 nodes.<br><br>Is there =
a better way to handle this? Or is this sufficient?<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_1008_28661684.1363648410550--

.

------=_Part_1019_6600621.1363694480013
Content-Type: text/plain; charset=ISO-8859-1



On Monday, March 18, 2013 11:13:30 PM UTC, Nicol Bolas wrote:
>
> Now that we can have stateful allocators, a problem still remains:
> containers are allowed to rebind allocators, so that they don't allocate
> `T`'s anymore. This effectively makes it impossible to implement a
> slot/pool allocator for a node container in a cross-platform way<http://stackoverflow.com/questions/15488527/rebinding-in-a-custom-stl-allocator-with-pre-allocated-block>
> .
>
> What we need is for node-based containers to provide a member type that is
> a `std::aligned_storage` for a particular size and alignment. This
> container is then required to allocate only allocations of that particular
> size and alignment. Note that this doesn't have to be one "node" in size;
> if a node container like to allocate groups of 4 nodes at once, then the
> `aligned_storage` type will be for 4 nodes.
>
> Is there a better way to handle this? Or is this sufficient?
>

I don't think we want to require implementations to expose that level of
detail.  We could maybe require that a container's internal types are not
over-aligned, in which case alignof(std::max_align_t) is sufficient as the
alignment.  Knowing the size isn't essential, if the allocator can handle
sizeof(value_type) and sizeof(something else) then it's not much harder to
handle any size and just be able to deal with whatever the container asks
for.

--

---
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_1019_6600621.1363694480013
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, March 18, 2013 11:13:30 PM UTC, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Now that we can have stateful alloca=
tors, a problem still remains: containers are allowed to rebind allocators,=
 so that they don't allocate `T`'s anymore. This <a href=3D"http://stackove=
rflow.com/questions/15488527/rebinding-in-a-custom-stl-allocator-with-pre-a=
llocated-block" target=3D"_blank">effectively makes it impossible to implem=
ent a slot/pool allocator for a node container in a cross-platform way</a>.=
<br><br>What we need is for node-based containers to provide a member type =
that is a `std::aligned_storage` for a particular size and alignment. This =
container is then required to allocate only allocations of that particular =
size and alignment. Note that this doesn't have to be one "node" in size; i=
f a node container like to allocate groups of 4 nodes at once, then the `al=
igned_storage` type will be for 4 nodes.<br><br>Is there a better way to ha=
ndle this? Or is this sufficient?<br></blockquote><div><br>I don't think we=
 want to require implementations to expose that level of detail.&nbsp; We c=
ould maybe require that a container's internal types are not over-aligned, =
in which case alignof(std::max_align_t) is sufficient as the alignment.&nbs=
p; Knowing the size isn't essential, if the allocator can handle sizeof(val=
ue_type) and sizeof(something else) then it's not much harder to handle any=
 size and just be able to deal with whatever the container asks for.<br></d=
iv>

<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_1019_6600621.1363694480013--

.

------=_Part_787_5764817.1363709327825
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, March 19, 2013 5:01:19 AM UTC-7, Jonathan Wakely wrote:
>
>
>
> On Monday, March 18, 2013 11:13:30 PM UTC, Nicol Bolas wrote:
>>
>> Now that we can have stateful allocators, a problem still remains:
>> containers are allowed to rebind allocators, so that they don't allocate
>> `T`'s anymore. This effectively makes it impossible to implement a
>> slot/pool allocator for a node container in a cross-platform way<http://stackoverflow.com/questions/15488527/rebinding-in-a-custom-stl-allocator-with-pre-allocated-block>
>> .
>>
>> What we need is for node-based containers to provide a member type that
>> is a `std::aligned_storage` for a particular size and alignment. This
>> container is then required to allocate only allocations of that particular
>> size and alignment. Note that this doesn't have to be one "node" in size;
>> if a node container like to allocate groups of 4 nodes at once, then the
>> `aligned_storage` type will be for 4 nodes.
>>
>> Is there a better way to handle this? Or is this sufficient?
>>
>
> I don't think we want to require implementations to expose that level of
> detail.  We could maybe require that a container's internal types are not
> over-aligned, in which case alignof(std::max_align_t) is sufficient as the
> alignment.  Knowing the size isn't essential, if the allocator can handle
> sizeof(value_type) and sizeof(something else) then it's not much harder to
> handle any size and just be able to deal with whatever the container asks
> for.
>

Perhaps we're not talking about the same thing. I'm talking about writing a memory
pool allocator <http://en.wikipedia.org/wiki/Memory_pool>, where you
allocate an array of fixed-sized objects, and dole those fixed-size blocks
of memory out to whomever asks for them. You can't allocate an array of
fixed-sized objects, then expect to service a system that allocates
arbitrarily sized objects. A pool allocator simply cannot "handle any
size"; you have to know the size of the objects beforehand.

What exactly is lost by forcing implementations of node-based container
types to stick to one particular size of allocation? Specifically, I'm
thinking of `list`, `map`, and `set` (the multi-versions too); the
unordered ones are more complex and can't really be used with a pool
allocation scheme.

--

---
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_787_5764817.1363709327825
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, March 19, 2013 5:01:19 AM UTC-7, Jonathan Wakely wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Monday, March 18, 2=
013 11:13:30 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">Now that we can have stateful allocators, a problem still remains: cont=
ainers are allowed to rebind allocators, so that they don't allocate `T`'s =
anymore. This <a href=3D"http://stackoverflow.com/questions/15488527/rebind=
ing-in-a-custom-stl-allocator-with-pre-allocated-block" target=3D"_blank">e=
ffectively makes it impossible to implement a slot/pool allocator for a nod=
e container in a cross-platform way</a>.<br><br>What we need is for node-ba=
sed containers to provide a member type that is a `std::aligned_storage` fo=
r a particular size and alignment. This container is then required to alloc=
ate only allocations of that particular size and alignment. Note that this =
doesn't have to be one "node" in size; if a node container like to allocate=
 groups of 4 nodes at once, then the `aligned_storage` type will be for 4 n=
odes.<br><br>Is there a better way to handle this? Or is this sufficient?<b=
r></blockquote><div><br>I don't think we want to require implementations to=
 expose that level of detail.&nbsp; We could maybe require that a container=
's internal types are not over-aligned, in which case alignof(std::max_alig=
n_t) is sufficient as the alignment.&nbsp; Knowing the size isn't essential=
, if the allocator can handle sizeof(value_type) and sizeof(something else)=
 then it's not much harder to handle any size and just be able to deal with=
 whatever the container asks for.<br></div></blockquote><div><br>Perhaps we=
're not talking about the same thing. I'm talking about writing a <a href=
=3D"http://en.wikipedia.org/wiki/Memory_pool">memory pool allocator</a>, wh=
ere you allocate an array of fixed-sized objects, and dole those fixed-size=
 blocks of memory out to whomever asks for them. You can't allocate an arra=
y of fixed-sized objects, then expect to service a system that allocates ar=
bitrarily sized objects. A pool allocator simply cannot "handle any size"; =
you have to know the size of the objects beforehand.<br><br>What exactly is=
 lost by forcing implementations of node-based container types to stick to =
one particular size of allocation? Specifically, I'm thinking of `list`, `m=
ap`, and `set` (the multi-versions too); the unordered ones are more comple=
x and can't really be used with a pool allocation scheme.<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_787_5764817.1363709327825--

.

------=_Part_575_4855721.1363736628729
Content-Type: text/plain; charset=ISO-8859-1

Op dinsdag 19 maart 2013 17:08:47 UTC+1 schreef Nicol Bolas het volgende:

> Perhaps we're not talking about the same thing. I'm talking about writing
> a memory pool allocator <http://en.wikipedia.org/wiki/Memory_pool>, where
> you allocate an array of fixed-sized objects, and dole those fixed-size
> blocks of memory out to whomever asks for them. You can't allocate an array
> of fixed-sized objects, then expect to service a system that allocates
> arbitrarily sized objects. A pool allocator simply cannot "handle any
> size"; you have to know the size of the objects beforehand.
>
> What exactly is lost by forcing implementations of node-based container
> types to stick to one particular size of allocation? Specifically, I'm
> thinking of `list`, `map`, and `set` (the multi-versions too); the
> unordered ones are more complex and can't really be used with a pool
> allocation scheme.
>

Why not? AFAIK hash maps allocate tons of 'nodes' too, so they too could
benefit. They do also allocate other stuff though.

--

---
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_575_4855721.1363736628729
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op dinsdag 19 maart 2013 17:08:47 UTC+1 schreef Nicol Bolas het volgende:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Perhaps we're not talking ab=
out the same thing. I'm talking about writing a <a href=3D"http://en.wikipe=
dia.org/wiki/Memory_pool" target=3D"_blank">memory pool allocator</a>, wher=
e you allocate an array of fixed-sized objects, and dole those fixed-size b=
locks of memory out to whomever asks for them. You can't allocate an array =
of fixed-sized objects, then expect to service a system that allocates arbi=
trarily sized objects. A pool allocator simply cannot "handle any size"; yo=
u have to know the size of the objects beforehand.<br><div><br>What exactly=
 is lost by forcing implementations of node-based container types to stick =
to one particular size of allocation? Specifically, I'm thinking of `list`,=
 `map`, and `set` (the multi-versions too); the unordered ones are more com=
plex and can't really be used with a pool allocation scheme.<br></div></blo=
ckquote><div><br></div><div>Why not? AFAIK hash maps allocate tons of 'node=
s' too, so they too could benefit. They do also allocate other stuff though=
..</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_575_4855721.1363736628729--

.

------=_Part_91_14218389.1363737337700
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, March 19, 2013 4:43:48 PM UTC-7, Olaf van der Spek wrote:
>
> Op dinsdag 19 maart 2013 17:08:47 UTC+1 schreef Nicol Bolas het volgende:
>
>> Perhaps we're not talking about the same thing. I'm talking about writing
>> a memory pool allocator <http://en.wikipedia.org/wiki/Memory_pool>,
>> where you allocate an array of fixed-sized objects, and dole those
>> fixed-size blocks of memory out to whomever asks for them. You can't
>> allocate an array of fixed-sized objects, then expect to service a system
>> that allocates arbitrarily sized objects. A pool allocator simply cannot
>> "handle any size"; you have to know the size of the objects beforehand.
>>
>> What exactly is lost by forcing implementations of node-based container
>> types to stick to one particular size of allocation? Specifically, I'm
>> thinking of `list`, `map`, and `set` (the multi-versions too); the
>> unordered ones are more complex and can't really be used with a pool
>> allocation scheme.
>>
>
> Why not? AFAIK hash maps allocate tons of 'nodes' too, so they too could
> benefit. They do also allocate other stuff though.
>

That last part is the main problem: you can't have the actual hashtable
itself be part of the pool if you want it to be contiguous.

The main difficulty is being able to tell the difference between a node
allocation and the allocation of the table that just so happens to be the
same size as a node.

--

---
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_91_14218389.1363737337700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, March 19, 2013 4:43:48 PM UTC-7, Olaf van der Spek wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Op dinsdag 19 maart 2013 17:=
08:47 UTC+1 schreef Nicol Bolas het volgende:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Perhaps we're not talking about the same thing. I'm talking a=
bout writing a <a href=3D"http://en.wikipedia.org/wiki/Memory_pool" target=
=3D"_blank">memory pool allocator</a>, where you allocate an array of fixed=
-sized objects, and dole those fixed-size blocks of memory out to whomever =
asks for them. You can't allocate an array of fixed-sized objects, then exp=
ect to service a system that allocates arbitrarily sized objects. A pool al=
locator simply cannot "handle any size"; you have to know the size of the o=
bjects beforehand.<br><div><br>What exactly is lost by forcing implementati=
ons of node-based container types to stick to one particular size of alloca=
tion? Specifically, I'm thinking of `list`, `map`, and `set` (the multi-ver=
sions too); the unordered ones are more complex and can't really be used wi=
th a pool allocation scheme.<br></div></blockquote><div><br></div><div>Why =
not? AFAIK hash maps allocate tons of 'nodes' too, so they too could benefi=
t. They do also allocate other stuff though.</div></blockquote><div><br>Tha=
t last part is the main problem: you can't have the actual hashtable itself=
 be part of the pool if you want it to be contiguous.<br><br>The main diffi=
culty is being able to tell the difference between a node allocation and th=
e allocation of the table that just so happens to be the same size as a nod=
e.<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_91_14218389.1363737337700--

.

On Wed, Mar 20, 2013 at 12:55 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Why not? AFAIK hash maps allocate tons of 'nodes' too, so they too could
>> benefit. They do also allocate other stuff though.
>
>
> That last part is the main problem: you can't have the actual hashtable
> itself be part of the pool if you want it to be contiguous.
>
> The main difficulty is being able to tell the difference between a node
> allocation and the allocation of the table that just so happens to be the
> same size as a node.

Is there a need to be able to tell the difference if they're the same size?


--
Olaf

--

---
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_28_26162716.1363738412930
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, March 19, 2013 5:07:36 PM UTC-7, Olaf van der Spek wrote:
>
> On Wed, Mar 20, 2013 at 12:55 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >> Why not? AFAIK hash maps allocate tons of 'nodes' too, so they too
> could
> >> benefit. They do also allocate other stuff though.
> >
> >
> > That last part is the main problem: you can't have the actual hashtable
> > itself be part of the pool if you want it to be contiguous.
> >
> > The main difficulty is being able to tell the difference between a node
> > allocation and the allocation of the table that just so happens to be
> the
> > same size as a node.
>
> Is there a need to be able to tell the difference if they're the same
> size?
>
>
> --
> Olaf
>

Fair enough ;)

--

---
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_28_26162716.1363738412930
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, March 19, 2013 5:07:36 PM UTC-7, Olaf van der Spek wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Mar 20, 2013 at 12:5=
5 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"htyjJW_TvxwJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; Why not? AFAIK hash maps allocate tons of 'nodes' too, so they=
 too could
<br>&gt;&gt; benefit. They do also allocate other stuff though.
<br>&gt;
<br>&gt;
<br>&gt; That last part is the main problem: you can't have the actual hash=
table
<br>&gt; itself be part of the pool if you want it to be contiguous.
<br>&gt;
<br>&gt; The main difficulty is being able to tell the difference between a=
 node
<br>&gt; allocation and the allocation of the table that just so happens to=
 be the
<br>&gt; same size as a node.
<br>
<br>Is there a need to be able to tell the difference if they're the same s=
ize?
<br>
<br>
<br>--=20
<br>Olaf
<br></blockquote><div><br>Fair enough ;) <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_28_26162716.1363738412930--

.

------=_Part_94_31667867.1363904083284
Content-Type: text/plain; charset=ISO-8859-1

Boost.Pool handles this just fine. Not knowing the implementation's
size/alignment requirements makes it tough, but you can simply create a
pool for each sizeof(T) that the implementation requests.

--

---
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_94_31667867.1363904083284
Content-Type: text/html; charset=ISO-8859-1

Boost.Pool handles this just fine. Not knowing the implementation's size/alignment requirements makes it tough, but you can simply create a pool for each sizeof(T) that the implementation requests.

<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 />

------=_Part_94_31667867.1363904083284--

.

On Thu, Mar 21, 2013 at 11:14 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> Boost.Pool handles this just fine. Not knowing the implementation's
> size/alignment requirements makes it tough, but you can simply create a pool
> for each sizeof(T) that the implementation requests.

Does it?
AFAIK it doesn't support a pool just for one container, it only
supports global pools. So locality may suffer and it requires locking.

--

---
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_256_9820891.1363918470196
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, March 21, 2013 3:15:39 PM UTC-7, Olaf van der Spek wrote:
>
> On Thu, Mar 21, 2013 at 11:14 PM, DeadMG <wolfei...@gmail.com<javascript:>>
> wrote:
> > Boost.Pool handles this just fine. Not knowing the implementation's
> > size/alignment requirements makes it tough, but you can simply create a
> pool
> > for each sizeof(T) that the implementation requests.
>
> Does it?
> AFAIK it doesn't support a pool just for one container, it only
> supports global pools. So locality may suffer and it requires locking.
>

I agree. This all sounds way too global. It also breaks one of the points
of having a pool: to *pre-allocate* memory. You're not really
pre-allocating something if you're allocating a pool upon request.

--

---
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_256_9820891.1363918470196
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, March 21, 2013 3:15:39 PM UTC-7, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Mar 21, 2013 at 11:=
14 PM, DeadMG &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"gKiEdAiGnAkJ">wolfei...@gmail.com</a>&gt; wrote: <br>&gt; Boost.P=
ool handles this just fine. Not knowing the implementation's <br>&gt; size/=
alignment requirements makes it tough, but you can simply create a pool <br=
>&gt; for each sizeof(T) that the implementation requests. <br> <br>Does it=
? <br>AFAIK it doesn't support a pool just for one container, it only <br>s=
upports global pools. So locality may suffer and it requires locking.<br></=
blockquote><div><br>I agree. This all sounds way too global. It also breaks=
 one of the points of having a pool: to <i>pre-allocate</i> memory. You're =
not really pre-allocating something if you're allocating a pool upon reques=
t. <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_256_9820891.1363918470196--

.

------=_Part_676_9490808.1363953995869
Content-Type: text/plain; charset=ISO-8859-1

There's no difference between pre-allocating memory in the constructor of a
pool of fixed size, and pre-allocating memory in the constructor of a pool
of dynamic size which was constructed upon request.

In addition, you have to consider what would happen in a container like
unordered_map, where it's half node-based, half array-based.

--

---
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_676_9490808.1363953995869
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There's no difference between pre-allocating memory in the constructor of a=
 pool of fixed size, and pre-allocating memory in the constructor of a pool=
 of dynamic size which was constructed upon request.<div><br></div><div>In =
addition, you have to consider what would happen in a container like unorde=
red_map, where it's half node-based, half array-based.</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_676_9490808.1363953995869--

.

------=_Part_55_24826673.1363963467382
Content-Type: text/plain; charset=ISO-8859-1

On Friday, March 22, 2013 5:06:35 AM UTC-7, DeadMG wrote:
>
> There's no difference between pre-allocating memory in the constructor of
> a pool of fixed size, and pre-allocating memory in the constructor of a
> pool of dynamic size which was constructed upon request.


Sure there is: when it happens.

In one case, it happens when I want it to: at the very beginning of my
application, in a fixed and pre-defined order.

In the other case, it happens at some arbitrary point when someone, *
somewhere*, uses a container. I have no idea of the order of memory
allocation, so the heap could very well get fragmented, with these pools
allocated and deallocated in an arbitrary order.

In addition, you have to consider what would happen in a container like
> unordered_map, where it's half node-based, half array-based.
>

Olaf already brought that up, and it doesn't seem to be a problem, so long
as the allocator is designed to allocate from the pool only when the size
is the right size for the pool items. Otherwise, it allocates from the heap.

--

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



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

On Friday, March 22, 2013 5:06:35 AM 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's no difference between pre-allocating me=
mory in the constructor of a pool of fixed size, and pre-allocating memory =
in the constructor of a pool of dynamic size which was constructed upon req=
uest.</blockquote><div><br>Sure there is: when it happens.<br><br>In one ca=
se, it happens when I want it to: at the very beginning of my application, =
in a fixed and pre-defined order.<br><br>In the other case, it happens at s=
ome arbitrary point when someone, <i>somewhere</i>, uses a container. I hav=
e no idea of the order of memory allocation, so the heap could very well ge=
t fragmented, with these pools allocated and deallocated in an arbitrary or=
der.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><=
div>In addition, you have to consider what would happen in a container like=
 unordered_map, where it's half node-based, half array-based.</div></blockq=
uote><div><br>Olaf already brought that up, and it doesn't seem to be a pro=
blem, so long as the allocator is designed to allocate from the pool only w=
hen the size is the right size for the pool items. Otherwise, it allocates =
from the heap.<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_55_24826673.1363963467382--

.

------=_Part_202_31332084.1363981670065
Content-Type: text/plain; charset=ISO-8859-1

So you simply explicitly request the pool. If you look at N3575, you could
simply call get_sized_pool() at the beginning of your program. In the
general case, lazily allocating the requested memory is better, IYAM.

--

---
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_202_31332084.1363981670065
Content-Type: text/html; charset=ISO-8859-1

So you simply explicitly request the pool. If you look at N3575, you could simply call get_sized_pool() at the beginning of your program. In the general case, lazily allocating the requested memory is better, IYAM.

<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 />

------=_Part_202_31332084.1363981670065--

.

------=_Part_155_15732669.1363996832853
Content-Type: text/plain; charset=ISO-8859-1

On Friday, March 22, 2013 12:47:49 PM UTC-7, DeadMG wrote:
>
> So you simply explicitly request the pool. If you look at N3575, you could
> simply call get_sized_pool() at the beginning of your program.


Thus leading us back to the original problem I'm trying to solve: we *don't
know* the size. We can't know the size, because there is no way to tell
std::list to give us the size/alignment of its internal node data
structures. Without the size, you can't call `get_sized_pool`.

--

---
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_155_15732669.1363996832853
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, March 22, 2013 12:47:49 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;">So you simply explicitly request the pool. If y=
ou look at N3575, you could simply call get_sized_pool() at the beginning o=
f your program.</blockquote><div><br>Thus leading us back to the original p=
roblem I'm trying to solve: we <i>don't know</i> the size. We can't know th=
e size, because there is no way to tell std::list to give us the size/align=
ment of its internal node data structures. Without the size, you can't call=
 `get_sized_pool`.<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_155_15732669.1363996832853--

.

------=_Part_153_5771429.1364226531412
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, March 21, 2013 10:14:43 PM UTC, DeadMG wrote:
>
> Boost.Pool handles this just fine. Not knowing the implementation's
> size/alignment requirements makes it tough, but you can simply create a
> pool for each sizeof(T) that the implementation requests.


Or to avoid needing a pool for *every* different size of object, round the
size up to a power of two and use one pool for all objects <= 4 bytes,
another pool for <= 8 bytes, another for <= 16 bytes, etc.


--

---
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_153_5771429.1364226531412
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, March 21, 2013 10:14:43 PM UTC, DeadMG wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">Boost.Pool handles this just fine. Not =
knowing the implementation's size/alignment requirements makes it tough, bu=
t you can simply create a pool for each sizeof(T) that the implementation r=
equests.</blockquote><div><br>Or to avoid needing a pool for *every* differ=
ent size of object, round the size up to a power of two and use one pool fo=
r all objects &lt;=3D 4 bytes, another pool for &lt;=3D 8 bytes, another fo=
r &lt;=3D 16 bytes, etc.<br><br><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_153_5771429.1364226531412--

.

------=_Part_126_10923256.1364226870845
Content-Type: text/plain; charset=ISO-8859-1

Yeah, you're right. Conceptually, the pool should pre-allocate a fixed
number of pages, which would be fragmentation-free and order is effectively
irrelevant, but that might not be valid on all systems.

Alternatively, you could pre-allocate in the pool's constructor, and then
the pools can sub-allocate from there.

Jonathan: That scheme is already permitted by N3575.

--

---
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_126_10923256.1364226870845
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yeah, you're right. Conceptually, the pool should pre-allocate a fixed numb=
er of pages, which would be fragmentation-free and order is effectively irr=
elevant, but that might not be valid on all systems.<div><br></div><div>Alt=
ernatively, you could pre-allocate in the pool's constructor, and then the =
pools can sub-allocate from there.</div><div><br></div><div>Jonathan: That =
scheme is already permitted by N3575.</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_126_10923256.1364226870845--

.