------=_Part_1117_1104473155.1445544355978
Content-Type: multipart/alternative;
 boundary="----=_Part_1118_1930905471.1445544355978"

------=_Part_1118_1930905471.1445544355978
Content-Type: text/plain; charset=UTF-8

I just wanted to point out that there are some other, MUCH faster ways to
implement memory allocation with almost no overhead.
In C, C++, you don't see these methods used because the memory API is
incompatible with them... But it is possible that, provided there is a
suitably sized block, we can guarantee both O(1) alloc and O(1) free, with
O(1) memory allocator overhead for all allocations (excluding free blocks)
and fixed % maximum block-size round-up overhead. (This can be set very
low, e.g. 1/8th excluding initial round-up to nearest word size) In order
to obtain this speed-up, we must provide the following API (names would
change probably):

void * alloc_fixed(size_t size);
void   free_fixed(void * mem, size_t size);


This API requires that the size be provided. It does not allow allocations
allocated with alloc_fixed to be deleted using an unsized free function.
This is important for maintaining an O(1) memory overhead for all
allocations and an O(1) time complexity for the free function.

This is possible to accomplish by using a slab-type allocator system with
floating point style size slab bucket indexing. It could also be templated,
providing further speed improvements, (no lookup, the size could be
evaluated at compile time.)

This could provide an enormous efficiency increase when working with, e.g.,
linked lists. For example, if a linked list node is 16 bytes (data plus
pointer), we can allocate in O(1), free in O(1), and have no memory
overhead per node other than the data of the node itself.
Without this API, we can either:
Provide the size as a header, producing additional memory overhead per
allocation.
Or look up the size, producing non-O(1) CPU overhead per alloc or free.

We need non-fixed size allocations, for that I suggest a new API as well:

std::tuple<void *, size_t> alloc_array(size_t size);
// Allocates an array of size or larger. Second return argument is the
actual size allocated.

std::tuple<void *, size_t> alloc_array(size_t min_sz, size_t req_max);
// Allocates an array of min_sz or larger, preferably not larger than
req_max, but this is a non-binding hint.

std::tuple<size_t, size_t> size_array(void * mem);
// Returns a tuple. The actual size of mem is the first element. The second
is the amount of free space known to follow mem. (Optional, lazy memory
allocators may return 0).

std::size_t<bool, size_t> try_expand_array(void * mem, size_t min_sz,
size_t max_sz);
// If mem can be expanded or shrunk to at least min_sz in-place, at most
max_sz(non-binding hint), returns true and the new size.
// If it returns false the operation failed and the allocation remains the
same size.

void free_array (void * mem);
// Self explanitory



These two APIs would not mix. You could only use one or the other for some
memory allocation.
With the above API we get:

* Less overhead for vectors, no need to store capacity, only size.
* No wasted space. If a vector allocates space for 40 elements, and the
memory allocator decides that it will round up the allocation to a size big
enough for 64 elements, the vector can make usage of the extra space.
* Possible to in-place expand vectors when lucky, if memory is fragmented.

Comments?

--

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

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

<div dir=3D"ltr">I just wanted to point out that there are some other, MUCH=
 faster ways to implement memory allocation with almost no overhead.<br>In =
C, C++, you don&#39;t see these methods used because the memory API is inco=
mpatible with them... But it is possible that, provided there is a suitably=
 sized block, we can guarantee both O(1) alloc and O(1) free, with O(1) mem=
ory allocator overhead for all allocations (excluding free blocks) and fixe=
d % maximum block-size round-up overhead. (This can be set very low, e.g. 1=
/8th excluding initial round-up to nearest word size) In order to obtain th=
is speed-up, we must provide the following API (names would change probably=
):<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">vo=
id</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> alloc_fixed</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">size_t size</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> =C2=A0 free_fixed</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 mem</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t size</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></di=
v></code></div><br><br>This API requires that the size be provided. It does=
 not allow allocations allocated with alloc_fixed to be deleted using an un=
sized free function. This is important for maintaining an O(1) memory overh=
ead for all allocations and an O(1) time complexity for the free function.<=
br><br>This is possible to accomplish by using a slab-type allocator system=
 with floating point style size slab bucket indexing. It could also be temp=
lated, providing further speed improvements, (no lookup, the size could be =
evaluated at compile time.)<br><br>This could provide an enormous efficienc=
y increase when working with, e.g., linked lists. For example, if a linked =
list node is 16 bytes (data plus pointer), we can allocate in O(1), free in=
 O(1), and have no memory overhead per node other than the data of the node=
 itself.<br>Without this API, we can either:<br>Provide the size as a heade=
r, producing additional memory overhead per allocation.<br>Or look up the s=
ize, producing non-O(1) CPU overhead per alloc or free.<br><br>We need non-=
fixed size allocations, for that I suggest a new API as well:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">tuple</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> size_t</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
alloc_array</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t s=
ize</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// Allocates an array=
 of size or larger. Second return argument is the actual size allocated.</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">*,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> size_t</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> alloc_array</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">size_t min_sz</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
size_t req_max</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Allocat=
es an array of min_sz or larger, preferably not larger than req_max, but th=
is is a non-binding hint.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br>std</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">siz=
e_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> size_array</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> mem</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 Returns a tuple. The actual size of mem is the first element. The second i=
s the amount of free space known to follow mem. (Optional, lazy memory allo=
cators may return 0).</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br>std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">size_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> size_t</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> try_expand_array</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> mem</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> size_t min_sz</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> size_t max_sz</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// If =
mem can be expanded or shrunk to at least min_sz in-place, at most max_sz(n=
on-binding hint), returns true and the new size.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// If it returns false the operation failed=
 and the allocation remains the same size.</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> free_array </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mem</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// Self explanitory</span><=
/div></code></div><br><br><br>These two APIs would not mix. You could only =
use one or the other for some memory allocation.<br>With the above API we g=
et:<br><br>* Less overhead for vectors, no need to store capacity, only siz=
e.<br>* No wasted space. If a vector allocates space for 40 elements, and t=
he memory allocator decides that it will round up the allocation to a size =
big enough for 64 elements, the vector can make usage of the extra space.<b=
r>* Possible to in-place expand vectors when lucky, if memory is fragmented=
..<br><br>Comments?<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1118_1930905471.1445544355978--
------=_Part_1117_1104473155.1445544355978--

.

On 10/22/2015 3:05 PM, Ryan Nicholl wrote:
> This API requires that the size be provided. It does not allow
> allocations allocated with alloc_fixed to be deleted using an unsized
> free function. This is important for maintaining an O(1) memory overhead
> for all allocations and an O(1) time complexity for the free function.

This sounds a lot like N3536: Sized Deallocation[1]. Is that not
sufficient for your needs? (That said, I wouldn't mind seeing new/delete
go away and be replaced with ordinary functions like malloc/free or your
alloc_fixed/free_fixed, but that's a huge can of worms, so I haven't
written up a proposal for it.)

- Jim

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.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/.

.

------=_Part_1566_782547938.1445557046803
Content-Type: multipart/alternative;
 boundary="----=_Part_1567_1289961239.1445557046803"

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

On Thursday, October 22, 2015 at 10:05:56 AM UTC-10, Ryan Nicholl wrote:
>
> I just wanted to point out that there are some other, MUCH faster ways to=
=20
> implement memory allocation with almost no overhead.
> In C, C++, you don't see these methods used because the memory API is=20
> incompatible with them... But it is possible that, provided there is a=20
> suitably sized block, we can guarantee both O(1) alloc and O(1) free, wit=
h=20
> O(1) memory allocator overhead for all allocations (excluding free blocks=
)=20
> and fixed % maximum block-size round-up overhead. (This can be set very=
=20
> low, e.g. 1/8th excluding initial round-up to nearest word size) In order=
=20
> to obtain this speed-up, we must provide the following API (names would=
=20
> change probably):
>
> void * alloc_fixed(size_t size);
> void   free_fixed(void * mem, size_t size);
>
> [...]

> We need non-fixed size allocations, for that I suggest a new API as well:
>
> std::tuple<void *, size_t> alloc_array(size_t size);
> // Allocates an array of size or larger. Second return argument is the=20
> actual size allocated.
>
[...]

> void free_array (void * mem);
> // Self explanitory
>

Surely in this case you should be providing size_t size to free_array as=20
well, since the caller by definition knows the size that was returned from=
=20
alloc_array.

On the subject of "allocator designs that make sense", I highly recommend=
=20
watching Andrei Alexandrescu's talk from CppCon 2015:
https://www.youtube.com/watch?v=3DLIb3L4vKZ7U
The big wins IMHO, also mostly present in your design, are
- we should separate allocation-of-memory from=20
construction/destruction-of-Ts-into-that-memory
- we should not require the allocator object itself to track the sizes of=
=20
individual allocations

Alexandrescu's design also provides a naming convention for an optional=20
A::owns(P) operation:
- we should allow an allocator object to express "Yes, I know how to=20
deallocate this pointer", to enable composing multiple allocators together

It's not being proposed for standardization AFAIK (I could easily be=20
wrong), but it's a design that makes a lot of sense.

my $.02,
=E2=80=93Arthur

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

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

On Thursday, October 22, 2015 at 10:05:56 AM UTC-10, Ryan Nicholl wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I just wanted to=
 point out that there are some other, MUCH faster ways to implement memory =
allocation with almost no overhead.<br>In C, C++, you don&#39;t see these m=
ethods used because the memory API is incompatible with them... But it is p=
ossible that, provided there is a suitably sized block, we can guarantee bo=
th O(1) alloc and O(1) free, with O(1) memory allocator overhead for all al=
locations (excluding free blocks) and fixed % maximum block-size round-up o=
verhead. (This can be set very low, e.g. 1/8th excluding initial round-up t=
o nearest word size) In order to obtain this speed-up, we must provide the =
following API (names would change probably):<br><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008"=
>void</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*=
</span><span style=3D"color:#000"> alloc_fixed</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">size_t size</span><span style=3D"co=
lor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#008">void</span><span style=3D"color:#000"> =C2=A0 free_fixed</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#008">void</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span styl=
e=3D"color:#000"> mem</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> size_t size</span><span style=3D"color:#660">);</span></di=
v></code></div><br></div></blockquote><div>[...]</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">We need non-fixed size allocations=
, for that I suggest a new API as well:<br><br><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">std<=
/span><span style=3D"color:#660">::</span><span style=3D"color:#000">tuple<=
/span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*,</sp=
an><span style=3D"color:#000"> size_t</span><span style=3D"color:#660">&gt;=
</span><span style=3D"color:#000"> alloc_array</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">size_t size</span><span style=3D"co=
lor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#800">// Allocates an array of size or larger. Second return argument is=
 the actual size allocated.</span><span style=3D"color:#000"><br></span></d=
iv></code></div></div></blockquote><div>[...]</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x;word-wrap:break-word"><code><div><span style=3D"color:#000"></span><span =
style=3D"color:#008">void</span><span style=3D"color:#000"> free_array </sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#008">void</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span><spa=
n style=3D"color:#000"> mem</span><span style=3D"color:#660">);</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#800">// Self explani=
tory</span></div></code></div></div></blockquote><div><br></div><div>Surely=
 in this case you should be providing <font face=3D"courier new, monospace"=
>size_t size</font> to <font face=3D"courier new, monospace">free_array</fo=
nt> as well, since the caller by definition knows the size that was returne=
d from <font face=3D"courier new, monospace">alloc_array</font>.</div><div>=
<br></div><div>On the subject of &quot;allocator designs that make sense&qu=
ot;, I highly recommend watching Andrei Alexandrescu&#39;s talk from CppCon=
 2015:</div><div><a href=3D"https://www.youtube.com/watch?v=3DLIb3L4vKZ7U">=
https://www.youtube.com/watch?v=3DLIb3L4vKZ7U</a></div><div>The big wins IM=
HO, also mostly present in your design, are</div><div>- we should separate =
allocation-of-memory from construction/destruction-of-Ts-into-that-memory</=
div><div>- we should not require the allocator object itself to track the s=
izes of individual allocations</div><div><br></div><div>Alexandrescu&#39;s =
design also provides a naming convention for an optional <font face=3D"cour=
ier new, monospace">A::owns(P)</font> operation:</div><div>- we should allo=
w an allocator object to express &quot;Yes, I know how to deallocate this p=
ointer&quot;, to enable composing multiple allocators together</div><div><b=
r></div><div>It&#39;s not being proposed for standardization AFAIK (I could=
 easily be wrong), but it&#39;s a design that makes a lot of sense.</div><d=
iv><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1567_1289961239.1445557046803--
------=_Part_1566_782547938.1445557046803--

.