Topic: About allocator_delete
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 28 Nov 2018 22:10:11 -0800 (PST)
Raw View
------=_Part_2703_1263479069.1543471811246
Content-Type: multipart/alternative;
boundary="----=_Part_2704_30061964.1543471811246"
------=_Part_2704_30061964.1543471811246
Content-Type: text/plain; charset="UTF-8"
Some questions about deleter for allocators:
1. What is the status of P0316
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0316r0.html>?
I find the original post
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/07hKDrCgmW0>,
but no responses and progresses. Is it superseded by P0211
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html>?
2. There are subtle differences of interface design. Not all of them are
addressed by the papers. For example, why is it necessary to parameterize
on T in P0316
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0316r0.html>?
Is the omission of accessor of the allocator intentionally in P0211
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html>?
3. Are there any prior art considered, like this
<https://github.com/facebook/folly/blob/master/folly/Memory.h#L591>?
4. What about deleter without call of destroy like libc++'s
__allocator_destructor
<https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L3194>
(... despite its name)? This is mentioned as boilerplate implementation in
the allocate_unique section in P0316
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0316r0.html>,
but it is not a part of proposed interface. And if needed, what name should
be?
5. What does it mean "This constructor shall not participate in overload
resolution unless A, ignoring qualifications, is not
allocation_deleter<A>." in subclause [unique.ptr.dltr.alloc] of proposed
change of P0211R2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html>?
6. The names in P0211R2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html>look
like more inconsistent with each other and "using operator {new,delete}",
compared to the original reversion
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0211r0.html>.
The rationale seems not sufficient. I don't find any documented discussion
of the request. Are there more detailed descriptions?
--
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/e3a09c82-8227-469b-9a55-8f8612b41695%40isocpp.org.
------=_Part_2704_30061964.1543471811246
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some questions about deleter for allocators:<br><br><ol><l=
i>What is the status of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2017/p0316r0.html">P0316</a>? I find <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/forum/#!topic/std-proposals/07hKDrCgmW0">the origina=
l post</a>, but no responses and progresses. Is it superseded by <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html">P021=
1</a>?<br></li><li>There are subtle differences of interface design. Not al=
l of them are addressed by the papers. For example, why is it necessary to =
parameterize on <span style=3D"font-family: courier new,monospace;">T</span=
> in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p03=
16r0.html">P0316</a>? Is the omission of accessor of the allocator intentio=
nally in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018=
/p0211r2.html">P0211</a>?</li><li>Are there any prior art considered, like =
<a href=3D"https://github.com/facebook/folly/blob/master/folly/Memory.h#L59=
1">this</a>?<br></li><li>What about deleter without call of <span style=3D"=
font-family: courier new,monospace;">destroy</span> like libc++'s <a hr=
ef=3D"https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L319=
4"><span style=3D"font-family: courier new,monospace;">__allocator_destruct=
or</span></a> (... despite its name)? This is mentioned as boilerplate impl=
ementation in the <span style=3D"font-family: courier new,monospace;">alloc=
ate_unique</span> section in <a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2017/p0316r0.html">P0316</a>, but it is not a part of propo=
sed interface. And if needed, what name should be?<br></li><li>What does it=
mean "This constructor shall not participate in overload resolution u=
nless
<code>A</code>, ignoring qualifications, is not <code>allocation_de=
leter<A></code>." in subclause [unique.ptr.dltr.alloc] of propos=
ed change of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2018/p0211r2.html">P0211R2</a>?</li><li>The names in <a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0211r2.html">P0211R2 </a>look=
like more inconsistent with each other and "using <code>operator {new=
,delete}</code>", compared to <a href=3D"http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2016/p0211r0.html">the original reversion</a>. The ra=
tionale seems not sufficient. I don't find any documented discussion of=
the request. Are there more detailed descriptions?<br></li></ol><br></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/e3a09c82-8227-469b-9a55-8f8612b41695%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3a09c82-8227-469b-9a55-8f8612b41695=
%40isocpp.org</a>.<br />
------=_Part_2704_30061964.1543471811246--
------=_Part_2703_1263479069.1543471811246--
.
Author: =?UTF-8?Q?=27Thomas_K=C3=B6ppe=27_via_ISO_C=2B=2B_Standard_=2D_Future_Proposals?= <std-proposals@isocpp.org>
Date: Thu, 29 Nov 2018 11:11:25 -0800 (PST)
Raw View
------=_Part_2938_954849220.1543518685187
Content-Type: multipart/alternative;
boundary="----=_Part_2939_1604947393.1543518685187"
------=_Part_2939_1604947393.1543518685187
Content-Type: text/plain; charset="UTF-8"
I can give a few answers regarding P0211 only:
Re 3) Prior art like https://stackoverflow.com/a/23132307 was considered
(as stated), but not the one you linked. I think extensions to the deleter
to allow allocator access are reasonable and may very well be added.
Re 4) (not sure that is relevant; that's just a different thing that may be
proposed separately)
Re 5) That was an error in responding to review feedback. It's the other
overload (the constructor template) that needs to be constrained to not be
ambiguous with the copy constructor.
Re 6) The original version did indeed use "allocate_delete" for the *deleter
type*, and while I understand that that's consistent with "default_delete",
it is also super confusing in the presence of "make_shared" and
"allocate_shared", because it really sounds like a verb. Then we could have
used "allocate_delete" also for the name of the deallocation function, but
that'd be a clash. So the idea was to just move away from this entire
confusing situation and use a different set of names where each name is at
least internally sensible, even if they don't create an obvious parallel
with "default_delete". (But I'd wager that most people don't know that
"default_delete" exists, so I don't even think that that kind of
"consistency" would buy us very much.)
Thanks for your feedback!
--
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/4e50792a-fbe7-426e-b1be-f7d9354578e3%40isocpp.org.
------=_Part_2939_1604947393.1543518685187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I can give a few answers regarding P0211 only:<div><br></d=
iv><div>Re 3) Prior art like=C2=A0https://stackoverflow.com/a/23132307 was =
considered (as stated), but not the one you linked. I think extensions to t=
he deleter to allow allocator access are reasonable and may very well be ad=
ded.</div><div><br></div><div>Re 4) (not sure that is relevant; that's =
just a different thing that may be proposed separately)</div><div><br></div=
><div>Re 5) That was an error in responding to review feedback. It's th=
e other overload (the constructor template) that needs to be constrained to=
not be ambiguous with the copy constructor.</div><div><br></div><div>Re 6)=
The original version did indeed use "allocate_delete" for the <i=
>deleter type</i>, and while I understand that that's consistent with &=
quot;default_delete", it is also super confusing in the presence of &q=
uot;make_shared" and "allocate_shared", because it really so=
unds like a verb. Then we could have used "allocate_delete" also =
for the name of the deallocation function, but that'd be a clash. So th=
e idea was to just move away from this entire confusing situation and use a=
different set of names where each name is at least internally sensible, ev=
en if they don't create an obvious parallel with "default_delete&q=
uot;. (But I'd wager that most people don't know that "default=
_delete" exists, so I don't even think that that kind of "con=
sistency" would buy us very much.)</div><div><br></div><div>Thanks for=
your feedback!</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/4e50792a-fbe7-426e-b1be-f7d9354578e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e50792a-fbe7-426e-b1be-f7d9354578e3=
%40isocpp.org</a>.<br />
------=_Part_2939_1604947393.1543518685187--
------=_Part_2938_954849220.1543518685187--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 30 Nov 2018 04:24:34 -0800 (PST)
Raw View
------=_Part_2522_287220682.1543580674945
Content-Type: multipart/alternative;
boundary="----=_Part_2523_253933841.1543580674945"
------=_Part_2523_253933841.1543580674945
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=883:11:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=EF=
=BC=9A
>
> I can give a few answers regarding P0211 only:
>
> Re 3) Prior art like https://stackoverflow.com/a/23132307 was considered=
=20
> (as stated), but not the one you linked. I think extensions to the delete=
r=20
> to allow allocator access are reasonable and may very well be added.
>
OK. Here is a related question: given there can be different type signature=
=20
of get_allocator in existed designs, which form should it be? I have=20
noticed in P0316, allocator_delete has a specialization allowing access the=
=20
non-const allocator lvalue, while other designs return const Allocator&.=20
Both are different to traditional by-value returning in containers, though.=
=20
The former seems unusual to allocator model in the standard (where even=20
stateful ones will often be expectedly copied), but it looks like more=20
consistent with the design of unique_ptr's use of deleters.
>
> Re 4) (not sure that is relevant; that's just a different thing that may=
=20
> be proposed separately)
>
> I agree it is different. (Then I have to figure out another name because=
=20
it looks like nice and clean, even it is not necessarily worth being added=
=20
to std.)
=20
> Re 5) That was an error in responding to review feedback. It's the other=
=20
> overload (the constructor template) that needs to be constrained to not b=
e=20
> ambiguous with the copy constructor.
>
> Re 6) The original version did indeed use "allocate_delete" for the *dele=
ter=20
> type*, and while I understand that that's consistent with=20
> "default_delete", it is also super confusing in the presence of=20
> "make_shared" and "allocate_shared", because it really sounds like a verb=
..=20
> Then we could have used "allocate_delete" also for the name of the=20
> deallocation function, but that'd be a clash. So the idea was to just mov=
e=20
> away from this entire confusing situation and use a different set of name=
s=20
> where each name is at least internally sensible, even if they don't creat=
e=20
> an obvious parallel with "default_delete". (But I'd wager that most peopl=
e=20
> don't know that "default_delete" exists, so I don't even think that that=
=20
> kind of "consistency" would buy us very much.)
>
> As I have known, many candidate designs use the name allocator_delete as=
=20
well as allocate_unique (like in folly). It looks like the confusion in the=
=20
verbal form does not raise as a major problem to the designer of such=20
interface (since I see no one has mentioned it explicitly). Even if so, the=
=20
confusion is already in std, and it will last before we deprecate and=20
rename default_delete. When would such change happen in future? Or is it=20
probable to occur? (I'd wager those who want to use the deleter type will=
=20
eventually know the role of default_delete in unique_ptr, since there is=20
little chance to solely use a deleter.)
That said, besides the consistency with default_delete, renaming allocator_=
delete=20
to allocation_deleter seems plausible, although renaming allocator to=20
allocation is also serving to the consistency.
=20
> Thanks for your feedback!
>
Now I also have concerns with allocator_new and allocator_delete.
=20
1. Why does allocator_new always take a A& and create a fresh allocator=
=20
object before the actual allocation?
2. It seems that they are not very intuitively recurring the effect of=
=20
new/delete operators, as the operators does not do "rebind". And what=20
about being members of allocator_traits<A>?
3. What about array allocation? (Note: allocate_unique<T[]> is also an=
=20
open issue in P0316.)
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a7177072-4b01-4f7b-b4c6-c0d4d8eac750%40isocpp.or=
g.
------=_Part_2523_253933841.1543580674945
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=883:11:25=EF=BC=8CThomas K=C3=
=B6ppe=E5=86=99=E9=81=93=EF=BC=9A<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">I can give a few answers regarding P0211 only:<div><br>=
</div><div>Re 3) Prior art like=C2=A0<a href=3D"https://stackoverflow.com/a=
/23132307" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa%2F23=
132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk4TOFFQ=
';return true;" onclick=3D"this.href=3D'https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa%2F23132307\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk4TOFFQ';return true;">https://st=
ackoverflow.<wbr>com/a/23132307</a> was considered (as stated), but not the=
one you linked. I think extensions to the deleter to allow allocator acces=
s are reasonable and may very well be added.</div></div></blockquote><div>O=
K. Here is a related question: given there can be different type signature =
of <span style=3D"font-family: courier new,monospace;">get_allocator</span>=
in existed designs, which form should it be? I have noticed in P0316, <spa=
n style=3D"font-family: courier new,monospace;">allocator_delete</span> has=
a specialization allowing access the non-const allocator lvalue, while oth=
er designs return <span style=3D"font-family: courier new,monospace;">const=
Allocator&</span>. Both are different to traditional by-value returnin=
g in containers, though. The former seems unusual to allocator model in the=
standard (where even stateful ones will often be expectedly copied), but i=
t looks like more consistent with the design of <span style=3D"font-family:=
courier new,monospace;">unique_ptr</span>'s use of deleters.<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></di=
v><div>Re 4) (not sure that is relevant; that's just a different thing =
that may be proposed separately)</div><div><br></div></div></blockquote><di=
v>I agree it is different. (Then I have to figure out another name because =
it looks like nice and clean, even it is not necessarily worth being added =
to <span style=3D"font-family: courier new,monospace;">std</span>.)<br>=C2=
=A0<br></div><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></div><div>Re 5) That was an error in responding to review feedback. I=
t's the other overload (the constructor template) that needs to be cons=
trained to not be ambiguous with the copy constructor.</div><div><br></div>=
<div>Re 6) The original version did indeed use "allocate_delete" =
for the <i>deleter type</i>, and while I understand that that's consist=
ent with "default_delete", it is also super confusing in the pres=
ence of "make_shared" and "allocate_shared", because it=
really sounds like a verb. Then we could have used "allocate_delete&q=
uot; also for the name of the deallocation function, but that'd be a cl=
ash. So the idea was to just move away from this entire confusing situation=
and use a different set of names where each name is at least internally se=
nsible, even if they don't create an obvious parallel with "defaul=
t_delete". (But I'd wager that most people don't know that &qu=
ot;default_delete" exists, so I don't even think that that kind of=
"consistency" would buy us very much.)</div><div><br></div></div=
></blockquote><div>As I have known, many candidate designs use the name <sp=
an style=3D"font-family: courier new,monospace;">allocator_delete</span> as=
well as <span style=3D"font-family: courier new,monospace;">allocate_uniqu=
e</span> (like in folly). It looks like the confusion in the verbal form do=
es not raise as a major problem to the designer of such interface (since I =
see no one has mentioned it explicitly). Even if so, the confusion is alrea=
dy in <span style=3D"font-family: courier new,monospace;">std</span>, and i=
t will last before we deprecate and rename <span style=3D"font-family: cour=
ier new,monospace;">default_delete</span>. When would such change happen in=
future? Or is it probable to occur? (I'd wager those who want to use t=
he deleter type will eventually know the role of <span style=3D"font-family=
: courier new,monospace;">default_delete</span> in <span style=3D"font-fami=
ly: courier new,monospace;">unique_ptr</span>, since there is little chance=
to solely use a deleter.)<br><br>That said, besides the consistency with <=
span style=3D"font-family: courier new,monospace;">default_delete</span>, r=
enaming <span style=3D"font-family: courier new,monospace;">allocator_delet=
e </span>to <span style=3D"font-family: courier new,monospace;">allocation_=
deleter</span> seems plausible, although renaming <span style=3D"font-famil=
y: courier new,monospace;">allocator</span> to <span style=3D"font-family: =
courier new,monospace;">allocation</span> is also serving to the consistenc=
y.<br>=C2=A0<br></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></div><div>Thanks for your feedback!</div></div></blockquote>=
<div><br>Now I also have concerns with <span style=3D"font-family: courier =
new,monospace;">allocator_new</span> and <span style=3D"font-family: courie=
r new,monospace;">allocator_delete</span>.<br>=C2=A0<br><ol><li>Why does <s=
pan style=3D"font-family: courier new,monospace;">allocator_new</span> alwa=
ys take a <span style=3D"font-family: courier new,monospace;">A&</span>=
and create a fresh allocator object before the actual allocation?</li><li>=
It seems that they are not very intuitively recurring the effect of <span s=
tyle=3D"font-family: courier new,monospace;">new</span>/<span style=3D"font=
-family: courier new,monospace;">delete </span>operators, as the operators =
does not do "rebind". And what about being members of <span style=
=3D"font-family: courier new,monospace;">allocator_traits<A></span>?<=
/li><li>What about array allocation? (Note: <span style=3D"font-family: cou=
rier new,monospace;">allocate_unique<T[]></span> is also an open issu=
e in P0316.)<br></li></ol><p><br></p></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/a7177072-4b01-4f7b-b4c6-c0d4d8eac750%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7177072-4b01-4f7b-b4c6-c0d4d8eac750=
%40isocpp.org</a>.<br />
------=_Part_2523_253933841.1543580674945--
------=_Part_2522_287220682.1543580674945--
.
Author: =?UTF-8?Q?=27Thomas_K=C3=B6ppe=27_via_ISO_C=2B=2B_Standard_=2D_Future_Proposals?= <std-proposals@isocpp.org>
Date: Fri, 30 Nov 2018 05:33:25 -0800 (PST)
Raw View
------=_Part_2544_1577815103.1543584805722
Content-Type: multipart/alternative;
boundary="----=_Part_2545_32742518.1543584805723"
------=_Part_2545_32742518.1543584805723
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Friday, 30 November 2018 12:24:35 UTC, FrankHB1989 wrote:
>
> =E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 =
UTC+8=E4=B8=8A=E5=8D=883:11:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=
=EF=BC=9A
>>
>> I can give a few answers regarding P0211 only:
>>
>> Re 3) Prior art like https://stackoverflow.com/a/23132307 was considered=
=20
>> (as stated), but not the one you linked. I think extensions to the delet=
er=20
>> to allow allocator access are reasonable and may very well be added.
>>
> OK. Here is a related question: given there can be different type=20
> signature of get_allocator in existed designs, which form should it be? I=
=20
> have noticed in P0316, allocator_delete has a specialization allowing=20
> access the non-const allocator lvalue, while other designs return const=
=20
> Allocator&. Both are different to traditional by-value returning in=20
> containers, though. The former seems unusual to allocator model in the=20
> standard (where even stateful ones will often be expectedly copied), but =
it=20
> looks like more consistent with the design of unique_ptr's use of=20
> deleters.
>
I don't know what the interface would look like, since none has been=20
proposed :-) I'll make a note of this for future discussion, though.
=20
> Now I also have concerns with allocator_new and allocator_delete.=20
>
> 1. Why does allocator_new always take a A& and create a fresh=20
> allocator object before the actual allocation?
> 2. It seems that they are not very intuitively recurring the effect of=
=20
> new/delete operators, as the operators does not do "rebind". And what=
=20
> about being members of allocator_traits<A>?
> 3. What about array allocation? (Note: allocate_unique<T[]> is also an=
=20
> open issue in P0316.)
> =20
> Re 1) I think this was copying the design for allocate_shared, but I agre=
e=20
that allocate_unique does not require allocating an unknown type, so we=20
could make this more restrictive. Or we could say something like "rebinding=
=20
is only needed when A is not an allocator for T". I'll note that, too.
Re 2) I don't quite understand the question, could you rephrase?
Re 3) I expressly do not want to tackle using allocators for arrays. I=20
don't think this is a good fit in the language (I also don't like=20
allocate_shared for arrays), and I'd rather leave this fight to someone=20
else to fight. The scalar version is good enough for now. (We actually=20
discussed this briefly in LEWGI in San Diego.)
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/470ea9b8-2bd6-4eed-bd96-e6dcb403186f%40isocpp.or=
g.
------=_Part_2545_32742518.1543584805723
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, 30 November 2018 12:24:35 UTC, FrankHB1989 wro=
te:<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">=E5=9C=A8 =
2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=
=8A=E5=8D=883:11:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=EF=BC=9A<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I can give a few answ=
ers regarding P0211 only:<div><br></div><div>Re 3) Prior art like=C2=A0<a h=
ref=3D"https://stackoverflow.com/a/23132307" rel=3D"nofollow" target=3D"_bl=
ank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fstackoverflow.com%2Fa%2F23132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNGgsH7Tj-98YcTH5qG8ZPzk4TOFFQ';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa=
%2F23132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk4=
TOFFQ';return true;">https://stackoverflow.<wbr>com/a/23132307</a> was =
considered (as stated), but not the one you linked. I think extensions to t=
he deleter to allow allocator access are reasonable and may very well be ad=
ded.</div></div></blockquote><div>OK. Here is a related question: given the=
re can be different type signature of <span style=3D"font-family:courier ne=
w,monospace">get_allocator</span> in existed designs, which form should it =
be? I have noticed in P0316, <span style=3D"font-family:courier new,monospa=
ce">allocator_delete</span> has a specialization allowing access the non-co=
nst allocator lvalue, while other designs return <span style=3D"font-family=
:courier new,monospace">const Allocator&</span>. Both are different to =
traditional by-value returning in containers, though. The former seems unus=
ual to allocator model in the standard (where even stateful ones will often=
be expectedly copied), but it looks like more consistent with the design o=
f <span style=3D"font-family:courier new,monospace">unique_ptr</span>'s=
use of deleters.<br></div></div></blockquote><div><br></div><div>I don'=
;t know what the interface would look like, since none has been proposed :-=
) I'll make a note of this for future discussion, though.</div><div>=C2=
=A0<br></div><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>Now I also have concerns with <span style=3D"font-family:courier new,m=
onospace">allocator_new</span> and <span style=3D"font-family:courier new,m=
onospace">allocator_delete</span>.=C2=A0<br><ol><li>Why does <span style=3D=
"font-family:courier new,monospace">allocator_new</span> always take a <spa=
n style=3D"font-family:courier new,monospace">A&</span> and create a fr=
esh allocator object before the actual allocation?</li><li>It seems that th=
ey are not very intuitively recurring the effect of <span style=3D"font-fam=
ily:courier new,monospace">new</span>/<span style=3D"font-family:courier ne=
w,monospace">delete </span>operators, as the operators does not do "re=
bind". And what about being members of <span style=3D"font-family:cour=
ier new,monospace">allocator_traits<A></span>?</li><li>What about arr=
ay allocation? (Note: <span style=3D"font-family:courier new,monospace">all=
ocate_unique<T[]></span> is also an open issue in P0316.)<br></li></o=
l></div></div></blockquote><div>Re 1) I think this was copying the design f=
or allocate_shared, but I agree that allocate_unique does not require alloc=
ating an unknown type, so we could make this more restrictive. Or we could =
say something like "rebinding is only needed when A is not an allocato=
r for T". I'll note that, too.</div><div><br></div><div>Re 2) I do=
n't quite understand the question, could you rephrase?</div><div><br></=
div><div>Re 3) I expressly do not want to tackle using allocators for array=
s. I don't think this is a good fit in the language (I also don't l=
ike allocate_shared for arrays), and I'd rather leave this fight to som=
eone else to fight. The scalar version is good enough for now. (We actually=
discussed this briefly in LEWGI in San Diego.)</div><div><br></div><div>=
=C2=A0</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/470ea9b8-2bd6-4eed-bd96-e6dcb403186f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/470ea9b8-2bd6-4eed-bd96-e6dcb403186f=
%40isocpp.org</a>.<br />
------=_Part_2545_32742518.1543584805723--
------=_Part_2544_1577815103.1543584805722--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Fri, 30 Nov 2018 07:15:41 -0800 (PST)
Raw View
------=_Part_3545_1709937701.1543590941308
Content-Type: multipart/alternative;
boundary="----=_Part_3546_1575213499.1543590941309"
------=_Part_3546_1575213499.1543590941309
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8B=E5=8D=889:33:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Friday, 30 November 2018 12:24:35 UTC, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=
UTC+8=E4=B8=8A=E5=8D=883:11:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=
=EF=BC=9A
>>>
>>> I can give a few answers regarding P0211 only:
>>>
>>> Re 3) Prior art like https://stackoverflow.com/a/23132307 was=20
>>> considered (as stated), but not the one you linked. I think extensions =
to=20
>>> the deleter to allow allocator access are reasonable and may very well =
be=20
>>> added.
>>>
>> OK. Here is a related question: given there can be different type=20
>> signature of get_allocator in existed designs, which form should it be?=
=20
>> I have noticed in P0316, allocator_delete has a specialization allowing=
=20
>> access the non-const allocator lvalue, while other designs return const=
=20
>> Allocator&. Both are different to traditional by-value returning in=20
>> containers, though. The former seems unusual to allocator model in the=
=20
>> standard (where even stateful ones will often be expectedly copied), but=
it=20
>> looks like more consistent with the design of unique_ptr's use of=20
>> deleters.
>>
>
> I don't know what the interface would look like, since none has been=20
> proposed :-) I'll make a note of this for future discussion, though.
> =20
>
>> Now I also have concerns with allocator_new and allocator_delete.=20
>>
>> 1. Why does allocator_new always take a A& and create a fresh=20
>> allocator object before the actual allocation?
>> 2. It seems that they are not very intuitively recurring the effect=
=20
>> of new/delete operators, as the operators does not do "rebind". And=
=20
>> what about being members of allocator_traits<A>?
>> 3. What about array allocation? (Note: allocate_unique<T[]> is also=
=20
>> an open issue in P0316.)
>> =20
>> Re 1) I think this was copying the design for allocate_shared, but I=20
> agree that allocate_unique does not require allocating an unknown type, s=
o=20
> we could make this more restrictive. Or we could say something like=20
> "rebinding is only needed when A is not an allocator for T". I'll note=20
> that, too.
>
> Re 2) I don't quite understand the question, could you rephrase?
>
Sorry, I think I have misunderstood the correspondence. It is now clear to=
=20
me.
The picture shows auto p =3D allocator_new<T>(alloc, args...) is an analog =
of T=20
* p =3D new T(args...). IMO this is not quite precise with the syntax, if=
=20
considered separately. A more precise one can be T * p =3D new(alloc)=20
T(args...) where the underlying operator new has no knowledge about the=20
target type of rebinding. In this view, allocator_new does strictly more=20
things than new, which is not necessarily intuitive. And since it can=20
totally depend on the single allocator type, it is clearer if provided by a=
=20
specialization of allocator_traits (instead by the names=20
allocator_traits<T>::new_object/allocator_traits<T>::delete_object, for=20
example) which also makes the implementation simpler. This is at the cost=
=20
of (likely) lengthy client code at caller sites; but anyway, make calls to=
=20
such a low-level "unsafe" (possibly leaky) interface short is not=20
intentional.
Then I realized the alloc should be the *additional *argument as it in allo=
cate_unique<T>(alloc,=20
args...) or allocate_shared<T>(alloc, args...) so the analog is actually=20
appropriate. Not sure free function templates forms of allocator_new/
allocator_delete are preferred in general, though.=20
>
> Re 3) I expressly do not want to tackle using allocators for arrays. I=20
> don't think this is a good fit in the language (I also don't like=20
> allocate_shared for arrays), and I'd rather leave this fight to someone=
=20
> else to fight. The scalar version is good enough for now. (We actually=20
> discussed this briefly in LEWGI in San Diego.)
>
> =20
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2df6cbf0-c351-4daa-891b-3aec5b6562b2%40isocpp.or=
g.
------=_Part_3546_1575213499.1543590941309
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=889:33:25=EF=BC=8CThomas K=C3=
=B6ppe=E5=86=99=E9=81=93=EF=BC=9A<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">On Friday, 30 November 2018 12:24:35 UTC, FrankHB1989 =
wrote:<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">=E5=9C=A8 20=
18=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=
=E5=8D=883:11:25=EF=BC=8CThomas K=C3=B6ppe=E5=86=99=E9=81=93=EF=BC=9A<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I can give a few answers=
regarding P0211 only:<div><br></div><div>Re 3) Prior art like=C2=A0<a href=
=3D"https://stackoverflow.com/a/23132307" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fstackoverflow.com%2Fa%2F23132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGgsH7Tj-98YcTH5qG8ZPzk4TOFFQ';return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa%2F2=
3132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk4TOFF=
Q';return true;">https://stackoverflow.<wbr>com/a/23132307</a> was cons=
idered (as stated), but not the one you linked. I think extensions to the d=
eleter to allow allocator access are reasonable and may very well be added.=
</div></div></blockquote><div>OK. Here is a related question: given there c=
an be different type signature of <span style=3D"font-family:courier new,mo=
nospace">get_allocator</span> in existed designs, which form should it be? =
I have noticed in P0316, <span style=3D"font-family:courier new,monospace">=
allocator_delete</span> has a specialization allowing access the non-const =
allocator lvalue, while other designs return <span style=3D"font-family:cou=
rier new,monospace">const Allocator&</span>. Both are different to trad=
itional by-value returning in containers, though. The former seems unusual =
to allocator model in the standard (where even stateful ones will often be =
expectedly copied), but it looks like more consistent with the design of <s=
pan style=3D"font-family:courier new,monospace">unique_ptr</span>'s use=
of deleters.<br></div></div></blockquote><div><br></div><div>I don't k=
now what the interface would look like, since none has been proposed :-) I&=
#39;ll make a note of this for future discussion, though.</div><div>=C2=A0<=
br></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>Now =
I also have concerns with <span style=3D"font-family:courier new,monospace"=
>allocator_new</span> and <span style=3D"font-family:courier new,monospace"=
>allocator_delete</span>.=C2=A0<br><ol><li>Why does <span style=3D"font-fam=
ily:courier new,monospace">allocator_new</span> always take a <span style=
=3D"font-family:courier new,monospace">A&</span> and create a fresh all=
ocator object before the actual allocation?</li><li>It seems that they are =
not very intuitively recurring the effect of <span style=3D"font-family:cou=
rier new,monospace">new</span>/<span style=3D"font-family:courier new,monos=
pace">delete </span>operators, as the operators does not do "rebind&qu=
ot;. And what about being members of <span style=3D"font-family:courier new=
,monospace">allocator_traits<A></span>?</li><li>What about array allo=
cation? (Note: <span style=3D"font-family:courier new,monospace">allocate_u=
nique<T[]></span> is also an open issue in P0316.)<br></li></ol></div=
></div></blockquote><div>Re 1) I think this was copying the design for allo=
cate_shared, but I agree that allocate_unique does not require allocating a=
n unknown type, so we could make this more restrictive. Or we could say som=
ething like "rebinding is only needed when A is not an allocator for T=
". I'll note that, too.</div><div><br></div><div>Re 2) I don't=
quite understand the question, could you rephrase?</div></div></blockquote=
><div>Sorry, I think I have misunderstood the correspondence. It is now cle=
ar to me.<br><br>The picture shows <span style=3D"font-family: courier new,=
monospace;">auto p =3D allocator_new<T>(alloc, args...)</span> is an =
analog of <span style=3D"font-family: courier new,monospace;">T * p =3D new=
T(args...)</span>. IMO this is not quite precise with the syntax, if consi=
dered separately. A more precise one can be <span style=3D"font-family: cou=
rier new,monospace;">T * p =3D new(alloc) T(args...)</span> where the under=
lying <span style=3D"font-family: courier new,monospace;">operator new</spa=
n> has no knowledge about the target type of rebinding. In this view, <span=
style=3D"font-family: courier new,monospace;">allocator_new </span>does st=
rictly more things than <span style=3D"font-family: courier new,monospace;"=
>new</span>, which is not necessarily intuitive. And since it can totally d=
epend on the single allocator type, it is clearer if provided by a speciali=
zation of <span style=3D"font-family: courier new,monospace;">allocator_tra=
its</span> (instead by the names <span style=3D"font-family: courier new,mo=
nospace;">allocator_traits<T>::new_object</span>/<span style=3D"font-=
family: courier new,monospace;">allocator_traits<T>::delete_object</s=
pan>, for example)=C2=A0 which also makes the implementation simpler. This =
is at the cost of (likely) lengthy client code at caller sites; but anyway,=
make calls to such a low-level "unsafe" (possibly leaky) interfa=
ce short is not intentional.<br><br>Then I realized the <span style=3D"font=
-family: courier new,monospace;">alloc </span>should be the <i>additional <=
/i>argument as it in <code>allocate_unique<T>(alloc, args...)</code> =
or <code>allocate_shared<T>(alloc, args...)</code> so the analog is a=
ctually appropriate. Not sure free function templates forms of <span style=
=3D"font-family: courier new,monospace;">allocator_new</span>/<span style=
=3D"font-family: courier new,monospace;">allocator_delete</span> are prefer=
red in general, though. <br></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><br></div><div>Re 3) I expressly do not want to=
tackle using allocators for arrays. I don't think this is a good fit i=
n the language (I also don't like allocate_shared for arrays), and I=
9;d rather leave this fight to someone else to fight. The scalar version is=
good enough for now. (We actually discussed this briefly in LEWGI in San D=
iego.)</div><div><br></div><div>=C2=A0</div></div></blockquote></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/2df6cbf0-c351-4daa-891b-3aec5b6562b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2df6cbf0-c351-4daa-891b-3aec5b6562b2=
%40isocpp.org</a>.<br />
------=_Part_3546_1575213499.1543590941309--
------=_Part_3545_1709937701.1543590941308--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sat, 1 Dec 2018 05:03:48 -0800 (PST)
Raw View
------=_Part_3813_1340359418.1543669428982
Content-Type: multipart/alternative;
boundary="----=_Part_3814_471348148.1543669428982"
------=_Part_3814_471348148.1543669428982
Content-Type: text/plain; charset="UTF-8"
One more general question: what would nested allocator_type do for
non-container like class types like allocate_delete instances in P0316? Is
it safe to play with *uses-allocator* constructions?
--
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/a70d8498-4e14-42ca-bd2f-c76fc31b8ba8%40isocpp.org.
------=_Part_3814_471348148.1543669428982
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One more general question: what would nested <span style=
=3D"font-family: courier new,monospace;">allocator_type</span> do for non-c=
ontainer like class types like <span style=3D"font-family: courier new,mono=
space;">allocate_delete</span> instances in P0316? Is it safe to play with =
<i>uses-allocator</i> constructions?<br><br></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/a70d8498-4e14-42ca-bd2f-c76fc31b8ba8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a70d8498-4e14-42ca-bd2f-c76fc31b8ba8=
%40isocpp.org</a>.<br />
------=_Part_3814_471348148.1543669428982--
------=_Part_3813_1340359418.1543669428982--
.
Author: Gareth Lloyd <gareth@ignition-web.co.uk>
Date: Mon, 3 Dec 2018 10:31:25 +0000
Raw View
--000000000000665a00057c1ba770
Content-Type: text/plain; charset="UTF-8"
>
> Re 3) Prior art like https://stackoverflow.com/a/23132307 was considered
>> (as stated), but not the one you linked. I think extensions to the deleter
>> to allow allocator access are reasonable and may very well be added.
>>
> OK. Here is a related question: given there can be different type
> signature of get_allocator in existed designs, which form should it be? I
> have noticed in P0316, allocator_delete has a specialization allowing
> access the non-const allocator lvalue, while other designs return const
> Allocator&. Both are different to traditional by-value returning in
> containers, though. The former seems unusual to allocator model in the
> standard (where even stateful ones will often be expectedly copied), but it
> looks like more consistent with the design of unique_ptr's use of
> deleters.
>
I disagree it is not reasonable, access to allocator would remove
potential optimizations. Not all allocator based deleters need the full
allocator, if the destroy and deallocate methods of the allocator are
stateless then the deleter does not need a copy of the allocator. In those
situation were allocator isn't needed you can make a deleter which behaves
correctly but can not provide the actual allocator. Benifits of the deleter
in these situations is that it is stateless. Adding get_allocator would
take this optimization off the table.
See
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/EFE4sUpOCl4
--
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/CANgTfEg58iqCy2mB0FF7wRFbDFOSoWiiXAWOCUiVN_hfVEONsQ%40mail.gmail.com.
--000000000000665a00057c1ba770
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote cl=
ass=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"><blockquote class=3D"g=
mail_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>Re 3) Prior art like=C2=
=A0<a href=3D"https://stackoverflow.com/a/23132307" rel=3D"nofollow" target=
=3D"_blank">https://stackoverflow.com/a/23132307</a> was considered (as sta=
ted), but not the one you linked. I think extensions to the deleter to allo=
w allocator access are reasonable and may very well be added.</div></div></=
blockquote><div>OK. Here is a related question: given there can be differen=
t type signature of <span style=3D"font-family:courier new,monospace">get_a=
llocator</span> in existed designs, which form should it be? I have noticed=
in P0316, <span style=3D"font-family:courier new,monospace">allocator_dele=
te</span> has a specialization allowing access the non-const allocator lval=
ue, while other designs return <span style=3D"font-family:courier new,monos=
pace">const Allocator&</span>. Both are different to traditional by-val=
ue returning in containers, though. The former seems unusual to allocator m=
odel in the standard (where even stateful ones will often be expectedly cop=
ied), but it looks like more consistent with the design of <span style=3D"f=
ont-family:courier new,monospace">unique_ptr</span>'s use of deleters.<=
br></div></div></blockquote><div><br></div><div>=C2=A0I disagree it is not =
reasonable, access to allocator would remove potential optimizations. Not a=
ll allocator based deleters need the full allocator, if the destroy and dea=
llocate methods of the allocator are stateless then the deleter does not ne=
ed a copy of the allocator. In those situation were allocator isn't nee=
ded you can make a deleter which behaves correctly but can not provide the =
actual allocator. Benifits of the deleter in these situations is that it is=
stateless. Adding get_allocator would take this optimization off the table=
..</div><div><br></div><div>See <a href=3D"https://groups.google.com/a/isocp=
p.org/forum/#!topic/std-proposals/EFE4sUpOCl4">https://groups.google.com/a/=
isocpp.org/forum/#!topic/std-proposals/EFE4sUpOCl4</a><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" 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/CANgTfEg58iqCy2mB0FF7wRFbDFOSoWiiXAWO=
CUiVN_hfVEONsQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANgTfEg58iqCy2mB=
0FF7wRFbDFOSoWiiXAWOCUiVN_hfVEONsQ%40mail.gmail.com</a>.<br />
--000000000000665a00057c1ba770--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 13 Dec 2018 15:27:12 -0800 (PST)
Raw View
------=_Part_607_2031602385.1544743633036
Content-Type: multipart/alternative;
boundary="----=_Part_608_620416850.1544743633036"
------=_Part_608_620416850.1544743633036
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B412=E6=9C=883=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=886:31:41=EF=BC=8CGareth Lloyd=E5=86=99=E9=81=93=EF=BC=9A
>
> Re 3) Prior art like https://stackoverflow.com/a/23132307 was considered=
=20
>>> (as stated), but not the one you linked. I think extensions to the dele=
ter=20
>>> to allow allocator access are reasonable and may very well be added.
>>>
>> OK. Here is a related question: given there can be different type=20
>> signature of get_allocator in existed designs, which form should it be?=
=20
>> I have noticed in P0316, allocator_delete has a specialization allowing=
=20
>> access the non-const allocator lvalue, while other designs return const=
=20
>> Allocator&. Both are different to traditional by-value returning in=20
>> containers, though. The former seems unusual to allocator model in the=
=20
>> standard (where even stateful ones will often be expectedly copied), but=
it=20
>> looks like more consistent with the design of unique_ptr's use of=20
>> deleters.
>>
>
> I disagree it is not reasonable, access to allocator would remove=20
> potential optimizations. Not all allocator based deleters need the full=
=20
> allocator, if the destroy and deallocate methods of the allocator are=20
> stateless then the deleter does not need a copy of the allocator. In thos=
e=20
> situation were allocator isn't needed you can make a deleter which behave=
s=20
> correctly but can not provide the actual allocator. Benifits of the delet=
er=20
> in these situations is that it is stateless. Adding get_allocator would=
=20
> take this optimization off the table.
>
> I don't see this is necessarily true.
1. Being trivially desturctible is the easy way to implement the=20
optimization, but not the only way. The optimization does not need trivi=
al=20
destructors in general. And the destructor is not even needed to be=20
literally no-op when the allocator object can be inferred to be elided=
=20
(although I don't know any implementation, the as-if rules allows this).=
=20
conservatively (without requiring whole program analysis), it only needs=
=20
to be proved *pure*. (Consider __attribute__((pure)) instead of=20
__attribute__((const)).)
2. The deleter object can still be trivially destructible when the=20
allocator is accessible through it - just not to store the allocator=20
object, but the reference.=20
3. Missing access of allocator can also lead to less-optimized code, if=
=20
allocator access is actually needed. If access through deleter is=20
impossible, it should be touched elsewhere, e.g. keeping an extra refere=
nce=20
externally. This incurs unnecessary cost if the deleter already has to k=
eep=20
one. So the conclusion is not to simply keep away of allocator access fr=
om=20
the deleter, better let the user decide (e.g. configured through traits)=
..
=20
=20
> See=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/EFE4sU=
pOCl4
>
--=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/acf96164-6ec8-4242-afd1-204606e5424a%40isocpp.or=
g.
------=_Part_608_620416850.1544743633036
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B412=E6=9C=883=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=886:31:41=EF=BC=8CGareth Lloyd=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>Re 3) Prior art like=C2=A0<a=
href=3D"https://stackoverflow.com/a/23132307" rel=3D"nofollow" target=3D"_=
blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Fstackoverflow.com%2Fa%2F23132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk4TOFFQ';return true;" onclick=3D"this.hre=
f=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2F=
a%2F23132307\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGgsH7Tj-98YcTH5qG8ZPzk=
4TOFFQ';return true;">https://stackoverflow.<wbr>com/a/23132307</a> was=
considered (as stated), but not the one you linked. I think extensions to =
the deleter to allow allocator access are reasonable and may very well be a=
dded.</div></div></blockquote><div>OK. Here is a related question: given th=
ere can be different type signature of <span style=3D"font-family:courier n=
ew,monospace">get_allocator</span> in existed designs, which form should it=
be? I have noticed in P0316, <span style=3D"font-family:courier new,monosp=
ace">allocator_delete</span> has a specialization allowing access the non-c=
onst allocator lvalue, while other designs return <span style=3D"font-famil=
y:courier new,monospace">const Allocator&</span>. Both are different to=
traditional by-value returning in containers, though. The former seems unu=
sual to allocator model in the standard (where even stateful ones will ofte=
n be expectedly copied), but it looks like more consistent with the design =
of <span style=3D"font-family:courier new,monospace">unique_ptr</span>'=
s use of deleters.<br></div></div></blockquote><div><br></div><div>=C2=A0I =
disagree it is not reasonable, access to allocator would remove potential o=
ptimizations. Not all allocator based deleters need the full allocator, if =
the destroy and deallocate methods of the allocator are stateless then the =
deleter does not need a copy of the allocator. In those situation were allo=
cator isn't needed you can make a deleter which behaves correctly but c=
an not provide the actual allocator. Benifits of the deleter in these situa=
tions is that it is stateless. Adding get_allocator would take this optimiz=
ation off the table.</div><div><br></div></div></div></div></blockquote><di=
v>I don't see this is necessarily true.<br><ol><li>Being trivially dest=
urctible is the easy way to implement the optimization, but not the only wa=
y. The optimization does not need trivial destructors in general. And the d=
estructor is not even needed to be literally no-op when the allocator objec=
t can be inferred to be elided (although I don't know any implementatio=
n, the as-if rules allows this). <span class=3D"op_dict3_font24 op_dict3_ma=
rginRight">conservatively</span> (without requiring whole program analysis)=
, it only needs to be proved <i>pure</i>. (Consider <span style=3D"font-fam=
ily: courier new,monospace;">__attribute__((pure))</span> instead of <span =
style=3D"font-family: courier new,monospace;">__attribute__((const))</span>=
..)<br></li><li>The deleter object can still be trivially destructible when =
the allocator is accessible through it - just not to store the allocator ob=
ject, but the reference. <br></li><li>Missing access of allocator can also =
lead to less-optimized code, if allocator access is actually needed. If acc=
ess through deleter is impossible, it should be touched elsewhere, e.g. kee=
ping an extra reference externally. This incurs unnecessary cost if the del=
eter already has to keep one. So the conclusion is not to simply keep away =
of allocator access from the deleter, better let the user decide (e.g. conf=
igured through traits).<br></li></ol><br><br>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div></div><div>See <a href=3D"https://groups.google.com/a=
/isocpp.org/forum/#!topic/std-proposals/EFE4sUpOCl4" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/forum/#!topic/std-proposals/EFE4sUpOCl4';return true;" onclic=
k=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/=
std-proposals/EFE4sUpOCl4';return true;">https://groups.google.com/a/<w=
br>isocpp.org/forum/#!topic/std-<wbr>proposals/EFE4sUpOCl4</a><br></div></d=
iv></div></div>
</blockquote></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/acf96164-6ec8-4242-afd1-204606e5424a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/acf96164-6ec8-4242-afd1-204606e5424a=
%40isocpp.org</a>.<br />
------=_Part_608_620416850.1544743633036--
------=_Part_607_2031602385.1544743633036--
.