Topic: Inferring stateless deleter from a partially
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Fri, 19 Oct 2018 08:40:01 -0700 (PDT)
Raw View
------=_Part_3845_751350406.1539963601340
Content-Type: multipart/alternative;
boundary="----=_Part_3846_544746132.1539963601341"
------=_Part_3846_544746132.1539963601341
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 17, 2018 at 7:17:36 AM UTC-7, Gareth Lloyd wrote:
>
> tl;dr; Currently a deleter is a facade over an allocator which currently=
=20
> doesn't hide how big the allocator is.
>
> Allocators provides a customization point for a generic data structure=20
> which may allocate internal structures.=20
>
> An allocator controls allocation, construction, destruction and=20
> deallocation. In the standard we have some opinionated allocators=20
> std::allocator, std::scoped_allocator_adaptor and=20
> std::pmr::polymorphic_allocator.
>
> With current allocators, if any one of those customization points require=
=20
> state then the entire allocator is stateful. This is fine if you are usin=
g=20
> the allocator as an allocator, you are going to be using those methods th=
at=20
> require state so the state is not an overhead. But there are situations,=
=20
> like deleter, where you are only using a subset of those methods.
>
> For a concrete example, allocate_unique needs the allocator to do the=20
> allocate and construct. But the returned unique_ptr only requires a=20
> specialized deleter based on the provided allocator. This deleter is a=20
> facade of the allocator, simplifying the interface and only using destroy=
=20
> and deallocate methods of the allocator. If those methods are stateless i=
n=20
> nature then the unique_ptr should not have to carry unnecessarily state=
=20
> that the deleter doesn't use.=20
>
> For allocators which are partially stateful there is currently no facilit=
y=20
> to make an allocate_unique implementation which can sense if the deleter=
=20
> methods (destroy and deallocate) are stateless. Without that sense the=20
> deleter has to be as stateful as the allocator it was derived from.
>
IIUC and AFAICT, the only situation where this comes up in practice is with=
=20
memory resources (heaps) where `deallocate` is a no-op.
In practice `destroy` is always "stateless" because its behavior depends=20
only on the type T being destroyed, not on the identity of the allocator=20
doing the destruction. (In fact, I think Mark Zeren is working on a=20
proposal to deprecate `destroy`, although I don't see it in the pre=E2=80=
=93San=20
Diego mailing.)
In practice, `deallocate` is frequently "stateless," e.g. when the=20
allocator is std::allocator<T>; but in most cases `deallocate` is stateless=
=20
*because* the allocator is stateless (i.e. the allocator has only one=20
possible value), in which case your optimization doesn't buy us anything=20
because the allocator is already an empty class. So the usefulness is=20
limited (in practice, AFAICT) to the case where the allocator is stateful=
=20
(or, as I like to say <https://youtu.be/0MdSJsCTRkY>, "value-ful") and=20
where `deallocate` is a no-op.
`deallocate` is not a no-op for any standard-library-provided allocator=20
type (std::allocator, std::pmr::polymorphic_allocator,=20
std::scoped_allocator_adaptor).
It could conceivably be a no-op for a user-provided allocator type A<T>=20
where A<T>'s value was restricted to point to a memory resource with a=20
no-op `deallocate`. For example:
template<class T>
struct monotonic_buffer_allocator : public=20
std::pmr::polymorphic_allocator<T> {
using Base =3D std::pmr::polymorphic_allocator<T>;
monotonic_buffer_allocator(std::pmr::monotonic_buffer_resource *mr) :=
=20
mr_(mr) {}
template<class U> monotonic_buffer_allocator(const=20
monotonic_buffer_allocator<U>& rhs) : Base(rhs) {}
using Base::allocate;
using Base::construct;
using Base::destroy;
void deallocate(T *, size_t) {}
template<class U> struct rebind { using other =3D=20
monotonic_buffer_allocator<U>; }
};
`monotonic_buffer_allocator` here is "value-ful" (non-empty) but also has a=
=20
no-op `deallocate` and a stateless `destroy`; so conceivably=20
`allocate_unique` could be written to take advantage of this property.
I would spell it `std::has_trivial_deallocate_v<A<T>>`.
Incidentally, I don't like your `stateless_deleter_v<A<T>>` because it is=
=20
missing an `is_` on the front.
Furthermore, observe that when `has_trivial_deallocate_v<A<T>>`, then the=
=20
`unique_ptr` returned from `allocate_unique<T, A<T>>` can be *trivially=20
destructible*. This seems like a very nice property to have,=20
philosophically speaking, even though I can't off the top of my head come=
=20
up with any concrete application for it.
A compromise approach might be to permit the allocator to specify a member=
=20
typedef `using deleter =3D ...` (defaulted to `allocator_delete<A<T>>` in=
=20
`allocator_traits`) which could be customized by the designer of the=20
allocator type. Then this deleter could be stateless and/or have a trivial=
=20
`deallocate` method.
Bottom lines:
- I think the property of *trivial* deallocate is much more directly=20
relevant to your use-case than is the property of *stateless* deallocate.
- I think it is not worth asking WG21 to pursue the *detection and=20
exploitation* of either property, until there *exists* some standard=20
allocator having the property, which is not likely ever to happen. It's=20
easy to hack up the existence and detection mechanisms within your own=20
codebase, as you've done, and then provide `my::allocate_unique` to exploit=
=20
them. You don't need to be friends with `std::unique_ptr` to make that=20
happen; you just need to provide a custom deleter type, which is already=20
possible in standard C++.
=E2=80=93Arthur
--=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/5f11127d-1ab8-41d8-8b8d-8e9781770f20%40isocpp.or=
g.
------=_Part_3846_544746132.1539963601341
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 17, 2018 at 7:17:36 AM UTC-7, Gareth=
Lloyd wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div class=3D"gmail_quote"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
dir=3D"ltr"><div dir=3D"ltr">tl;dr; Currently a deleter is a facade over a=
n allocator which currently doesn't hide how big the allocator is.</div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr">Allocators provides a customiz=
ation point for a generic data structure which may allocate internal struct=
ures. <br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">An
allocator controls allocation, construction, destruction and=20
deallocation. In the standard we have some opinionated allocators=20
std::allocator, std::scoped_allocator_adaptor and std::pmr::polymorphic_<wb=
r>allocator.</div><div dir=3D"ltr"><br></div><div>With
current allocators, if any one of those customization points require=20
state then the entire allocator is stateful. This is fine if you are=20
using the allocator as an allocator, you are going to be using those=20
methods that require state so the state is not an overhead. But there=20
are situations, like deleter, where you are only using a subset of those
methods.</div><div><br></div><div>For a concrete example,=20
allocate_unique needs the allocator to do the allocate and construct.=20
But the returned unique_ptr only requires a specialized deleter based on
the provided allocator. This deleter is a facade of the allocator,=20
simplifying the interface and only using destroy and deallocate methods=20
of the allocator. If those methods are stateless in nature then the=20
unique_ptr should not have to carry unnecessarily state that the deleter
doesn't use. <br></div><div><br></div>For allocators which are partial=
ly stateful there is currently no=20
facility to make an allocate_unique implementation=20
which can sense if the deleter methods (destroy and deallocate) are=20
stateless. Without that sense the deleter has to be as stateful as the=20
allocator it was derived from.</div></div></div></div></div></div></div></d=
iv></div></div></blockquote><div><br></div><div>IIUC and AFAICT, the only s=
ituation where this comes up in practice is with memory resources (heaps) w=
here `deallocate` is a no-op.</div><div><br></div><div>In practice `destroy=
` is always "stateless" because its behavior depends only on the =
type T being destroyed, not on the identity of the allocator doing the dest=
ruction. (In fact, I think Mark Zeren is working on a proposal to deprecate=
`destroy`, although I don't see it in the pre=E2=80=93San Diego mailin=
g.)</div><div>In practice, `deallocate` is frequently "stateless,"=
; e.g. when the allocator is std::allocator<T>; but in most cases `de=
allocate` is stateless <i>because</i> the allocator is stateless (i.e. the =
allocator has only one possible value), in which case your optimization doe=
sn't buy us anything because the allocator is already an empty class. S=
o the usefulness is limited (in practice, AFAICT) to the case where the all=
ocator is stateful (or, <a href=3D"https://youtu.be/0MdSJsCTRkY">as I like =
to say</a>, "value-ful") and where `deallocate` is a no-op.</div>=
<div><br></div><div>`deallocate` is not a no-op for any standard-library-pr=
ovided allocator type (std::allocator, std::pmr::polymorphic_allocator, std=
::scoped_allocator_adaptor).</div><div>It could conceivably be a no-op for =
a user-provided allocator type A<T> where A<T>'s value was =
restricted to point to a memory resource with a no-op `deallocate`. For exa=
mple:</div><div><br></div><div>template<class T></div><div>struct mon=
otonic_buffer_allocator : public std::pmr::polymorphic_allocator<T> {=
</div><div>=C2=A0 =C2=A0 using Base =3D std::pmr::polymorphic_allocator<=
T>;</div><div><br></div><div>=C2=A0 =C2=A0 monotonic_buffer_allocator(st=
d::pmr::monotonic_buffer_resource *mr) : mr_(mr) {}<br></div><div><div>=C2=
=A0 =C2=A0 template<class U> monotonic_buffer_allocator(const monoton=
ic_buffer_allocator<U>& rhs) : Base(rhs) {}</div></div><div><br><=
/div><div>=C2=A0 =C2=A0 using Base::allocate;</div><div>=C2=A0 =C2=A0 using=
Base::construct;</div><div>=C2=A0 =C2=A0 using Base::destroy;</div><div>=
=C2=A0 =C2=A0 void deallocate(T *, size_t) {}</div><div><br></div><div>=C2=
=A0 =C2=A0 template<class U> struct rebind { using other =3D monotoni=
c_buffer_allocator<U>; }</div><div>};<br></div><div><br></div><div>`m=
onotonic_buffer_allocator` here is "value-ful" (non-empty) but al=
so has a no-op `deallocate` and a stateless `destroy`; so conceivably `allo=
cate_unique` could be written to take advantage of this property.</div><div=
><br></div><div>I would spell it `std::has_trivial_deallocate_v<A<T&g=
t;>`.</div><div>Incidentally, I don't like your `stateless_deleter_v=
<A<T>>` because it is missing an `is_` on the front.</div><div>=
<br></div><div>Furthermore, observe that when `has_trivial_deallocate_v<=
A<T>>`, then the `unique_ptr` returned from `allocate_unique<T,=
A<T>>` can be <i><b>trivially destructible</b></i>. This seems li=
ke a very nice property to have, philosophically speaking, even though I ca=
n't off the top of my head come up with any concrete application for it=
..</div><div><br></div><div>A compromise approach might be to permit the all=
ocator to specify a member typedef `using deleter =3D ...` (defaulted to `a=
llocator_delete<A<T>>` in `allocator_traits`) which could be cu=
stomized by the designer of the allocator type. Then this deleter could be =
stateless and/or have a trivial `deallocate` method.</div><div><br></div><d=
iv>Bottom lines:</div><div>- I think the property of <i><b>trivial</b></i> =
deallocate is much more directly relevant to your use-case than is the prop=
erty of=C2=A0<i><b>stateless</b></i> deallocate.</div><div>- I think it is =
not worth asking WG21 to pursue the <i><b>detection and exploitation</b></i=
> of either property, until there <i><b>exists</b></i> some standard alloca=
tor having the property, which is not likely ever to happen. It's easy =
to hack up the existence and detection mechanisms within your own codebase,=
as you've done, and then provide `my::allocate_unique` to exploit them=
.. You don't need to be friends with `std::unique_ptr` to make that happ=
en; you just need to provide a custom deleter type, which is already possib=
le in standard C++.</div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5f11127d-1ab8-41d8-8b8d-8e9781770f20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f11127d-1ab8-41d8-8b8d-8e9781770f20=
%40isocpp.org</a>.<br />
------=_Part_3846_544746132.1539963601341--
------=_Part_3845_751350406.1539963601340--
.
Author: Gareth Lloyd <gareth@ignition-web.co.uk>
Date: Mon, 22 Oct 2018 17:17:12 -0700 (PDT)
Raw View
------=_Part_4740_922585725.1540253832801
Content-Type: multipart/alternative;
boundary="----=_Part_4741_1451322860.1540253832801"
------=_Part_4741_1451322860.1540253832801
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
> IIUC and AFAICT, the only situation where this comes up in practice is=20
> with memory resources (heaps) where `deallocate` is a no-op.
>
> In practice `destroy` is always "stateless" because its behavior depends=
=20
> only on the type T being destroyed, not on the identity of the allocator=
=20
> doing the destruction. (In fact, I think Mark Zeren is working on a=20
> proposal to deprecate `destroy`, although I don't see it in the pre=E2=80=
=93San=20
> Diego mailing.)
>
I can't think of a useful customization of `destroy` but one may exist, I'd=
=20
like to hear more on the idea of deprecating it.
=20
> Furthermore, observe that when `has_trivial_deallocate_v<A<T>>`, then the=
=20
> `unique_ptr` returned from `allocate_unique<T, A<T>>` can be *trivially=
=20
> destructible*. This seems like a very nice property to have,=20
> philosophically speaking, even though I can't off the top of my head come=
=20
> up with any concrete application for it.
>
`unique_ptr` itself would need specializing to make it actually trivially=
=20
destructibe and not just noop destructor. value_type must be trivailly=20
destructible, allocator uses default destroy and noop deallocate. (On a=20
related note see=20
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5=
Isw)
=20
> A compromise approach might be to permit the allocator to specify a membe=
r=20
> typedef `using deleter =3D ...` (defaulted to `allocator_delete<A<T>>` in=
=20
> `allocator_traits`) which could be customized by the designer of the=20
> allocator type. Then this deleter could be stateless and/or have a trivia=
l=20
> `deallocate` method.
>
This possibly hints that a dual concept of a `maker` to mirror that of the=
=20
`deleter`. Those would be a convient allocator_trait additions to have.
=20
> Bottom lines:
> - I think the property of *trivial* deallocate is much more directly=20
> relevant to your use-case than is the property of *stateless* deallocate.
>
=20
I think both are important.
- I think it is not worth asking WG21 to pursue the *detection and=20
> exploitation* of either property, until there *exists* some standard=20
> allocator having the property, which is not likely ever to happen. It's=
=20
> easy to hack up the existence and detection mechanisms within your own=20
> codebase, as you've done, and then provide `my::allocate_unique` to explo=
it=20
> them. You don't need to be friends with `std::unique_ptr` to make that=20
> happen; you just need to provide a custom deleter type, which is already=
=20
> possible in standard C++.
>
Custom deleter only gives us the noop deallocation, trivial destruction of=
=20
unique_ptr requires more.
Should P0316R0 "allocate_unique and allocator_delete" only consider the=20
standard allocator? If it makes it into that standard then it will need to=
=20
allow specialized allocator_delete?
In my other post=20
(https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs=
5Isw)=20
I show limitations of the winked-out optimization with existing containers=
=20
and existing allocators. This may motivate the need for either more=20
allocators in the standard or better facilities to make your own.
--=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/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%40isocpp.or=
g.
------=_Part_4741_1451322860.1540253832801
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>IIUC and AFAICT, the only situation where this comes up in practic=
e is with memory resources (heaps) where `deallocate` is a no-op.</div><div=
><br></div><div>In practice `destroy` is always "stateless" becau=
se its behavior depends only on the type T being destroyed, not on the iden=
tity of the allocator doing the destruction. (In fact, I think Mark Zeren i=
s working on a proposal to deprecate `destroy`, although I don't see it=
in the pre=E2=80=93San Diego mailing.)</div></div></blockquote><div><br></=
div><div>I can't think of a useful customization of `destroy` but one m=
ay exist, I'd like to hear more on the idea of deprecating it.<br></div=
><div>=C2=A0</div><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>Furthermore, observe that when `has_trivial_deallocate_v<A<=
T><wbr>>`, then the `unique_ptr` returned from `allocate_unique<T,=
A<T>>` can be <i><b>trivially destructible</b></i>. This seems li=
ke a very nice property to have, philosophically speaking, even though I ca=
n't off the top of my head come up with any concrete application for it=
..</div></div></blockquote><div><br></div><div>`unique_ptr` itself would nee=
d specializing to make it actually trivially destructibe and not just noop =
destructor. value_type must be trivailly destructible, allocator uses defau=
lt destroy and noop deallocate. (On a related note see https://groups.googl=
e.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw)<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>A compromise approach might be to permit the allocator to sp=
ecify a member typedef `using deleter =3D ...` (defaulted to `allocator_del=
ete<A<T>>` in `allocator_traits`) which could be customized by =
the designer of the allocator type. Then this deleter could be stateless an=
d/or have a trivial `deallocate` method.</div></div></blockquote><div><br><=
/div><div>This possibly hints that a dual concept of a `maker` to mirror th=
at of the `deleter`. Those would be a convient allocator_trait additions to=
have.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div>Bottom lines:</div><div>- I think the property of =
<i><b>trivial</b></i> deallocate is much more directly relevant to your use=
-case than is the property of=C2=A0<i><b>stateless</b></i> deallocate.</div=
></div></blockquote><div>=C2=A0</div><div>I think both are important.<br></=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>- I think it is not worth asking WG21 to pursue the <i><b>detect=
ion and exploitation</b></i> of either property, until there <i><b>exists</=
b></i> some standard allocator having the property, which is not likely eve=
r to happen. It's easy to hack up the existence and detection mechanism=
s within your own codebase, as you've done, and then provide `my::alloc=
ate_unique` to exploit them. You don't need to be friends with `std::un=
ique_ptr` to make that happen; you just need to provide a custom deleter ty=
pe, which is already possible in standard C++.</div></div></blockquote><div=
><br></div><div>Custom deleter only gives us the noop deallocation, trivial=
destruction of unique_ptr requires more.</div><div>Should P0316R0 "al=
locate_unique and allocator_delete" only consider the standard allocat=
or? If it makes it into that standard then it will need to allow specialize=
d allocator_delete?</div><div>In my other post (https://groups.google.com/a=
/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw) I show limitations of =
the winked-out optimization with existing containers and existing allocator=
s. This may motivate the need for either more allocators in the standard or=
better facilities to make your own.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/abd7a3bc-e438-4fa3-b26a-a8888bfec11a=
%40isocpp.org</a>.<br />
------=_Part_4741_1451322860.1540253832801--
------=_Part_4740_922585725.1540253832801--
.
Author: Gareth Lloyd <gareth@ignition-web.co.uk>
Date: Tue, 23 Oct 2018 05:36:35 -0700 (PDT)
Raw View
------=_Part_5008_873197895.1540298195928
Content-Type: multipart/alternative;
boundary="----=_Part_5009_406449433.1540298195928"
------=_Part_5009_406449433.1540298195928
Content-Type: text/plain; charset="UTF-8"
>
> A compromise approach might be to permit the allocator to specify a member
>> typedef `using deleter = ...` (defaulted to `allocator_delete<A<T>>` in
>> `allocator_traits`) which could be customized by the designer of the
>> allocator type. Then this deleter could be stateless and/or have a trivial
>> `deallocate` method.
>>
>
> This possibly hints that a dual concept of a `maker` to mirror that of the
> `deleter`. Those would be a convient allocator_trait additions to have.
>
Having slept on this the obvious concept name would be `newer` (not a fan
of the name). User defined types can provide new/delete overrides
(customization point for external allocation). I know their are good
reasons why allocators (customization point for internal allocations) did
not go with the newer/deleter paradigm, there are advantages to working
with raw memory separately from the object materialization(s). The
newer/deleter typedefs do add convenience to the type designers that use
allocators, but for the winked-out optimization giving a trivial
destructible type `is_trivial_deleter_v` would also need to be part of the
allocator (optional) + allocator_trait. That or some canonical
implementation of the noop_deleter, that by convention is_same<> can be
used to enable the is_trivial_destructible<> on the generic type (I do not
advocate this approach).
--
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/5474c7c2-f539-4b53-85df-4f7449b8c285%40isocpp.org.
------=_Part_5009_406449433.1540298195928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><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><di=
v>A compromise approach might be to permit the allocator to specify a membe=
r typedef `using deleter =3D ...` (defaulted to `allocator_delete<A<T=
>>` in `allocator_traits`) which could be customized by the designer =
of the allocator type. Then this deleter could be stateless and/or have a t=
rivial `deallocate` method.</div></div></blockquote><div><br></div><div>Thi=
s possibly hints that a dual concept of a `maker` to mirror that of the `de=
leter`. Those would be a convient allocator_trait additions to have.</div><=
/div></blockquote><div><br></div><div>Having slept on this the obvious conc=
ept name would be `newer` (not a fan of the name). User defined types can p=
rovide new/delete overrides (customization point for external allocation). =
I know their are good reasons why allocators (customization point for inter=
nal allocations) did not go with the newer/deleter paradigm, there are adva=
ntages to working with raw memory separately from the object materializatio=
n(s). The newer/deleter typedefs do add convenience to the type designers t=
hat use allocators, but for the winked-out optimization giving a trivial de=
structible type `is_trivial_deleter_v` would also need to be part of the al=
locator (optional) + allocator_trait. That or some canonical implementation=
of the noop_deleter, that by convention is_same<> can be used to ena=
ble the is_trivial_destructible<> on the generic type (I do not advoc=
ate this approach). <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5474c7c2-f539-4b53-85df-4f7449b8c285%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5474c7c2-f539-4b53-85df-4f7449b8c285=
%40isocpp.org</a>.<br />
------=_Part_5009_406449433.1540298195928--
------=_Part_5008_873197895.1540298195928--
.
Author: Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>
Date: Wed, 24 Oct 2018 00:04:44 -0700
Raw View
--0000000000008e86370578f41a5d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
An example of a weird destroy: the object lives on an accelerator and needs
to be destroyed by a thread local to the accelerator.
On Mon, Oct 22, 2018, 5:17 PM Gareth Lloyd <gareth@ignition-web.co.uk>
wrote:
> IIUC and AFAICT, the only situation where this comes up in practice is
>> with memory resources (heaps) where `deallocate` is a no-op.
>>
>> In practice `destroy` is always "stateless" because its behavior depends
>> only on the type T being destroyed, not on the identity of the allocator
>> doing the destruction. (In fact, I think Mark Zeren is working on a
>> proposal to deprecate `destroy`, although I don't see it in the pre=E2=
=80=93San
>> Diego mailing.)
>>
>
> I can't think of a useful customization of `destroy` but one may exist,
> I'd like to hear more on the idea of deprecating it.
>
>
>> Furthermore, observe that when `has_trivial_deallocate_v<A<T>>`, then th=
e
>> `unique_ptr` returned from `allocate_unique<T, A<T>>` can be *trivially
>> destructible*. This seems like a very nice property to have,
>> philosophically speaking, even though I can't off the top of my head com=
e
>> up with any concrete application for it.
>>
>
> `unique_ptr` itself would need specializing to make it actually trivially
> destructibe and not just noop destructor. value_type must be trivailly
> destructible, allocator uses default destroy and noop deallocate. (On a
> related note see
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmE=
s5Isw
> )
>
>
>> A compromise approach might be to permit the allocator to specify a
>> member typedef `using deleter =3D ...` (defaulted to `allocator_delete<A=
<T>>`
>> in `allocator_traits`) which could be customized by the designer of the
>> allocator type. Then this deleter could be stateless and/or have a trivi=
al
>> `deallocate` method.
>>
>
> This possibly hints that a dual concept of a `maker` to mirror that of th=
e
> `deleter`. Those would be a convient allocator_trait additions to have.
>
>
>> Bottom lines:
>> - I think the property of *trivial* deallocate is much more directly
>> relevant to your use-case than is the property of *stateless* deallocate=
..
>>
>
> I think both are important.
>
> - I think it is not worth asking WG21 to pursue the *detection and
>> exploitation* of either property, until there *exists* some standard
>> allocator having the property, which is not likely ever to happen. It's
>> easy to hack up the existence and detection mechanisms within your own
>> codebase, as you've done, and then provide `my::allocate_unique` to expl=
oit
>> them. You don't need to be friends with `std::unique_ptr` to make that
>> happen; you just need to provide a custom deleter type, which is already
>> possible in standard C++.
>>
>
> Custom deleter only gives us the noop deallocation, trivial destruction o=
f
> unique_ptr requires more.
> Should P0316R0 "allocate_unique and allocator_delete" only consider the
> standard allocator? If it makes it into that standard then it will need t=
o
> allow specialized allocator_delete?
> In my other post (
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmE=
s5Isw)
> I show limitations of the winked-out optimization with existing container=
s
> and existing allocators. This may motivate the need for either more
> allocators in the standard or better facilities to make your own.
>
> --
> 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/abd7a3bc-e43=
8-4fa3-b26a-a8888bfec11a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abd7a3bc-e4=
38-4fa3-b26a-a8888bfec11a%40isocpp.org?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/CAP3wax_tk%2B_%3DGiVrsCUFrDvzV08OOcpMkK7j%3Dk_Uf=
hZmAVCuiA%40mail.gmail.com.
--0000000000008e86370578f41a5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>An example of a weird destroy: the object lives on a=
n accelerator and needs to be destroyed by a thread local to the accelerato=
r.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 22, 2018,=
5:17 PM Gareth Lloyd <<a href=3D"mailto:gareth@ignition-web.co.uk">gare=
th@ignition-web.co.uk</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><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>IIUC and AFAICT, the only situation where this comes up in practice i=
s with memory resources (heaps) where `deallocate` is a no-op.</div><div><b=
r></div><div>In practice `destroy` is always "stateless" because =
its behavior depends only on the type T being destroyed, not on the identit=
y of the allocator doing the destruction. (In fact, I think Mark Zeren is w=
orking on a proposal to deprecate `destroy`, although I don't see it in=
the pre=E2=80=93San Diego mailing.)</div></div></blockquote><div><br></div=
><div>I can't think of a useful customization of `destroy` but one may =
exist, I'd like to hear more on the idea of deprecating it.<br></div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>Furthermore, observe that when `has_trivial_deallocate_v<A<T>>=
;`, then the `unique_ptr` returned from `allocate_unique<T, A<T>&g=
t;` can be <i><b>trivially destructible</b></i>. This seems like a very nic=
e property to have, philosophically speaking, even though I can't off t=
he top of my head come up with any concrete application for it.</div></div>=
</blockquote><div><br></div><div>`unique_ptr` itself would need specializin=
g to make it actually trivially destructibe and not just noop destructor. v=
alue_type must be trivailly destructible, allocator uses default destroy an=
d noop deallocate. (On a related note see <a href=3D"https://groups.google.=
com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw" target=3D"_blank"=
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/forum/#!topic/st=
d-proposals/Rx3EmEs5Isw</a>)<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><div>A compromise approach =
might be to permit the allocator to specify a member typedef `using deleter=
=3D ...` (defaulted to `allocator_delete<A<T>>` in `allocator_=
traits`) which could be customized by the designer of the allocator type. T=
hen this deleter could be stateless and/or have a trivial `deallocate` meth=
od.</div></div></blockquote><div><br></div><div>This possibly hints that a =
dual concept of a `maker` to mirror that of the `deleter`. Those would be a=
convient allocator_trait additions to have.<br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Bottom lines:</di=
v><div>- I think the property of <i><b>trivial</b></i> deallocate is much m=
ore directly relevant to your use-case than is the property of=C2=A0<i><b>s=
tateless</b></i> deallocate.</div></div></blockquote><div>=C2=A0</div><div>=
I think both are important.<br></div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>- I think it is not worth asking WG2=
1 to pursue the <i><b>detection and exploitation</b></i> of either property=
, until there <i><b>exists</b></i> some standard allocator having the prope=
rty, which is not likely ever to happen. It's easy to hack up the exist=
ence and detection mechanisms within your own codebase, as you've done,=
and then provide `my::allocate_unique` to exploit them. You don't need=
to be friends with `std::unique_ptr` to make that happen; you just need to=
provide a custom deleter type, which is already possible in standard C++.<=
/div></div></blockquote><div><br></div><div>Custom deleter only gives us th=
e noop deallocation, trivial destruction of unique_ptr requires more.</div>=
<div>Should P0316R0 "allocate_unique and allocator_delete" only c=
onsider the standard allocator? If it makes it into that standard then it w=
ill need to allow specialized allocator_delete?</div><div>In my other post =
(<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos=
als/Rx3EmEs5Isw" target=3D"_blank" rel=3D"noreferrer">https://groups.google=
..com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw</a>) I show limit=
ations of the winked-out optimization with existing containers and existing=
allocators. This may motivate the need for either more allocators in the s=
tandard or better facilities to make your own.<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" rel=3D"noreferrer">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" rel=3D"noreferrer">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/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%40isocpp.org</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAP3wax_tk%2B_%3DGiVrsCUFrDvzV08OOcpM=
kK7j%3Dk_UfhZmAVCuiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAP3wax_tk%=
2B_%3DGiVrsCUFrDvzV08OOcpMkK7j%3Dk_UfhZmAVCuiA%40mail.gmail.com</a>.<br />
--0000000000008e86370578f41a5d--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 26 Oct 2018 23:07:21 -0400
Raw View
--00000000000011859605792d23a0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 22, 2018 at 8:17 PM Gareth Lloyd <gareth@ignition-web.co.uk>
wrote:
> IIUC and AFAICT, the only situation where this comes up in practice is
>> with memory resources (heaps) where `deallocate` is a no-op.
>>
>> In practice `destroy` is always "stateless" because its behavior depends
>> only on the type T being destroyed, not on the identity of the allocator
>> doing the destruction. (In fact, I think Mark Zeren is working on a
>> proposal to deprecate `destroy`, although I don't see it in the pre=E2=
=80=93San
>> Diego mailing.)
>>
>
> I can't think of a useful customization of `destroy` but one may exist,
> I'd like to hear more on the idea of deprecating it.
>
>
>> Furthermore, observe that when `has_trivial_deallocate_v<A<T>>`, then th=
e
>> `unique_ptr` returned from `allocate_unique<T, A<T>>` can be *trivially
>> destructible*. This seems like a very nice property to have,
>> philosophically speaking, even though I can't off the top of my head com=
e
>> up with any concrete application for it.
>>
>
> `unique_ptr` itself would need specializing to make it actually trivially
> destructible and not just noop destructor.
>
Right. This is the only reason (AFAICT) why you'd desire cooperation from
the standard library. Everything else you want to do =E2=80=94 everything *=
except*
make unique_ptr trivially destructible =E2=80=94 can be done inside
your::allocate_unique() in plain vanilla C++11 with no cooperation from the
standard library at all.
> value_type must be trivially destructible, allocator uses default destroy
> and noop deallocate. (On a related note see
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmE=
s5Isw
> )
>
For the former, std::is_trivially_destructible<ValueType> is provided by
the standard library.
For the latter two, your::allocate_unique() would have to examine
your::has_noop_deallocate_method<Allocator>, but that's fine because no
*standard* allocators have noop `deallocate` methods, so you don't have to
cooperate with the standard library for that one.
=E2=80=93Arthur
--=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/CADvuK0LocKvswhVB%2BiAtNCGazpJPKFwgMv0thmA8T_u%2=
BxETbYA%40mail.gmail.com.
--00000000000011859605792d23a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Oct 22, 2018 at 8:17 PM Gareth Lloyd <<a href=
=3D"mailto:gareth@ignition-web.co.uk">gareth@ignition-web.co.uk</a>> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>IIUC=
and AFAICT, the only situation where this comes up in practice is with mem=
ory resources (heaps) where `deallocate` is a no-op.</div><div><br></div><d=
iv>In practice `destroy` is always "stateless" because its behavi=
or depends only on the type T being destroyed, not on the identity of the a=
llocator doing the destruction. (In fact, I think Mark Zeren is working on =
a proposal to deprecate `destroy`, although I don't see it in the pre=
=E2=80=93San Diego mailing.)</div></div></blockquote><div><br></div><div>I =
can't think of a useful customization of `destroy` but one may exist, I=
'd like to hear more on the idea of deprecating it.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Furt=
hermore, observe that when `has_trivial_deallocate_v<A<T>>`, th=
en the `unique_ptr` returned from `allocate_unique<T, A<T>>` ca=
n be <i><b>trivially destructible</b></i>. This seems like a very nice prop=
erty to have, philosophically speaking, even though I can't off the top=
of my head come up with any concrete application for it.</div></div></bloc=
kquote><div><br></div><div>`unique_ptr` itself would need specializing to m=
ake it actually trivially destructible and not just noop destructor.</div><=
/div></blockquote><div><br></div><div>Right. This is the only reason (AFAIC=
T) why you'd desire cooperation from the standard library. Everything e=
lse you want to do =E2=80=94 everything <i><b>except</b></i> make unique_pt=
r trivially destructible =E2=80=94 can be done inside your::allocate_unique=
() in plain vanilla C++11 with no cooperation from the standard library at =
all.</div><div>=C2=A0</div><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> value_type must be trivially destructible, allocator uses default des=
troy and noop deallocate. (On a related note see <a href=3D"https://groups.=
google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/=
Rx3EmEs5Isw</a>)<br></div></div></blockquote><div><br></div><div>For the fo=
rmer, std::is_trivially_destructible<ValueType> is provided by the st=
andard library.</div><div>For the latter two, your::allocate_unique() would=
have to examine your::has_noop_deallocate_method<Allocator>, but tha=
t's fine because no <i>standard</i> allocators have noop `deallocate` m=
ethods, so you don't have to cooperate with the standard library for th=
at one.</div><div><br></div><div>=E2=80=93Arthur</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CADvuK0LocKvswhVB%2BiAtNCGazpJPKFwgMv=
0thmA8T_u%2BxETbYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LocKvs=
whVB%2BiAtNCGazpJPKFwgMv0thmA8T_u%2BxETbYA%40mail.gmail.com</a>.<br />
--00000000000011859605792d23a0--
.
Author: Gareth Lloyd <gareth@ignition-web.co.uk>
Date: Mon, 29 Oct 2018 22:52:47 +0000
Raw View
--000000000000499da3057965ee8a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Furthermore, observe that when `has_trivial_deallocate_v<A<T>>`, then the
>>> `unique_ptr` returned from `allocate_unique<T, A<T>>` can be *trivially
>>> destructible*. This seems like a very nice property to have,
>>> philosophically speaking, even though I can't off the top of my head co=
me
>>> up with any concrete application for it.
>>>
>>
>> `unique_ptr` itself would need specializing to make it actually triviall=
y
>> destructible and not just noop destructor.
>>
>
> Right. This is the only reason (AFAICT) why you'd desire cooperation from
> the standard library. Everything else you want to do =E2=80=94 everything=
*except*
> make unique_ptr trivially destructible =E2=80=94 can be done inside
> your::allocate_unique() in plain vanilla C++11 with no cooperation from t=
he
> standard library at all.
>
>
>> value_type must be trivially destructible, allocator uses default destro=
y
>> and noop deallocate. (On a related note see
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3Em=
Es5Isw
>> )
>>
>
> For the former, std::is_trivially_destructible<ValueType> is provided by
> the standard library.
> For the latter two, your::allocate_unique() would have to examine
> your::has_noop_deallocate_method<Allocator>, but that's fine because no
> *standard* allocators have noop `deallocate` methods, so you don't have
> to cooperate with the standard library for that one.
>
I urge that you read '=E2=80=9CWinked-out=E2=80=9D optimization on generic =
collections"'
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5=
Isw
if you have not already. It should help frame my motivations better.
It is not just unique_ptr this applies to, I have considering more that
that. I desire such a facility within the standard library because
something like this is required to enable all types in the standard, that
use allocators, to have a standard mechanism to be trivial_destructible
depending upon the provided allocator.
These posts are based on a code transformation process, based on John Lakos
ACCU and CppCon talks, that I've done on the codebase I work on. Using the
PMR pattern with monotonic_buffer_resource lost the winked out optimization
(LTO didn't help) and trivial destructable types that the codebase
previously had. I did this work because of the shortcomings I found with
using std::pmr::monotonic_buffer_resource with generic code. This pattern
allowed me to decouple the allocator used (using regular allocator concept)
which helps with testing a component, but in production still have an
optimized datastructure with the more optimizable monotonic allocator given
via template parameter. My findings were that current set of standard
allocators are not complete/finished, pmr has demonstrated one way to do
allocators but it is not nessisarily the holy grale or the end.
--=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/CANgTfEhvTfauen%3DGS71y11T%2BQY48Z7joDNXB5O5T%3D=
8LpYNgTJg%40mail.gmail.com.
--000000000000499da3057965ee8a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br><br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div>Furthermore, observe that when `has_tri=
vial_deallocate_v<A<T>>`, then the `unique_ptr` returned from `=
allocate_unique<T, A<T>>` can be <i><b>trivially destructible</=
b></i>. This seems like a very nice property to have, philosophically speak=
ing, even though I can't off the top of my head come up with any concre=
te application for it.</div></div></blockquote><div><br></div><div>`unique_=
ptr` itself would need specializing to make it actually trivially destructi=
ble and not just noop destructor.</div></div></blockquote><div><br></div><d=
iv>Right. This is the only reason (AFAICT) why you'd desire cooperation=
from the standard library. Everything else you want to do =E2=80=94 everyt=
hing <i><b>except</b></i> make unique_ptr trivially destructible =E2=80=94 =
can be done inside your::allocate_unique() in plain vanilla C++11 with no c=
ooperation from the standard library at all.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div> value_type=
must be trivially destructible, allocator uses default destroy and noop de=
allocate. (On a related note see <a href=3D"https://groups.google.com/a/iso=
cpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw" target=3D"_blank">https://=
groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw</a>)=
<br></div></div></blockquote><div><br></div><div>For the former, std::is_tr=
ivially_destructible<ValueType> is provided by the standard library.<=
/div><div>For the latter two, your::allocate_unique() would have to examine=
your::has_noop_deallocate_method<Allocator>, but that's fine bec=
ause no <i>standard</i> allocators have noop `deallocate` methods, so you d=
on't have to cooperate with the standard library for that one.</div></d=
iv></div></blockquote><div><br></div><div>I urge that you read '<span c=
lass=3D"gmail-F0XO1GC-mb-Y" id=3D"gmail-t-t">=E2=80=9CWinked-out=E2=80=9D o=
ptimization on generic collections</span>"' <a href=3D"https://gro=
ups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos=
als/Rx3EmEs5Isw</a> if you have not already. It should help frame my motiva=
tions better.</div><div><br></div><div>It is not just unique_ptr this appli=
es to, I have considering more that that. I desire such a facility within t=
he standard library because something like this is required to enable all t=
ypes in the standard, that use allocators, to have a standard mechanism to =
be trivial_destructible depending upon the provided allocator. <br></div><d=
iv><br></div><div>These posts are based on a code transformation process, b=
ased on John Lakos ACCU and CppCon talks, that I've done on the codebas=
e I work on. Using the PMR pattern with=20
monotonic_buffer_resource
lost the winked out optimization (LTO didn't help) and trivial destruct=
able types that the codebase previously had.=20
I did this work because of the shortcomings I found with using=20
std::pmr::monotonic_buffer_resource with generic code. This pattern allowed=
me to decouple the allocator used (using regular allocator concept) which =
helps with testing a component, but in production still have an optimized d=
atastructure with the more optimizable monotonic allocator given via templa=
te parameter. My findings were that current set of standard allocators are
not complete/finished, pmr has demonstrated one way to do allocators=20
but it is not nessisarily the holy grale or the end.=20
</div></div></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" 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/CANgTfEhvTfauen%3DGS71y11T%2BQY48Z7jo=
DNXB5O5T%3D8LpYNgTJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANgTfEhvTf=
auen%3DGS71y11T%2BQY48Z7joDNXB5O5T%3D8LpYNgTJg%40mail.gmail.com</a>.<br />
--000000000000499da3057965ee8a--
.