------=_Part_3002_1469614887.1460873953304
Content-Type: multipart/alternative;
 boundary="----=_Part_3003_350879216.1460873953305"

------=_Part_3003_350879216.1460873953305
Content-Type: text/plain; charset=UTF-8

Hello std-proposals, I was recently experimenting with stateful allocators,
such as stack_alloc[1], and standard containers.

During my experiment I've noticed an inefficiency: even when all
allocations made by a container were within my custom memory arena and
therefore could be deallocated at end of scope all together with the arena
instance, container's destructor had no way of knowing that it was allowed
to abandon memory safely and save cycles. Especially in case of
map/set/unordered_map/unordered_set, deallocations can have noticeable cost
and be not cache-friendly, because they have to traverse memory
non-linearly jumping through tree or linked list nodes.

Maybe standard containers should provide a way to relax the deallocation
logic to avoid redundant traversal of the container in destructor?

I know I'm not the only person on this planet who saw the need for this
operation, because I found the following method declared on red-black-tree
and several containers in EASTL[2]:

template <typename K, typename V, typename C, typename A, typename E, bool
bM, bool bU>
inline void rbtree<K, V, C, A, E, bM, bU>::reset_lose_memory()
{
// The reset_lose_memory function is a special extension function which
unilaterally
// resets the container to an empty state without freeing the memory of
// the contained objects. This is useful for very quickly tearing down a
// container built into scratch memory.
mAnchor.mpNodeRight  = &mAnchor;
mAnchor.mpNodeLeft   = &mAnchor;
mAnchor.mpNodeParent = NULL;
mAnchor.mColor       = kRBTreeColorRed;
mnSize               = 0;
}


Having a method on containers is one option, alternatively maybe it can be
a method on the allocator, which would tell the container if it is allowed
to not call "deallocate" for all the memory it had so far allocated?..

Was this considered before? Is it a worthy proposal?

[1] https://howardhinnant.github.io/stack_alloc.html
[2]
https://github.com/electronicarts/EASTL/blob/master/include/EASTL/internal/red_black_tree.h

---
Max Galkin

--
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/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1%40isocpp.org.

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

<div dir=3D"ltr"><div>Hello std-proposals, I was recently experimenting wit=
h stateful allocators, such as stack_alloc[1], and standard containers.<br>=
</div><div><br></div><div>During my experiment I&#39;ve noticed an ineffici=
ency: even when all allocations made by a container were within my custom m=
emory arena and therefore could be deallocated at end of scope all together=
 with the arena instance, container&#39;s destructor had no way of knowing =
that it was allowed to abandon memory safely and save cycles. Especially in=
 case of map/set/unordered_map/unordered_set, deallocations can have notice=
able cost and be not cache-friendly, because they have to traverse memory n=
on-linearly jumping through tree or linked list nodes.</div><div><br></div>=
<div>Maybe standard containers should provide a way to relax the deallocati=
on logic to avoid redundant traversal of the container in destructor?</div>=
<div><br></div><div>I know I&#39;m not the only person on this planet who s=
aw the need for this operation, because I found the following method declar=
ed on red-black-tree and several containers in EASTL[2]:</div><div><br></di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>tem=
plate &lt;typename K, typename V, typename C, typename A, typename E, bool =
bM, bool bU&gt;</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>inline void rbtree&lt;K, V, C, A, E, bM, bU&gt;::reset_lose=
_memory()</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre=
"> </span>{</div><div><span class=3D"Apple-tab-span" style=3D"white-space:p=
re">  </span>// The reset_lose_memory function is a special extension funct=
ion which unilaterally=C2=A0</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">  </span>// resets the container to an empty state wit=
hout freeing the memory of=C2=A0</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">  </span>// the contained objects. This is useful =
for very quickly tearing down a=C2=A0</div><div><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre">  </span>// container built into scratch memo=
ry.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </=
span>mAnchor.mpNodeRight =C2=A0=3D &amp;mAnchor;</div><div><span class=3D"A=
pple-tab-span" style=3D"white-space:pre">  </span>mAnchor.mpNodeLeft =C2=A0=
 =3D &amp;mAnchor;</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">  </span>mAnchor.mpNodeParent =3D NULL;</div><div><span class=3D=
"Apple-tab-span" style=3D"white-space:pre">  </span>mAnchor.mColor =C2=A0 =
=C2=A0 =C2=A0 =3D kRBTreeColorRed;</div><div><span class=3D"Apple-tab-span"=
 style=3D"white-space:pre">  </span>mnSize =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =3D 0;</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre"> </span>}</div><div><br></div><div><br></div><div>Having a=
 method on containers is one option, alternatively maybe it can be a method=
 on the allocator, which would tell the container if it is allowed to not c=
all &quot;deallocate&quot; for all the memory it had so far allocated?..</d=
iv><div><br></div><div>Was this considered before? Is it a worthy proposal?=
</div><div><br></div><div>[1] https://howardhinnant.github.io/stack_alloc.h=
tml</div><div>[2] https://github.com/electronicarts/EASTL/blob/master/inclu=
de/EASTL/internal/red_black_tree.h</div><div><br></div><div>---</div><div>M=
ax Galkin</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1=
%40isocpp.org</a>.<br />

------=_Part_3003_350879216.1460873953305--
------=_Part_3002_1469614887.1460873953304--

.

--001a113ecb1ac103fe0530ada50f
Content-Type: text/plain; charset=UTF-8

Wouldn't the traversal be required still (in general) for the calls to
destroy(), even if deallocate() is a noop? Unless we target this towards
types that do not need their destructors to be called and check that
through traits on the contained type from the containers' functions...


2016-04-17 2:19 GMT-04:00 Max Galkin <maksim.galkin@gmail.com>:

> Hello std-proposals, I was recently experimenting with stateful
> allocators, such as stack_alloc[1], and standard containers.
>
> During my experiment I've noticed an inefficiency: even when all
> allocations made by a container were within my custom memory arena and
> therefore could be deallocated at end of scope all together with the arena
> instance, container's destructor had no way of knowing that it was allowed
> to abandon memory safely and save cycles. Especially in case of
> map/set/unordered_map/unordered_set, deallocations can have noticeable cost
> and be not cache-friendly, because they have to traverse memory
> non-linearly jumping through tree or linked list nodes.
>
> Maybe standard containers should provide a way to relax the deallocation
> logic to avoid redundant traversal of the container in destructor?
>
> I know I'm not the only person on this planet who saw the need for this
> operation, because I found the following method declared on red-black-tree
> and several containers in EASTL[2]:
>
> template <typename K, typename V, typename C, typename A, typename E, bool
> bM, bool bU>
> inline void rbtree<K, V, C, A, E, bM, bU>::reset_lose_memory()
> {
> // The reset_lose_memory function is a special extension function which
> unilaterally
> // resets the container to an empty state without freeing the memory of
> // the contained objects. This is useful for very quickly tearing down a
> // container built into scratch memory.
> mAnchor.mpNodeRight  = &mAnchor;
> mAnchor.mpNodeLeft   = &mAnchor;
> mAnchor.mpNodeParent = NULL;
> mAnchor.mColor       = kRBTreeColorRed;
> mnSize               = 0;
> }
>
>
> Having a method on containers is one option, alternatively maybe it can be
> a method on the allocator, which would tell the container if it is allowed
> to not call "deallocate" for all the memory it had so far allocated?..
>
> Was this considered before? Is it a worthy proposal?
>
> [1] https://howardhinnant.github.io/stack_alloc.html
> [2]
> https://github.com/electronicarts/EASTL/blob/master/include/EASTL/internal/red_black_tree.h
>
> ---
> Max Galkin
>
> --
> 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/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAKiZDp2kpp9fPwfUZy4SybQoguYPWcymWZTxnUm66c4ck_%2BZfw%40mail.gmail.com.

--001a113ecb1ac103fe0530ada50f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Wouldn&#39;t the traversal be required still (in gene=
ral) for the calls to destroy(), even if deallocate() is a noop? Unless we =
target this towards types that do not need their destructors to be called a=
nd check that through traits on the contained type from the containers&#39;=
 functions...<br><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">2016-04-17 2:19 GMT-04:00 Max Galkin <span dir=3D"ltr">&lt=
;<a href=3D"mailto:maksim.galkin@gmail.com" target=3D"_blank">maksim.galkin=
@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>Hello std-proposals, I was recently experimenting with stateful all=
ocators, such as stack_alloc[1], and standard containers.<br></div><div><br=
></div><div>During my experiment I&#39;ve noticed an inefficiency: even whe=
n all allocations made by a container were within my custom memory arena an=
d therefore could be deallocated at end of scope all together with the aren=
a instance, container&#39;s destructor had no way of knowing that it was al=
lowed to abandon memory safely and save cycles. Especially in case of map/s=
et/unordered_map/unordered_set, deallocations can have noticeable cost and =
be not cache-friendly, because they have to traverse memory non-linearly ju=
mping through tree or linked list nodes.</div><div><br></div><div>Maybe sta=
ndard containers should provide a way to relax the deallocation logic to av=
oid redundant traversal of the container in destructor?</div><div><br></div=
><div>I know I&#39;m not the only person on this planet who saw the need fo=
r this operation, because I found the following method declared on red-blac=
k-tree and several containers in EASTL[2]:</div><div><br></div><div><span s=
tyle=3D"white-space:pre-wrap"> </span>template &lt;typename K, typename V, =
typename C, typename A, typename E, bool bM, bool bU&gt;</div><div><span st=
yle=3D"white-space:pre-wrap"> </span>inline void rbtree&lt;K, V, C, A, E, b=
M, bU&gt;::reset_lose_memory()</div><div><span style=3D"white-space:pre-wra=
p"> </span>{</div><div><span style=3D"white-space:pre-wrap">  </span>// The=
 reset_lose_memory function is a special extension function which unilatera=
lly=C2=A0</div><div><span style=3D"white-space:pre-wrap">  </span>// resets=
 the container to an empty state without freeing the memory of=C2=A0</div><=
div><span style=3D"white-space:pre-wrap">  </span>// the contained objects.=
 This is useful for very quickly tearing down a=C2=A0</div><div><span style=
=3D"white-space:pre-wrap">  </span>// container built into scratch memory.<=
/div><div><span style=3D"white-space:pre-wrap">  </span>mAnchor.mpNodeRight=
 =C2=A0=3D &amp;mAnchor;</div><div><span style=3D"white-space:pre-wrap">  <=
/span>mAnchor.mpNodeLeft =C2=A0 =3D &amp;mAnchor;</div><div><span style=3D"=
white-space:pre-wrap">  </span>mAnchor.mpNodeParent =3D NULL;</div><div><sp=
an style=3D"white-space:pre-wrap">  </span>mAnchor.mColor =C2=A0 =C2=A0 =C2=
=A0 =3D kRBTreeColorRed;</div><div><span style=3D"white-space:pre-wrap">  <=
/span>mnSize =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0;</div><=
div><span style=3D"white-space:pre-wrap"> </span>}</div><div><br></div><div=
><br></div><div>Having a method on containers is one option, alternatively =
maybe it can be a method on the allocator, which would tell the container i=
f it is allowed to not call &quot;deallocate&quot; for all the memory it ha=
d so far allocated?..</div><div><br></div><div>Was this considered before? =
Is it a worthy proposal?</div><div><br></div><div>[1] <a href=3D"https://ho=
wardhinnant.github.io/stack_alloc.html" target=3D"_blank">https://howardhin=
nant.github.io/stack_alloc.html</a></div><div>[2] <a href=3D"https://github=
..com/electronicarts/EASTL/blob/master/include/EASTL/internal/red_black_tree=
..h" target=3D"_blank">https://github.com/electronicarts/EASTL/blob/master/i=
nclude/EASTL/internal/red_black_tree.h</a></div><div><br></div><div>---</di=
v><div>Max Galkin</div><span class=3D"HOEnZb"><font color=3D"#888888"><div>=
<br></div></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888=
">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/c04cee6f-5a30-40cf-a3e4-0f21d3425ea1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c04cee6f-5a30-=
40cf-a3e4-0f21d3425ea1%40isocpp.org</a>.<br>
</font></span></blockquote></div><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/CAKiZDp2kpp9fPwfUZy4SybQoguYPWcymWZTx=
nUm66c4ck_%2BZfw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2kpp9fPw=
fUZy4SybQoguYPWcymWZTxnUm66c4ck_%2BZfw%40mail.gmail.com</a>.<br />

--001a113ecb1ac103fe0530ada50f--

.

--Apple-Mail-97835049-B514-4898-88EE-8E16303BE524
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If you take the view that the objects within the released memory live forev=
er, as is essentially what garbage collection does, there is no need to des=
troy any object. Assuming the objects thus treated don't contain any non-me=
mory resource there is no need to destroy them. After all, they are concept=
ually still alive. They are just never referenced again and the memory they=
 occupied can be used for something else.

Some if the allocators in BDE (see e.g. https://github.com/bloomberg/bde/bl=
ob/master/groups/bdl/bdlma/bdlma_multipoolallocator.h ) have a release() me=
mber which simply releases all memory currently in use by the allocator. Th=
e main constraint is that you can't release the memory if there is an aouto=
matically managed object (e.g., an object on the stack) would later clean u=
p the memmory. Allocating such objects with the same allocator conveniently=
 avoids this problem entirely.

The upshot is that the object release for corresponding objects becomes an =
allocator thing. As long as the correct allocator is used there isn't even =
a need to use smart pointers to track object lifetime further lowering the =
needs to touch memory unrelated to the actual business processing (e.g., th=
e synchronized reference counts of a std::shared_ptr<T>). This approach can=
 yield nice improvements, e.g., in contexts where it is typical to build up=
 data structures which are short lived like while processing a request in a=
 setver.

The main caveats with this approach are

 1. The allocators need to be used correctly. If an object thus released al=
located memory using a different allocator this memory isn't recovered.
 2. Any non-memory resource held by an object isn't released.=20

Correct use of allocators can be verified with a static analyser.  I think =
that verifying that no destructor is needed (orher than to release memory) =
may require annotation for objects which do have a destructor but where the=
 destructor is only required to release memory. Of course, it assumed that =
all memory allocations/deallocations happen using the correct allocator.

> On 17 Apr 2016, at 13:47, Patrice Roy <patricer@gmail.com> wrote:
>=20
> Wouldn't the traversal be required still (in general) for the calls to de=
stroy(), even if deallocate() is a noop? Unless we target this towards type=
s that do not need their destructors to be called and check that through tr=
aits on the contained type from the containers' functions...
>=20
>=20
> 2016-04-17 2:19 GMT-04:00 Max Galkin <maksim.galkin@gmail.com>:
>> Hello std-proposals, I was recently experimenting with stateful allocato=
rs, such as stack_alloc[1], and standard containers.
>>=20
>> During my experiment I've noticed an inefficiency: even when all allocat=
ions made by a container were within my custom memory arena and therefore c=
ould be deallocated at end of scope all together with the arena instance, c=
ontainer's destructor had no way of knowing that it was allowed to abandon =
memory safely and save cycles. Especially in case of map/set/unordered_map/=
unordered_set, deallocations can have noticeable cost and be not cache-frie=
ndly, because they have to traverse memory non-linearly jumping through tre=
e or linked list nodes.
>>=20
>> Maybe standard containers should provide a way to relax the deallocation=
 logic to avoid redundant traversal of the container in destructor?
>>=20
>> I know I'm not the only person on this planet who saw the need for this =
operation, because I found the following method declared on red-black-tree =
and several containers in EASTL[2]:
>>=20
>>  template <typename K, typename V, typename C, typename A, typename E, b=
ool bM, bool bU>
>>  inline void rbtree<K, V, C, A, E, bM, bU>::reset_lose_memory()
>>  {
>>   // The reset_lose_memory function is a special extension function whic=
h unilaterally=20
>>   // resets the container to an empty state without freeing the memory o=
f=20
>>   // the contained objects. This is useful for very quickly tearing down=
 a=20
>>   // container built into scratch memory.
>>   mAnchor.mpNodeRight  =3D &mAnchor;
>>   mAnchor.mpNodeLeft   =3D &mAnchor;
>>   mAnchor.mpNodeParent =3D NULL;
>>   mAnchor.mColor       =3D kRBTreeColorRed;
>>   mnSize               =3D 0;
>>  }
>>=20
>>=20
>> Having a method on containers is one option, alternatively maybe it can =
be a method on the allocator, which would tell the container if it is allow=
ed to not call "deallocate" for all the memory it had so far allocated?..
>>=20
>> Was this considered before? Is it a worthy proposal?
>>=20
>> [1] https://howardhinnant.github.io/stack_alloc.html
>> [2] https://github.com/electronicarts/EASTL/blob/master/include/EASTL/in=
ternal/red_black_tree.h

--=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/1AC3A78F-9769-4405-B618-C2C9DF878567%40gmail.com=
..

--Apple-Mail-97835049-B514-4898-88EE-8E16303BE524
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div>If you take the view th=
at the objects within the released memory live forever, as is essentially w=
hat garbage collection does, there is no need to destroy any object. Assumi=
ng the objects thus treated don't contain any non-memory resource there is =
no need to destroy them. After all, they are conceptually still alive. They=
 are just never referenced again and the memory they occupied can be used f=
or something else.</div><div><br></div><div>Some if the allocators in BDE (=
see e.g.&nbsp;<a href=3D"https://github.com/bloomberg/bde/blob/master/group=
s/bdl/bdlma/bdlma_multipoolallocator.h">https://github.com/bloomberg/bde/bl=
ob/master/groups/bdl/bdlma/bdlma_multipoolallocator.h</a> ) have a release(=
) member which simply releases all memory currently in use by the allocator=
.. The main constraint is that you can't release the memory if there is an a=
outomatically managed object (e.g., an object on the stack) would later cle=
an up the memmory. Allocating such objects with the same allocator convenie=
ntly avoids this problem entirely.</div><div><br></div><div>The upshot is t=
hat the object release for corresponding objects becomes an allocator thing=
.. As long as the correct allocator is used there isn't even a need to use s=
mart pointers to track object lifetime further lowering the needs to touch =
memory unrelated to the actual business processing (e.g., the synchronized =
reference counts of a std::shared_ptr&lt;T&gt;). This approach can yield ni=
ce improvements, e.g., in contexts where it is typical to build up data str=
uctures which are short lived like while processing a request in a setver.<=
/div><div><br></div><div>The main caveats with this approach are</div><div>=
<br></div><div>&nbsp;1. The allocators need to be used correctly. If an obj=
ect thus released allocated memory using a different allocator this memory =
isn't recovered.</div><div>&nbsp;2. Any non-memory resource held by an obje=
ct isn't released.&nbsp;</div><div><br></div><div>Correct use of allocators=
 can be verified with a static analyser. &nbsp;I think that verifying that =
no destructor is needed (orher than to release memory) may require annotati=
on for objects which do have a destructor but where the destructor is only =
required to release memory. Of course, it assumed that all memory allocatio=
ns/deallocations happen using the correct allocator.</div><div><br></div><d=
iv>On 17 Apr 2016, at 13:47, Patrice Roy &lt;<a href=3D"mailto:patricer@gma=
il.com">patricer@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"=
cite"><div dir=3D"ltr"><div>Wouldn't the traversal be required still (in ge=
neral) for the calls to destroy(), even if deallocate() is a noop? Unless w=
e target this towards types that do not need their destructors to be called=
 and check that through traits on the contained type from the containers' f=
unctions...<br><br></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2016-04-17 2:19 GMT-04:00 Max Galkin <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:maksim.galkin@gmail.com" target=3D"_blank">maksim.galkin@gm=
ail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Hello std-proposals, I was recently experimenting with stateful alloca=
tors, such as stack_alloc[1], and standard containers.<br></div><div><br></=
div><div>During my experiment I've noticed an inefficiency: even when all a=
llocations made by a container were within my custom memory arena and there=
fore could be deallocated at end of scope all together with the arena insta=
nce, container's destructor had no way of knowing that it was allowed to ab=
andon memory safely and save cycles. Especially in case of map/set/unordere=
d_map/unordered_set, deallocations can have noticeable cost and be not cach=
e-friendly, because they have to traverse memory non-linearly jumping throu=
gh tree or linked list nodes.</div><div><br></div><div>Maybe standard conta=
iners should provide a way to relax the deallocation logic to avoid redunda=
nt traversal of the container in destructor?</div><div><br></div><div>I kno=
w I'm not the only person on this planet who saw the need for this operatio=
n, because I found the following method declared on red-black-tree and seve=
ral containers in EASTL[2]:</div><div><br></div><div><span style=3D"white-s=
pace:pre-wrap"> </span>template &lt;typename K, typename V, typename C, typ=
ename A, typename E, bool bM, bool bU&gt;</div><div><span style=3D"white-sp=
ace:pre-wrap"> </span>inline void rbtree&lt;K, V, C, A, E, bM, bU&gt;::rese=
t_lose_memory()</div><div><span style=3D"white-space:pre-wrap"> </span>{</d=
iv><div><span style=3D"white-space:pre-wrap">  </span>// The reset_lose_mem=
ory function is a special extension function which unilaterally&nbsp;</div>=
<div><span style=3D"white-space:pre-wrap">  </span>// resets the container =
to an empty state without freeing the memory of&nbsp;</div><div><span style=
=3D"white-space:pre-wrap">  </span>// the contained objects. This is useful=
 for very quickly tearing down a&nbsp;</div><div><span style=3D"white-space=
:pre-wrap">  </span>// container built into scratch memory.</div><div><span=
 style=3D"white-space:pre-wrap">  </span>mAnchor.mpNodeRight &nbsp;=3D &amp=
;mAnchor;</div><div><span style=3D"white-space:pre-wrap">  </span>mAnchor.m=
pNodeLeft &nbsp; =3D &amp;mAnchor;</div><div><span style=3D"white-space:pre=
-wrap">  </span>mAnchor.mpNodeParent =3D NULL;</div><div><span style=3D"whi=
te-space:pre-wrap">  </span>mAnchor.mColor &nbsp; &nbsp; &nbsp; =3D kRBTree=
ColorRed;</div><div><span style=3D"white-space:pre-wrap">  </span>mnSize &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =3D 0;</div><div><span style=
=3D"white-space:pre-wrap"> </span>}</div><div><br></div><div><br></div><div=
>Having a method on containers is one option, alternatively maybe it can be=
 a method on the allocator, which would tell the container if it is allowed=
 to not call "deallocate" for all the memory it had so far allocated?..</di=
v><div><br></div><div>Was this considered before? Is it a worthy proposal?<=
/div><div><br></div><div>[1] <a href=3D"https://howardhinnant.github.io/sta=
ck_alloc.html" target=3D"_blank">https://howardhinnant.github.io/stack_allo=
c.html</a></div><div>[2] <a href=3D"https://github.com/electronicarts/EASTL=
/blob/master/include/EASTL/internal/red_black_tree.h" target=3D"_blank">htt=
ps://github.com/electronicarts/EASTL/blob/master/include/EASTL/internal/red=
_black_tree.h</a></div></div></blockquote></div></div>
</blockquote></body></html>

<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/1AC3A78F-9769-4405-B618-C2C9DF878567%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-9769-4405-B618-C2C9DF878567%=
40gmail.com</a>.<br />

--Apple-Mail-97835049-B514-4898-88EE-8E16303BE524--

.

--001a113acfc229bcbe0530aed039
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I understand that; it's the contained objects' finalization that won't get
done. It's not the memory not being released (the traversal that does noop
calls to deallocate) that's a bother here, as I can understand the interest
in avoiding this traversal when the memory is released as a single chunk
(or not at all, when it's a buffer on the stacl), but the destructors of
the individual objects thatm by not being called, would not get the
opoortunity to do their work (close files, sockets, do their own
memory-related things, etc.)

What I meant was: if we can avoid the deallocate traversal, which makes
sense to me, we'd still need (at least in some cases) to do a traversal
anyway to finalize (destroy()) the objects, which is a different thing
altogether.

I can see ways to avoid this traversal for objets that do not require
finalization, but it's traits-based and could be a bit involved; maybe
wrapping it in a low-level algorithm to keep things straightforward in user
code?

2016-04-17 9:57 GMT-04:00 Dietmar K=C3=BChl <dietmar.kuehl@gmail.com>:

> If you take the view that the objects within the released memory live
> forever, as is essentially what garbage collection does, there is no need
> to destroy any object. Assuming the objects thus treated don't contain an=
y
> non-memory resource there is no need to destroy them. After all, they are
> conceptually still alive. They are just never referenced again and the
> memory they occupied can be used for something else.
>
> Some if the allocators in BDE (see e.g.
> https://github.com/bloomberg/bde/blob/master/groups/bdl/bdlma/bdlma_multi=
poolallocator.h
> ) have a release() member which simply releases all memory currently in u=
se
> by the allocator. The main constraint is that you can't release the memor=
y
> if there is an aoutomatically managed object (e.g., an object on the stac=
k)
> would later clean up the memmory. Allocating such objects with the same
> allocator conveniently avoids this problem entirely.
>
> The upshot is that the object release for corresponding objects becomes a=
n
> allocator thing. As long as the correct allocator is used there isn't eve=
n
> a need to use smart pointers to track object lifetime further lowering th=
e
> needs to touch memory unrelated to the actual business processing (e.g.,
> the synchronized reference counts of a std::shared_ptr<T>). This approach
> can yield nice improvements, e.g., in contexts where it is typical to bui=
ld
> up data structures which are short lived like while processing a request =
in
> a setver.
>
> The main caveats with this approach are
>
>  1. The allocators need to be used correctly. If an object thus released
> allocated memory using a different allocator this memory isn't recovered.
>  2. Any non-memory resource held by an object isn't released.
>
> Correct use of allocators can be verified with a static analyser.  I thin=
k
> that verifying that no destructor is needed (orher than to release memory=
)
> may require annotation for objects which do have a destructor but where t=
he
> destructor is only required to release memory. Of course, it assumed that
> all memory allocations/deallocations happen using the correct allocator.
>
> On 17 Apr 2016, at 13:47, Patrice Roy <patricer@gmail.com> wrote:
>
> Wouldn't the traversal be required still (in general) for the calls to
> destroy(), even if deallocate() is a noop? Unless we target this towards
> types that do not need their destructors to be called and check that
> through traits on the contained type from the containers' functions...
>
>
> 2016-04-17 2:19 GMT-04:00 Max Galkin <maksim.galkin@gmail.com>:
>
>> Hello std-proposals, I was recently experimenting with stateful
>> allocators, such as stack_alloc[1], and standard containers.
>>
>> During my experiment I've noticed an inefficiency: even when all
>> allocations made by a container were within my custom memory arena and
>> therefore could be deallocated at end of scope all together with the are=
na
>> instance, container's destructor had no way of knowing that it was allow=
ed
>> to abandon memory safely and save cycles. Especially in case of
>> map/set/unordered_map/unordered_set, deallocations can have noticeable c=
ost
>> and be not cache-friendly, because they have to traverse memory
>> non-linearly jumping through tree or linked list nodes.
>>
>> Maybe standard containers should provide a way to relax the deallocation
>> logic to avoid redundant traversal of the container in destructor?
>>
>> I know I'm not the only person on this planet who saw the need for this
>> operation, because I found the following method declared on red-black-tr=
ee
>> and several containers in EASTL[2]:
>>
>> template <typename K, typename V, typename C, typename A, typename E,
>> bool bM, bool bU>
>> inline void rbtree<K, V, C, A, E, bM, bU>::reset_lose_memory()
>> {
>> // The reset_lose_memory function is a special extension function which
>> unilaterally
>> // resets the container to an empty state without freeing the memory of
>> // the contained objects. This is useful for very quickly tearing down a
>> // container built into scratch memory.
>> mAnchor.mpNodeRight  =3D &mAnchor;
>> mAnchor.mpNodeLeft   =3D &mAnchor;
>> mAnchor.mpNodeParent =3D NULL;
>> mAnchor.mColor       =3D kRBTreeColorRed;
>> mnSize               =3D 0;
>> }
>>
>>
>> Having a method on containers is one option, alternatively maybe it can
>> be a method on the allocator, which would tell the container if it is
>> allowed to not call "deallocate" for all the memory it had so far
>> allocated?..
>>
>> Was this considered before? Is it a worthy proposal?
>>
>> [1] https://howardhinnant.github.io/stack_alloc.html
>> [2]
>> https://github.com/electronicarts/EASTL/blob/master/include/EASTL/intern=
al/red_black_tree.h
>>
> --
> 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/1AC3A78F-976=
9-4405-B618-C2C9DF878567%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-97=
69-4405-B618-C2C9DF878567%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
> .
>

--=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/CAKiZDp3kZ4Xfb_2qVsAx5Ob7ZeZ-QWRxips-XpNfL13vTPZ=
Vjw%40mail.gmail.com.

--001a113acfc229bcbe0530aed039
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I understand that; it&#39;s the contained object=
s&#39; finalization that won&#39;t get done. It&#39;s not the memory not be=
ing released (the traversal that does noop calls to deallocate) that&#39;s =
a bother here, as I can understand the interest in avoiding this traversal =
when the memory is released as a single chunk (or not at all, when it&#39;s=
 a buffer on the stacl), but the destructors of the individual objects that=
m by not being called, would not get the opoortunity to do their work (clos=
e files, sockets, do their own memory-related things, etc.)<br><br></div>Wh=
at I meant was: if we can avoid the deallocate traversal, which makes sense=
 to me, we&#39;d still need (at least in some cases) to do a traversal anyw=
ay to finalize (destroy()) the objects, which is a different thing altogeth=
er.<br><br></div>I can see ways to avoid this traversal for objets that do =
not require finalization, but it&#39;s traits-based and could be a bit invo=
lved; maybe wrapping it in a low-level algorithm to keep things straightfor=
ward in user code?<br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2016-04-17 9:57 GMT-04:00 Dietmar K=C3=BChl <span dir=3D"ltr">&l=
t;<a href=3D"mailto:dietmar.kuehl@gmail.com" target=3D"_blank">dietmar.kueh=
l@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"a=
uto"><div></div><div>If you take the view that the objects within the relea=
sed memory live forever, as is essentially what garbage collection does, th=
ere is no need to destroy any object. Assuming the objects thus treated don=
&#39;t contain any non-memory resource there is no need to destroy them. Af=
ter all, they are conceptually still alive. They are just never referenced =
again and the memory they occupied can be used for something else.</div><di=
v><br></div><div>Some if the allocators in BDE (see e.g.=C2=A0<a href=3D"ht=
tps://github.com/bloomberg/bde/blob/master/groups/bdl/bdlma/bdlma_multipool=
allocator.h" target=3D"_blank">https://github.com/bloomberg/bde/blob/master=
/groups/bdl/bdlma/bdlma_multipoolallocator.h</a> ) have a release() member =
which simply releases all memory currently in use by the allocator. The mai=
n constraint is that you can&#39;t release the memory if there is an aoutom=
atically managed object (e.g., an object on the stack) would later clean up=
 the memmory. Allocating such objects with the same allocator conveniently =
avoids this problem entirely.</div><div><br></div><div>The upshot is that t=
he object release for corresponding objects becomes an allocator thing. As =
long as the correct allocator is used there isn&#39;t even a need to use sm=
art pointers to track object lifetime further lowering the needs to touch m=
emory unrelated to the actual business processing (e.g., the synchronized r=
eference counts of a std::shared_ptr&lt;T&gt;). This approach can yield nic=
e improvements, e.g., in contexts where it is typical to build up data stru=
ctures which are short lived like while processing a request in a setver.</=
div><div><br></div><div>The main caveats with this approach are</div><div><=
br></div><div>=C2=A01. The allocators need to be used correctly. If an obje=
ct thus released allocated memory using a different allocator this memory i=
sn&#39;t recovered.</div><div>=C2=A02. Any non-memory resource held by an o=
bject isn&#39;t released.=C2=A0</div><div><br></div><div>Correct use of all=
ocators can be verified with a static analyser.=C2=A0 I think that verifyin=
g that no destructor is needed (orher than to release memory) may require a=
nnotation for objects which do have a destructor but where the destructor i=
s only required to release memory. Of course, it assumed that all memory al=
locations/deallocations happen using the correct allocator.</div><span clas=
s=3D""><div><br></div><div>On 17 Apr 2016, at 13:47, Patrice Roy &lt;<a hre=
f=3D"mailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>&gt=
; wrote:<br><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Would=
n&#39;t the traversal be required still (in general) for the calls to destr=
oy(), even if deallocate() is a noop? Unless we target this towards types t=
hat do not need their destructors to be called and check that through trait=
s on the contained type from the containers&#39; functions...<br><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-04-17 =
2:19 GMT-04:00 Max Galkin <span dir=3D"ltr">&lt;<a href=3D"mailto:maksim.ga=
lkin@gmail.com" target=3D"_blank">maksim.galkin@gmail.com</a>&gt;</span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hello std-proposals,=
 I was recently experimenting with stateful allocators, such as stack_alloc=
[1], and standard containers.<br></div><div><br></div><div>During my experi=
ment I&#39;ve noticed an inefficiency: even when all allocations made by a =
container were within my custom memory arena and therefore could be dealloc=
ated at end of scope all together with the arena instance, container&#39;s =
destructor had no way of knowing that it was allowed to abandon memory safe=
ly and save cycles. Especially in case of map/set/unordered_map/unordered_s=
et, deallocations can have noticeable cost and be not cache-friendly, becau=
se they have to traverse memory non-linearly jumping through tree or linked=
 list nodes.</div><div><br></div><div>Maybe standard containers should prov=
ide a way to relax the deallocation logic to avoid redundant traversal of t=
he container in destructor?</div><div><br></div><div>I know I&#39;m not the=
 only person on this planet who saw the need for this operation, because I =
found the following method declared on red-black-tree and several container=
s in EASTL[2]:</div><div><br></div><div><span style=3D"white-space:pre-wrap=
"> </span>template &lt;typename K, typename V, typename C, typename A, type=
name E, bool bM, bool bU&gt;</div><div><span style=3D"white-space:pre-wrap"=
> </span>inline void rbtree&lt;K, V, C, A, E, bM, bU&gt;::reset_lose_memory=
()</div><div><span style=3D"white-space:pre-wrap"> </span>{</div><div><span=
 style=3D"white-space:pre-wrap">  </span>// The reset_lose_memory function =
is a special extension function which unilaterally=C2=A0</div><div><span st=
yle=3D"white-space:pre-wrap">  </span>// resets the container to an empty s=
tate without freeing the memory of=C2=A0</div><div><span style=3D"white-spa=
ce:pre-wrap">  </span>// the contained objects. This is useful for very qui=
ckly tearing down a=C2=A0</div><div><span style=3D"white-space:pre-wrap">  =
</span>// container built into scratch memory.</div><div><span style=3D"whi=
te-space:pre-wrap">  </span>mAnchor.mpNodeRight =C2=A0=3D &amp;mAnchor;</di=
v><div><span style=3D"white-space:pre-wrap">  </span>mAnchor.mpNodeLeft =C2=
=A0 =3D &amp;mAnchor;</div><div><span style=3D"white-space:pre-wrap">  </sp=
an>mAnchor.mpNodeParent =3D NULL;</div><div><span style=3D"white-space:pre-=
wrap">  </span>mAnchor.mColor =C2=A0 =C2=A0 =C2=A0 =3D kRBTreeColorRed;</di=
v><div><span style=3D"white-space:pre-wrap">  </span>mnSize =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0;</div><div><span style=3D"white-sp=
ace:pre-wrap"> </span>}</div><div><br></div><div><br></div><div>Having a me=
thod on containers is one option, alternatively maybe it can be a method on=
 the allocator, which would tell the container if it is allowed to not call=
 &quot;deallocate&quot; for all the memory it had so far allocated?..</div>=
<div><br></div><div>Was this considered before? Is it a worthy proposal?</d=
iv><div><br></div><div>[1] <a href=3D"https://howardhinnant.github.io/stack=
_alloc.html" target=3D"_blank">https://howardhinnant.github.io/stack_alloc.=
html</a></div><div>[2] <a href=3D"https://github.com/electronicarts/EASTL/b=
lob/master/include/EASTL/internal/red_black_tree.h" target=3D"_blank">https=
://github.com/electronicarts/EASTL/blob/master/include/EASTL/internal/red_b=
lack_tree.h</a></div></div></blockquote></div></div>
</blockquote></span></div>

<p></p>

-- <br><span class=3D"">
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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-9769-4405-B618-C2C9DF878567%=
40gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-9769-4=
405-B618-C2C9DF878567%40gmail.com</a>.<br>
</blockquote></div><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/CAKiZDp3kZ4Xfb_2qVsAx5Ob7ZeZ-QWRxips-=
XpNfL13vTPZVjw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3kZ4Xfb_2q=
VsAx5Ob7ZeZ-QWRxips-XpNfL13vTPZVjw%40mail.gmail.com</a>.<br />

--001a113acfc229bcbe0530aed039--

.

------=_Part_169_2047981761.1460913677653
Content-Type: multipart/alternative;
 boundary="----=_Part_170_450870264.1460913677657"

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

I can so far see 2 ways to approach this:

1. Add something like "abandon_and_clear()" method on e.g. std::map, and=20
leave the burden of ensuring correctness in each specific case to=20
application developers :)  The benefit would be simplicity of=20
implementation, and also it'd give developers more control over when to=20
apply this approach, and let them apply it even when a map stores some=20
non-trivial values, but for which they know they don't need to run the=20
destructors (maybe the values are allocated from a different pool, but can=
=20
also be abandoned).
 =20
2. Come up with a list of conditions and traits for key_type, value_type=20
and allocator_type, and abandon memory in destructor (or on .clear()) only=
=20
when all those conditions are met and thus memory safety is guaranteed by=
=20
compiler in this scenario. E.g. key_type and value_type must either be=20
"trivial" (if my understanding of "trivial" is correct -- they'd have no=20
user-defined destructor) or use the same allocator as used by the=20
container, and not use any other allocators (not sure if we have any=20
standard way of expressing such trait). I think if we can express this,=20
then std::map<std::string, std::vector> can abandon memory in a safe manner=
=20
when allocator permits.

Maybe even both ways should be supported?

I'm also curious if there's any other approach -- maybe via some new kind=
=20
of "smart pointers" returned from allocator? Although we don't want to=20
examine each allocated pointer, that'd defeat the purpose. What container=
=20
needs to know is part of allocator's static contract and part of its=20
dynamic state.

Max


On Sunday, April 17, 2016 at 7:11:00 AM UTC-7, Patrice Roy wrote:
>
> I understand that; it's the contained objects' finalization that won't ge=
t=20
> done. It's not the memory not being released (the traversal that does noo=
p=20
> calls to deallocate) that's a bother here, as I can understand the intere=
st=20
> in avoiding this traversal when the memory is released as a single chunk=
=20
> (or not at all, when it's a buffer on the stacl), but the destructors of=
=20
> the individual objects thatm by not being called, would not get the=20
> opoortunity to do their work (close files, sockets, do their own=20
> memory-related things, etc.)
>
> What I meant was: if we can avoid the deallocate traversal, which makes=
=20
> sense to me, we'd still need (at least in some cases) to do a traversal=
=20
> anyway to finalize (destroy()) the objects, which is a different thing=20
> altogether.
>
> I can see ways to avoid this traversal for objets that do not require=20
> finalization, but it's traits-based and could be a bit involved; maybe=20
> wrapping it in a low-level algorithm to keep things straightforward in us=
er=20
> code?
>
> 2016-04-17 9:57 GMT-04:00 Dietmar K=C3=BChl <dietma...@gmail.com <javascr=
ipt:>>
> :
>
>> If you take the view that the objects within the released memory live=20
>> forever, as is essentially what garbage collection does, there is no nee=
d=20
>> to destroy any object. Assuming the objects thus treated don't contain a=
ny=20
>> non-memory resource there is no need to destroy them. After all, they ar=
e=20
>> conceptually still alive. They are just never referenced again and the=
=20
>> memory they occupied can be used for something else.
>>
>> Some if the allocators in BDE (see e.g.=20
>> https://github.com/bloomberg/bde/blob/master/groups/bdl/bdlma/bdlma_mult=
ipoolallocator.h=20
>> ) have a release() member which simply releases all memory currently in =
use=20
>> by the allocator. The main constraint is that you can't release the memo=
ry=20
>> if there is an aoutomatically managed object (e.g., an object on the sta=
ck)=20
>> would later clean up the memmory. Allocating such objects with the same=
=20
>> allocator conveniently avoids this problem entirely.
>>
>> The upshot is that the object release for corresponding objects becomes=
=20
>> an allocator thing. As long as the correct allocator is used there isn't=
=20
>> even a need to use smart pointers to track object lifetime further lower=
ing=20
>> the needs to touch memory unrelated to the actual business processing=20
>> (e.g., the synchronized reference counts of a std::shared_ptr<T>). This=
=20
>> approach can yield nice improvements, e.g., in contexts where it is typi=
cal=20
>> to build up data structures which are short lived like while processing =
a=20
>> request in a setver.
>>
>> The main caveats with this approach are
>>
>>  1. The allocators need to be used correctly. If an object thus released=
=20
>> allocated memory using a different allocator this memory isn't recovered=
..
>>  2. Any non-memory resource held by an object isn't released.=20
>>
>> Correct use of allocators can be verified with a static analyser.  I=20
>> think that verifying that no destructor is needed (orher than to release=
=20
>> memory) may require annotation for objects which do have a destructor bu=
t=20
>> where the destructor is only required to release memory. Of course, it=
=20
>> assumed that all memory allocations/deallocations happen using the corre=
ct=20
>> allocator.
>>
>> On 17 Apr 2016, at 13:47, Patrice Roy <patr...@gmail.com <javascript:>>=
=20
>> wrote:
>>
>> Wouldn't the traversal be required still (in general) for the calls to=
=20
>> destroy(), even if deallocate() is a noop? Unless we target this towards=
=20
>> types that do not need their destructors to be called and check that=20
>> through traits on the contained type from the containers' functions...
>>
>>
>> 2016-04-17 2:19 GMT-04:00 Max Galkin <maksim...@gmail.com <javascript:>>=
:
>>
>>> Hello std-proposals, I was recently experimenting with stateful=20
>>> allocators, such as stack_alloc[1], and standard containers.
>>>
>>> During my experiment I've noticed an inefficiency: even when all=20
>>> allocations made by a container were within my custom memory arena and=
=20
>>> therefore could be deallocated at end of scope all together with the ar=
ena=20
>>> instance, container's destructor had no way of knowing that it was allo=
wed=20
>>> to abandon memory safely and save cycles. Especially in case of=20
>>> map/set/unordered_map/unordered_set, deallocations can have noticeable =
cost=20
>>> and be not cache-friendly, because they have to traverse memory=20
>>> non-linearly jumping through tree or linked list nodes.
>>>
>>> Maybe standard containers should provide a way to relax the deallocatio=
n=20
>>> logic to avoid redundant traversal of the container in destructor?
>>>
>>> I know I'm not the only person on this planet who saw the need for this=
=20
>>> operation, because I found the following method declared on red-black-t=
ree=20
>>> and several containers in EASTL[2]:
>>>
>>> template <typename K, typename V, typename C, typename A, typename E,=
=20
>>> bool bM, bool bU>
>>> inline void rbtree<K, V, C, A, E, bM, bU>::reset_lose_memory()
>>> {
>>> // The reset_lose_memory function is a special extension function which=
=20
>>> unilaterally=20
>>> // resets the container to an empty state without freeing the memory of=
=20
>>> // the contained objects. This is useful for very quickly tearing down =
a=20
>>> // container built into scratch memory.
>>> mAnchor.mpNodeRight  =3D &mAnchor;
>>> mAnchor.mpNodeLeft   =3D &mAnchor;
>>> mAnchor.mpNodeParent =3D NULL;
>>> mAnchor.mColor       =3D kRBTreeColorRed;
>>> mnSize               =3D 0;
>>> }
>>>
>>>
>>> Having a method on containers is one option, alternatively maybe it can=
=20
>>> be a method on the allocator, which would tell the container if it is=
=20
>>> allowed to not call "deallocate" for all the memory it had so far=20
>>> allocated?..
>>>
>>> Was this considered before? Is it a worthy proposal?
>>>
>>> [1] https://howardhinnant.github.io/stack_alloc.html
>>> [2]=20
>>> https://github.com/electronicarts/EASTL/blob/master/include/EASTL/inter=
nal/red_black_tree.h
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-97=
69-4405-B618-C2C9DF878567%40gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-9=
769-4405-B618-C2C9DF878567%40gmail.com?utm_medium=3Demail&utm_source=3Dfoot=
er>
>> .
>>
>
>

--=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/98158978-a840-46b5-a5b1-ef71c45a54d9%40isocpp.or=
g.

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

<div dir=3D"ltr">I can so far see 2 ways to approach this:<div><br></div><d=
iv>1. Add something like &quot;abandon_and_clear()&quot; method on e.g. std=
::map, and leave the burden of ensuring correctness in each specific case t=
o application developers :) =C2=A0The benefit would be simplicity of implem=
entation, and also it&#39;d give developers more control over when to apply=
 this approach, and let them apply it even when a map stores some non-trivi=
al values, but for which they know they don&#39;t need to run the destructo=
rs (maybe the values are allocated from a different pool, but can also be a=
bandoned).</div><div>=C2=A0=C2=A0</div><div>2. Come up with a list of condi=
tions and traits for key_type, value_type and allocator_type, and abandon m=
emory in destructor (or on .clear()) only when all those conditions are met=
 and thus memory safety is guaranteed by compiler in this scenario. E.g. ke=
y_type and value_type must either be &quot;trivial&quot; (if my understandi=
ng of &quot;trivial&quot; is correct -- they&#39;d have no user-defined des=
tructor) or use the same allocator as used by the container, and not use an=
y other allocators (not sure if we have any standard way of expressing such=
 trait). I think if we can express this, then std::map&lt;std::string, std:=
:vector&gt; can abandon memory in a safe manner when allocator permits.</di=
v><div><br></div><div>Maybe even both ways should be supported?</div><div><=
br></div><div>I&#39;m also curious if there&#39;s any other approach -- may=
be via some new kind of &quot;smart pointers&quot; returned from allocator?=
 Although we don&#39;t want to examine each allocated pointer, that&#39;d d=
efeat the purpose. What container needs to know is part of allocator&#39;s =
static contract and part of its dynamic state.</div><div><br></div><div>Max=
<br><br><br>On Sunday, April 17, 2016 at 7:11:00 AM UTC-7, Patrice Roy wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>I=
 understand that; it&#39;s the contained objects&#39; finalization that won=
&#39;t get done. It&#39;s not the memory not being released (the traversal =
that does noop calls to deallocate) that&#39;s a bother here, as I can unde=
rstand the interest in avoiding this traversal when the memory is released =
as a single chunk (or not at all, when it&#39;s a buffer on the stacl), but=
 the destructors of the individual objects thatm by not being called, would=
 not get the opoortunity to do their work (close files, sockets, do their o=
wn memory-related things, etc.)<br><br></div>What I meant was: if we can av=
oid the deallocate traversal, which makes sense to me, we&#39;d still need =
(at least in some cases) to do a traversal anyway to finalize (destroy()) t=
he objects, which is a different thing altogether.<br><br></div>I can see w=
ays to avoid this traversal for objets that do not require finalization, bu=
t it&#39;s traits-based and could be a bit involved; maybe wrapping it in a=
 low-level algorithm to keep things straightforward in user code?<br></div>=
<div><br><div class=3D"gmail_quote">2016-04-17 9:57 GMT-04:00 Dietmar K=C3=
=BChl <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"s3EzxbtYBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">dietma...@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"auto"><div></div><div>If you take the view th=
at the objects within the released memory live forever, as is essentially w=
hat garbage collection does, there is no need to destroy any object. Assumi=
ng the objects thus treated don&#39;t contain any non-memory resource there=
 is no need to destroy them. After all, they are conceptually still alive. =
They are just never referenced again and the memory they occupied can be us=
ed for something else.</div><div><br></div><div>Some if the allocators in B=
DE (see e.g.=C2=A0<a href=3D"https://github.com/bloomberg/bde/blob/master/g=
roups/bdl/bdlma/bdlma_multipoolallocator.h" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2Fbloomberg%2Fbde%2Fblob%2Fmaster%2Fgroups%2Fbdl%2Fbdlma%2=
Fbdlma_multipoolallocator.h\46sa\75D\46sntz\0751\46usg\75AFQjCNHcGaR7kzPgn2=
rn_Y8BN5sfhAvnsg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www=
..google.com/url?q\75https%3A%2F%2Fgithub.com%2Fbloomberg%2Fbde%2Fblob%2Fmas=
ter%2Fgroups%2Fbdl%2Fbdlma%2Fbdlma_multipoolallocator.h\46sa\75D\46sntz\075=
1\46usg\75AFQjCNHcGaR7kzPgn2rn_Y8BN5sfhAvnsg&#39;;return true;">https://git=
hub.com/<wbr>bloomberg/bde/blob/master/<wbr>groups/bdl/bdlma/bdlma_<wbr>mul=
tipoolallocator.h</a> ) have a release() member which simply releases all m=
emory currently in use by the allocator. The main constraint is that you ca=
n&#39;t release the memory if there is an aoutomatically managed object (e.=
g., an object on the stack) would later clean up the memmory. Allocating su=
ch objects with the same allocator conveniently avoids this problem entirel=
y.</div><div><br></div><div>The upshot is that the object release for corre=
sponding objects becomes an allocator thing. As long as the correct allocat=
or is used there isn&#39;t even a need to use smart pointers to track objec=
t lifetime further lowering the needs to touch memory unrelated to the actu=
al business processing (e.g., the synchronized reference counts of a std::s=
hared_ptr&lt;T&gt;). This approach can yield nice improvements, e.g., in co=
ntexts where it is typical to build up data structures which are short live=
d like while processing a request in a setver.</div><div><br></div><div>The=
 main caveats with this approach are</div><div><br></div><div>=C2=A01. The =
allocators need to be used correctly. If an object thus released allocated =
memory using a different allocator this memory isn&#39;t recovered.</div><d=
iv>=C2=A02. Any non-memory resource held by an object isn&#39;t released.=
=C2=A0</div><div><br></div><div>Correct use of allocators can be verified w=
ith a static analyser.=C2=A0 I think that verifying that no destructor is n=
eeded (orher than to release memory) may require annotation for objects whi=
ch do have a destructor but where the destructor is only required to releas=
e memory. Of course, it assumed that all memory allocations/deallocations h=
appen using the correct allocator.</div><span><div><br></div><div>On 17 Apr=
 2016, at 13:47, Patrice Roy &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"s3EzxbtYBQAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">patr...@gmail.com</a>&gt; wrote:<br><br></div><=
blockquote type=3D"cite"><div dir=3D"ltr"><div>Wouldn&#39;t the traversal b=
e required still (in general) for the calls to destroy(), even if deallocat=
e() is a noop? Unless we target this towards types that do not need their d=
estructors to be called and check that through traits on the contained type=
 from the containers&#39; functions...<br><br></div></div><div><br><div cla=
ss=3D"gmail_quote">2016-04-17 2:19 GMT-04:00 Max Galkin <span dir=3D"ltr">&=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"s3Ezx=
btYBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;=
return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ma=
ksim...@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>Hello std-proposals, I was recently experimenting with state=
ful allocators, such as stack_alloc[1], and standard containers.<br></div><=
div><br></div><div>During my experiment I&#39;ve noticed an inefficiency: e=
ven when all allocations made by a container were within my custom memory a=
rena and therefore could be deallocated at end of scope all together with t=
he arena instance, container&#39;s destructor had no way of knowing that it=
 was allowed to abandon memory safely and save cycles. Especially in case o=
f map/set/unordered_map/<wbr>unordered_set, deallocations can have noticeab=
le cost and be not cache-friendly, because they have to traverse memory non=
-linearly jumping through tree or linked list nodes.</div><div><br></div><d=
iv>Maybe standard containers should provide a way to relax the deallocation=
 logic to avoid redundant traversal of the container in destructor?</div><d=
iv><br></div><div>I know I&#39;m not the only person on this planet who saw=
 the need for this operation, because I found the following method declared=
 on red-black-tree and several containers in EASTL[2]:</div><div><br></div>=
<div><span style=3D"white-space:pre-wrap"> </span>template &lt;typename K, =
typename V, typename C, typename A, typename E, bool bM, bool bU&gt;</div><=
div><span style=3D"white-space:pre-wrap"> </span>inline void rbtree&lt;K, V=
, C, A, E, bM, bU&gt;::reset_lose_memory()</div><div><span style=3D"white-s=
pace:pre-wrap"> </span>{</div><div><span style=3D"white-space:pre-wrap">  <=
/span>// The reset_lose_memory function is a special extension function whi=
ch unilaterally=C2=A0</div><div><span style=3D"white-space:pre-wrap">  </sp=
an>// resets the container to an empty state without freeing the memory of=
=C2=A0</div><div><span style=3D"white-space:pre-wrap">  </span>// the conta=
ined objects. This is useful for very quickly tearing down a=C2=A0</div><di=
v><span style=3D"white-space:pre-wrap">  </span>// container built into scr=
atch memory.</div><div><span style=3D"white-space:pre-wrap">  </span>mAncho=
r.mpNodeRight =C2=A0=3D &amp;mAnchor;</div><div><span style=3D"white-space:=
pre-wrap">  </span>mAnchor.mpNodeLeft =C2=A0 =3D &amp;mAnchor;</div><div><s=
pan style=3D"white-space:pre-wrap">  </span>mAnchor.mpNodeParent =3D NULL;<=
/div><div><span style=3D"white-space:pre-wrap">  </span>mAnchor.mColor =C2=
=A0 =C2=A0 =C2=A0 =3D kRBTreeColorRed;</div><div><span style=3D"white-space=
:pre-wrap">  </span>mnSize =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =3D 0;</div><div><span style=3D"white-space:pre-wrap"> </span>}</div><div>=
<br></div><div><br></div><div>Having a method on containers is one option, =
alternatively maybe it can be a method on the allocator, which would tell t=
he container if it is allowed to not call &quot;deallocate&quot; for all th=
e memory it had so far allocated?..</div><div><br></div><div>Was this consi=
dered before? Is it a worthy proposal?</div><div><br></div><div>[1] <a href=
=3D"https://howardhinnant.github.io/stack_alloc.html" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
75https%3A%2F%2Fhowardhinnant.github.io%2Fstack_alloc.html\46sa\75D\46sntz\=
0751\46usg\75AFQjCNE_Ujfnv0AZek_VxeCwOqG_grTRsA&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fhowardhin=
nant.github.io%2Fstack_alloc.html\46sa\75D\46sntz\0751\46usg\75AFQjCNE_Ujfn=
v0AZek_VxeCwOqG_grTRsA&#39;;return true;">https://howardhinnant.github.<wbr=
>io/stack_alloc.html</a></div><div>[2] <a href=3D"https://github.com/electr=
onicarts/EASTL/blob/master/include/EASTL/internal/red_black_tree.h" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\75https%3A%2F%2Fgithub.com%2Felectronicarts%2FEASTL%2Fblob%2=
Fmaster%2Finclude%2FEASTL%2Finternal%2Fred_black_tree.h\46sa\75D\46sntz\075=
1\46usg\75AFQjCNHA7MTQVuAouBufC0KJObLdmYgIng&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
electronicarts%2FEASTL%2Fblob%2Fmaster%2Finclude%2FEASTL%2Finternal%2Fred_b=
lack_tree.h\46sa\75D\46sntz\0751\46usg\75AFQjCNHA7MTQVuAouBufC0KJObLdmYgIng=
&#39;;return true;">https://github.com/<wbr>electronicarts/EASTL/blob/<wbr>=
master/include/EASTL/internal/<wbr>red_black_tree.h</a></div></div></blockq=
uote></div></div>
</blockquote></span></div>

<p></p>

-- <br><span>
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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
s3EzxbtYBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"s3EzxbtYBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1AC3A78F-9769-4405-B618-C2C9DF878567%=
40gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/1AC3A78F-9769-4405-B618-C2C9DF878567%40gm=
ail.com?utm_medium\75email\46utm_source\75footer&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/1AC3A78F-9769-4405-B618-C2C9DF878567%40gmail.com?utm_medium\75email\=
46utm_source\75footer&#39;;return true;">https://groups.google.com/a/<wbr>i=
socpp.org/d/msgid/std-<wbr>proposals/1AC3A78F-9769-4405-<wbr>B618-C2C9DF878=
567%40gmail.com</a>.<br>
</blockquote></div><br></div>
</blockquote></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/98158978-a840-46b5-a5b1-ef71c45a54d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98158978-a840-46b5-a5b1-ef71c45a54d9=
%40isocpp.org</a>.<br />

------=_Part_170_450870264.1460913677657--
------=_Part_169_2047981761.1460913677653--

.

--001a1140160c5b1b250530c0c526
Content-Type: text/plain; charset=UTF-8

On Sun, Apr 17, 2016 at 7:21 PM, Max Galkin <maksim.galkin@gmail.com> wrote:

> I can so far see 2 ways to approach this:
>
> 1. Add something like "abandon_and_clear()" method on e.g. std::map, and
> leave the burden of ensuring correctness in each specific case to
> application developers :)  The benefit would be simplicity of
> implementation, and also it'd give developers more control over when to
> apply this approach, and let them apply it even when a map stores some
> non-trivial values, but for which they know they don't need to run the
> destructors (maybe the values are allocated from a different pool, but can
> also be abandoned).
>
> 2. Come up with a list of conditions and traits for key_type, value_type
> and allocator_type, and abandon memory in destructor (or on .clear()) only
> when all those conditions are met and thus memory safety is guaranteed by
> compiler in this scenario. E.g. key_type and value_type must either be
> "trivial" (if my understanding of "trivial" is correct -- they'd have no
> user-defined destructor) or use the same allocator as used by the
> container, and not use any other allocators (not sure if we have any
> standard way of expressing such trait). I think if we can express this,
> then std::map<std::string, std::vector> can abandon memory in a safe manner
> when allocator permits.
>
> Maybe even both ways should be supported?
>

Option #1 is not really required, because it can be implemented generically
for just about anything with the following:

template<class K> void abandon_and_clear(K &k)
{
struct T { char f[sizeof k]; };
T &t = T();
new (&t) auto(std::move(k));
}

Option #2 is not very useful, because in certain cases with non-trivial
destructors you would still want that logic to apply. For example, a map of
string to vectors, where strings and vectors use the same allocator.

But let's look at this from another angle. Today's allocator paradigm has
the allocator solely responsible for both destruction and deallocation. In
principle, if the destroy and deallocate methods are no-op, the compiler
should be able to detect that and generate no code calling those methods
and traversing the container. So we are talking about an optimization.

The question is, do we want extra hints to the compiler to effect that
particular optimization?

Cheers,
V.

--
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/CAA7YVg2Nf%2BD0d_T2bHP60TTP9GHH7JdCff9y%2Bqv%2BxBerQAV%2Bgg%40mail.gmail.com.

--001a1140160c5b1b250530c0c526
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Apr 17, 2016 at 7:21 PM, Max Galkin <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:maksim.galkin@gmail.com" target=3D"_blank">maksim.galkin@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr">I can so far see 2 =
ways to approach this:<div><br></div><div>1. Add something like &quot;aband=
on_and_clear()&quot; method on e.g. std::map, and leave the burden of ensur=
ing correctness in each specific case to application developers :) =C2=A0Th=
e benefit would be simplicity of implementation, and also it&#39;d give dev=
elopers more control over when to apply this approach, and let them apply i=
t even when a map stores some non-trivial values, but for which they know t=
hey don&#39;t need to run the destructors (maybe the values are allocated f=
rom a different pool, but can also be abandoned).</div><div>=C2=A0=C2=A0</d=
iv><div>2. Come up with a list of conditions and traits for key_type, value=
_type and allocator_type, and abandon memory in destructor (or on .clear())=
 only when all those conditions are met and thus memory safety is guarantee=
d by compiler in this scenario. E.g. key_type and value_type must either be=
 &quot;trivial&quot; (if my understanding of &quot;trivial&quot; is correct=
 -- they&#39;d have no user-defined destructor) or use the same allocator a=
s used by the container, and not use any other allocators (not sure if we h=
ave any standard way of expressing such trait). I think if we can express t=
his, then std::map&lt;std::string, std::vector&gt; can abandon memory in a =
safe manner when allocator permits.</div><div><br></div><div>Maybe even bot=
h ways should be supported?</div></div></blockquote><div><br></div><div>Opt=
ion #1 is not really required, because it can be implemented generically fo=
r just about anything with the following:</div><div><br></div><div><div><di=
v>template&lt;class K&gt; void abandon_and_clear(K &amp;k)</div><div>{</div=
><div><span class=3D"" style=3D"white-space:pre"> </span>struct T { char f[=
sizeof k]; };</div><div><span class=3D"" style=3D"white-space:pre"> </span>=
T &amp;t =3D T();</div><div><span class=3D"" style=3D"white-space:pre"> </s=
pan>new (&amp;t) auto(std::move(k));</div><div>}</div></div></div><div><br>=
</div><div>Option #2 is not very useful, because in certain cases with non-=
trivial destructors you would still want that logic to apply. For example, =
a map of string to vectors, where strings and vectors use the same allocato=
r.</div><div><br></div><div>But let&#39;s look at this from another angle. =
Today&#39;s allocator paradigm has the allocator solely responsible for bot=
h destruction and deallocation. In principle, if the destroy and deallocate=
 methods are no-op, the compiler should be able to detect that and generate=
 no code calling those methods and traversing the container. So we are talk=
ing about an optimization.</div><div><br></div><div>The question is, do we =
want extra hints to the compiler to effect that particular optimization?</d=
iv><div><br></div><div>Cheers,<br></div><div>V.</div></div></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/CAA7YVg2Nf%2BD0d_T2bHP60TTP9GHH7JdCff=
9y%2Bqv%2BxBerQAV%2Bgg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2N=
f%2BD0d_T2bHP60TTP9GHH7JdCff9y%2Bqv%2BxBerQAV%2Bgg%40mail.gmail.com</a>.<br=
 />

--001a1140160c5b1b250530c0c526--

.

------=_Part_59_1997091296.1461125702798
Content-Type: multipart/alternative;
 boundary="----=_Part_60_1887632077.1461125702799"

------=_Part_60_1887632077.1461125702799
Content-Type: text/plain; charset=UTF-8

re #1: nice... although move() isn't equivalent to clear() in general, the
state is left "unspecified" IIRC, and also this would still spend a few
cycles on moving some bits... but for things like vector/map it does seem
like it'd be an acceptable workaround in practice

re #2: deallocation is not necessarily a no-op, like with the stack_alloc.h
for example... we would only call "abandon_and_clear()" if stack_alloc have
not yet forwarded an allocation request to the system allocator, which can
only be determined at run time, depends on the dynamic size of the
structure using the allocator, so I'm not sure how we can optimize this at
compile-time...

---
Max

On Monday, April 18, 2016 at 4:36:30 AM UTC-7, Viacheslav Usov wrote:
>
> On Sun, Apr 17, 2016 at 7:21 PM, Max Galkin <maksim...@gmail.com
> <javascript:>> wrote:
>
>> I can so far see 2 ways to approach this:
>>
>> 1. Add something like "abandon_and_clear()" method on e.g. std::map, and
>> leave the burden of ensuring correctness in each specific case to
>> application developers :)  The benefit would be simplicity of
>> implementation, and also it'd give developers more control over when to
>> apply this approach, and let them apply it even when a map stores some
>> non-trivial values, but for which they know they don't need to run the
>> destructors (maybe the values are allocated from a different pool, but can
>> also be abandoned).
>>
>> 2. Come up with a list of conditions and traits for key_type, value_type
>> and allocator_type, and abandon memory in destructor (or on .clear()) only
>> when all those conditions are met and thus memory safety is guaranteed by
>> compiler in this scenario. E.g. key_type and value_type must either be
>> "trivial" (if my understanding of "trivial" is correct -- they'd have no
>> user-defined destructor) or use the same allocator as used by the
>> container, and not use any other allocators (not sure if we have any
>> standard way of expressing such trait). I think if we can express this,
>> then std::map<std::string, std::vector> can abandon memory in a safe manner
>> when allocator permits.
>>
>> Maybe even both ways should be supported?
>>
>
> Option #1 is not really required, because it can be implemented
> generically for just about anything with the following:
>
> template<class K> void abandon_and_clear(K &k)
> {
> struct T { char f[sizeof k]; };
> T &t = T();
> new (&t) auto(std::move(k));
> }
>
> Option #2 is not very useful, because in certain cases with non-trivial
> destructors you would still want that logic to apply. For example, a map of
> string to vectors, where strings and vectors use the same allocator.
>
> But let's look at this from another angle. Today's allocator paradigm has
> the allocator solely responsible for both destruction and deallocation. In
> principle, if the destroy and deallocate methods are no-op, the compiler
> should be able to detect that and generate no code calling those methods
> and traversing the container. So we are talking about an optimization.
>
> The question is, do we want extra hints to the compiler to effect that
> particular optimization?
>
> Cheers,
> V.
>

--
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/f3a2984f-9f7b-4df9-8a1a-12acf6557165%40isocpp.org.

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

<div dir=3D"ltr"><div>re #1: nice... although move() isn&#39;t equivalent t=
o clear() in general, the state is left &quot;unspecified&quot; IIRC, and a=
lso this would still spend a few cycles on moving some bits... but for thin=
gs like vector/map it does seem like it&#39;d be an acceptable workaround i=
n practice</div><div><br></div><div>re #2: deallocation is not necessarily =
a no-op, like with the stack_alloc.h for example... we would only call &quo=
t;abandon_and_clear()&quot; if stack_alloc have not yet forwarded an alloca=
tion request to the system allocator, which can only be determined at run t=
ime, depends on the dynamic size of the structure using the allocator, so I=
&#39;m not sure how we can optimize this at compile-time...</div><div><br><=
/div>---<div>Max<br><br>On Monday, April 18, 2016 at 4:36:30 AM UTC-7, Viac=
heslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On Sun, Apr 17, 2016 at 7:21 PM, Max G=
alkin <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"vNt7EuKeBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">maksim...@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr">I can so far see 2 ways to approach this:<div><b=
r></div><div>1. Add something like &quot;abandon_and_clear()&quot; method o=
n e.g. std::map, and leave the burden of ensuring correctness in each speci=
fic case to application developers :) =C2=A0The benefit would be simplicity=
 of implementation, and also it&#39;d give developers more control over whe=
n to apply this approach, and let them apply it even when a map stores some=
 non-trivial values, but for which they know they don&#39;t need to run the=
 destructors (maybe the values are allocated from a different pool, but can=
 also be abandoned).</div><div>=C2=A0=C2=A0</div><div>2. Come up with a lis=
t of conditions and traits for key_type, value_type and allocator_type, and=
 abandon memory in destructor (or on .clear()) only when all those conditio=
ns are met and thus memory safety is guaranteed by compiler in this scenari=
o. E.g. key_type and value_type must either be &quot;trivial&quot; (if my u=
nderstanding of &quot;trivial&quot; is correct -- they&#39;d have no user-d=
efined destructor) or use the same allocator as used by the container, and =
not use any other allocators (not sure if we have any standard way of expre=
ssing such trait). I think if we can express this, then std::map&lt;std::st=
ring, std::vector&gt; can abandon memory in a safe manner when allocator pe=
rmits.</div><div><br></div><div>Maybe even both ways should be supported?</=
div></div></blockquote><div><br></div><div>Option #1 is not really required=
, because it can be implemented generically for just about anything with th=
e following:</div><div><br></div><div><div><div>template&lt;class K&gt; voi=
d abandon_and_clear(K &amp;k)</div><div>{</div><div><span style=3D"white-sp=
ace:pre"> </span>struct T { char f[sizeof k]; };</div><div><span style=3D"w=
hite-space:pre"> </span>T &amp;t =3D T();</div><div><span style=3D"white-sp=
ace:pre"> </span>new (&amp;t) auto(std::move(k));</div><div>}</div></div></=
div><div><br></div><div>Option #2 is not very useful, because in certain ca=
ses with non-trivial destructors you would still want that logic to apply. =
For example, a map of string to vectors, where strings and vectors use the =
same allocator.</div><div><br></div><div>But let&#39;s look at this from an=
other angle. Today&#39;s allocator paradigm has the allocator solely respon=
sible for both destruction and deallocation. In principle, if the destroy a=
nd deallocate methods are no-op, the compiler should be able to detect that=
 and generate no code calling those methods and traversing the container. S=
o we are talking about an optimization.</div><div><br></div><div>The questi=
on is, do we want extra hints to the compiler to effect that particular opt=
imization?</div><div><br></div><div>Cheers,<br></div><div>V.</div></div></d=
iv></div>
</blockquote></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/f3a2984f-9f7b-4df9-8a1a-12acf6557165%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3a2984f-9f7b-4df9-8a1a-12acf6557165=
%40isocpp.org</a>.<br />

------=_Part_60_1887632077.1461125702799--
------=_Part_59_1997091296.1461125702798--

.

--001a1140160cf8fa6d0530e7dce0
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 6:15 AM, Max Galkin <maksim.galkin@gmail.com> wrote:

> re #2: deallocation is not necessarily a no-op, like with the
stack_alloc.h for example... we would only call "abandon_and_clear()" if
stack_alloc have not yet forwarded an allocation request to the system
allocator, which can only be determined at run time, depends on the dynamic
size of the structure using the allocator, so I'm not sure how we can
optimize this at compile-time...

I am not sure what exactly you are proposing, then. If you cannot just make
deallocate no-op, then the container will call it, right? Do you want or do
you not want that to happen in this case?

If your deallocator is not no-op, and you still want it NOT to be called,
then you would need some other way to deallocate memory, presumably in a
more efficient way? Then why can't you make deallocate no-op and use that
other mechanism?

Cheers,
V.

--
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/CAA7YVg1P-V%2BcXWYWzhT7Ei4VNZFQBuGWcfVYUzy%2B-aUJ_CFngg%40mail.gmail.com.

--001a1140160cf8fa6d0530e7dce0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 20, 2016 at 6:15 AM, Max Galkin <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:maksim.galkin@gmail.com" target=3D"_blank">maksim.galkin@gmail.com</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt; re #2: deallocation is not n=
ecessarily a no-op, like with the stack_alloc.h for example... we would onl=
y call &quot;abandon_and_clear()&quot; if stack_alloc have not yet forwarde=
d an allocation request to the system allocator, which can only be determin=
ed at run time, depends on the dynamic size of the structure using the allo=
cator, so I&#39;m not sure how we can optimize this at compile-time...</div=
><div><br></div><div>I am not sure what exactly you are proposing, then. If=
 you cannot just make deallocate no-op, then the container will call it, ri=
ght? Do you want or do you not want that to happen in this case?</div><div>=
<br></div><div>If your deallocator is not no-op, and you still want it NOT =
to be called, then you would need some other way to deallocate memory, pres=
umably in a more efficient way? Then why can&#39;t you make deallocate no-o=
p and use that other mechanism?</div><div><br></div><div>Cheers,</div><div>=
V.</div><div><br></div></div></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/CAA7YVg1P-V%2BcXWYWzhT7Ei4VNZFQBuGWcf=
VYUzy%2B-aUJ_CFngg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1P-V%2=
BcXWYWzhT7Ei4VNZFQBuGWcfVYUzy%2B-aUJ_CFngg%40mail.gmail.com</a>.<br />

--001a1140160cf8fa6d0530e7dce0--

.

--001a113ed9dce94f950530eaa4f9
Content-Type: text/plain; charset=UTF-8

As an embedded systems programmer my wish list would be:to

   - Preserve all current guarantees (*i.e.* no extensions enabling
   subversion)
   - Language extended to tease deallocation activity from destruction
   - Compiler able to distinguish when either or both activities are
   vacuous and optimize appropriately

Contrary to what seems to have been suggested earlier in this thread,
visiting the elements of a container to perform destruction without
performing deallocation is an important case to optimize. One of the main
reason for implementing zones / arenas / what-have-yous is to make the
destruction scan cheaper by improving locality.  Another reason is that
reintegrating a random bit of destroyed memory back into any form of more
general heap can swamp all of the other costs of the container destruction
pass.

/john

--
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/CAJnXXohuRCL%3DFziMjhvkTXdMNT44RR%2By62eO9J_it%3DM7prFkaw%40mail.gmail.com.

--001a113ed9dce94f950530eaa4f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">As an embedded systems programm=
er my wish list would be:to=C2=A0</div><div class=3D"gmail_extra"><ul><li>P=
reserve all current guarantees (<i>i.e.</i>=C2=A0no extensions enabling sub=
version)<br></li><li>Language extended to tease deallocation activity from =
destruction</li><li>Compiler able to distinguish when either or both activi=
ties are vacuous and optimize appropriately</li></ul><div>Contrary to what =
seems to have been suggested earlier in this thread, visiting the elements =
of a container to perform destruction without performing deallocation is an=
 important case to optimize. One of the main reason for implementing zones =
/ arenas / what-have-yous is to make the destruction scan cheaper by improv=
ing locality.=C2=A0 Another reason is that reintegrating a random bit of de=
stroyed memory back into any form of more general heap can swamp all of the=
 other costs of the container destruction pass.</div><div><br></div><div>/j=
ohn</div></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/CAJnXXohuRCL%3DFziMjhvkTXdMNT44RR%2By=
62eO9J_it%3DM7prFkaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXohuRC=
L%3DFziMjhvkTXdMNT44RR%2By62eO9J_it%3DM7prFkaw%40mail.gmail.com</a>.<br />

--001a113ed9dce94f950530eaa4f9--

.

--001a1140160cd7d58d0530eb379e
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 3:33 PM, John Yates <john@yates-sheets.org> wrote:

> Language extended to tease deallocation activity from destruction

I am not sure what you mean, but the current synopsis on the allocator and
allocator traits has these two as distinct functions: deallocate and
destroy respectively.

Cheers,
V.

--
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/CAA7YVg2F9G7yiS7SgRkqPXjFnoYJm4bLV_avi3t21%2B9SkUnX5A%40mail.gmail.com.

--001a1140160cd7d58d0530eb379e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 20, 2016 at 3:33 PM, John Yates <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:john@yates-sheets.org" target=3D"_blank">john@yates-sheets.org</a>&gt;=
</span> wrote:<br><div><br></div><div>&gt; Language extended to tease deall=
ocation activity from destruction</div><div><br></div><div>I am not sure wh=
at you mean, but the current synopsis on the allocator and allocator traits=
 has these two as distinct functions: deallocate and destroy respectively.<=
/div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div></div></d=
iv></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/CAA7YVg2F9G7yiS7SgRkqPXjFnoYJm4bLV_av=
i3t21%2B9SkUnX5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2F9G7yiS=
7SgRkqPXjFnoYJm4bLV_avi3t21%2B9SkUnX5A%40mail.gmail.com</a>.<br />

--001a1140160cd7d58d0530eb379e--

.

--f46d04289c1d26bced0530eb8dab
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 10:14 AM, Viacheslav Usov <via.usov@gmail.com>
wrote:

> On Wed, Apr 20, 2016 at 3:33 PM, John Yates <john@yates-sheets.org> wrote:
>
> > Language extended to tease deallocation activity from destruction
>
> I am not sure what you mean, but the current synopsis on the allocator and
> allocator traits has these two as distinct functions: deallocate and
> destroy respectively.
>

Please overlook what was obviously an Emily Littela
<https://en.wikipedia.org/wiki/Emily_Litella> moment.  I was focusing on
the fact that when I code I invoke only destruction and never mention
deallocation.  Cleanly that is as it should be.

/john

--
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/CAJnXXogT8vuWTNs%3DpUxUnKGf6_e8FRFT%2BB97p%3DV%2BWo_m_xMCog%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 20, 2016 at 10:14 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Apr 2=
0, 2016 at 3:33 PM, John Yates <span dir=3D"ltr">&lt;<a href=3D"mailto:john=
@yates-sheets.org" target=3D"_blank">john@yates-sheets.org</a>&gt;</span> w=
rote:<br><div><br></div><div>&gt; Language extended to tease deallocation a=
ctivity from destruction</div><div><br></div></span><div>I am not sure what=
 you mean, but the current synopsis on the allocator and allocator traits h=
as these two as distinct functions: deallocate and destroy respectively.</d=
iv></div></div></div></blockquote><div><br></div><div>Please overlook what =
was obviously an <a href=3D"https://en.wikipedia.org/wiki/Emily_Litella">Em=
ily Littela</a> moment.=C2=A0 I was focusing on the fact that when I code I=
 invoke only destruction and never mention deallocation.=C2=A0 Cleanly that=
 is as it should be.</div><div><br></div><div>/john</div><div><br></div></d=
iv></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/CAJnXXogT8vuWTNs%3DpUxUnKGf6_e8FRFT%2=
BB97p%3DV%2BWo_m_xMCog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnXXogT=
8vuWTNs%3DpUxUnKGf6_e8FRFT%2BB97p%3DV%2BWo_m_xMCog%40mail.gmail.com</a>.<br=
 />

--f46d04289c1d26bced0530eb8dab--

.