--000000000000c0438c056e4b639e
Content-Type: text/plain; charset="UTF-8"

The associative containers' "node handle" can either be constructed in an
empty state or be moved from another node handle. It is not possible to
create a node handle with arbitrary content "from scratch", without having
it extracted from a container.

A typical case when the currently impossible creation of node handles with
arbitrary content would be beneficial is a multi-threaded program where
access to a container has to be synchronised. In such a case it might be
beneficial to construct "the content", synchronise and and then insert
pre-created content.

Another, related, case occurs when the value needs some extra massage after
construction to make it fully usable, in which case it would be desirable
to pre-create it, massage, and then insert.

All of the above, of course, is achievable with an extra level of
indirection, with its corresponding (little) loss of efficiency and effort
for the programmer.

I am not proposing any particular syntax, but it seems fairly obvious that
such a node handle should be created either by a static member of the
container, with an allocator explicitly passed to it, or by a non-static
member with or without an allocator parameter, where the latter would use
the container's current allocator.

Opinions about this?

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0og7fKh95AJFcbVr%3DQ_BmbXoLTuAbgw8ASQgZX07pONw%40mail.gmail.com.

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

<div dir=3D"ltr">The associative containers&#39; &quot;node handle&quot; ca=
n either be constructed in an empty state or be moved from another node han=
dle. It is not possible to create a node handle with arbitrary content &quo=
t;from scratch&quot;, without having it extracted from a container.<div><br=
></div><div>A typical case when the currently impossible creation of node h=
andles with arbitrary content would be beneficial is a multi-threaded progr=
am where access to a container has to be synchronised. In such a case it mi=
ght be beneficial to construct &quot;the content&quot;, synchronise and and=
 then insert pre-created content.</div><div><br></div><div>Another, related=
, case occurs when the value needs some extra massage after construction to=
 make it fully usable, in which case it would be desirable to pre-create it=
, massage, and then insert.</div><div><br></div><div>All of the above, of c=
ourse, is achievable with an extra level of indirection, with its correspon=
ding (little) loss of efficiency and effort for the programmer.</div><div><=
br></div><div>I am not proposing any particular syntax, but it seems fairly=
 obvious that such a node handle should be created either by a static membe=
r of the container, with an allocator explicitly passed to it, or by a non-=
static member with or without an allocator parameter, where the latter woul=
d use the container&#39;s current allocator.</div><div><br></div><div>Opini=
ons about this?</div><div><br></div><div>Cheers,</div><div>V.</div></div>

<p></p>

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

--000000000000c0438c056e4b639e--

.

------=_Part_79295_2001730612.1528646569219
Content-Type: multipart/alternative;
 boundary="----=_Part_79296_608481726.1528646569219"

------=_Part_79296_608481726.1528646569219
Content-Type: text/plain; charset="UTF-8"



On Sunday, June 10, 2018 at 11:36:00 AM UTC-4, Viacheslav Usov wrote:
>
> The associative containers' "node handle" can either be constructed in an
> empty state or be moved from another node handle. It is not possible to
> create a node handle with arbitrary content "from scratch", without having
> it extracted from a container.
>
> A typical case when the currently impossible creation of node handles with
> arbitrary content would be beneficial is a multi-threaded program where
> access to a container has to be synchronised. In such a case it might be
> beneficial to construct "the content", synchronise and and then insert
> pre-created content.
>
> Another, related, case occurs when the value needs some extra massage
> after construction to make it fully usable, in which case it would be
> desirable to pre-create it, massage, and then insert.
>
> All of the above, of course, is achievable with an extra level of
> indirection, with its corresponding (little) loss of efficiency and effort
> for the programmer.
>

I assume by this you mean creating a container, inserting an item into it,
manipulating it in whatever way you prefer, and then extracting it into a
node_handle, yes?

With the exception of node containers that do allocation when empty, I
don't see why this would cause "loss of efficiency and effort for the
programmer". You could wrap it in your own function easily enough.

Also there is enough variance in terms of how you would insert and
manipulate such an element that it's best to leave that to the user.

--
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/2b6c3614-71ed-4144-9662-fa4d6028567f%40isocpp.org.

------=_Part_79296_608481726.1528646569219
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, June 10, 2018 at 11:36:00 AM UTC-4, Via=
cheslav Usov wrote:<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">The associative containers&#39; &quot;node handle&quot; can either be=
 constructed in an empty state or be moved from another node handle. It is =
not possible to create a node handle with arbitrary content &quot;from scra=
tch&quot;, without having it extracted from a container.<div><br></div><div=
>A typical case when the currently impossible creation of node handles with=
 arbitrary content would be beneficial is a multi-threaded program where ac=
cess to a container has to be synchronised. In such a case it might be bene=
ficial to construct &quot;the content&quot;, synchronise and and then inser=
t pre-created content.</div><div><br></div><div>Another, related, case occu=
rs when the value needs some extra massage after construction to make it fu=
lly usable, in which case it would be desirable to pre-create it, massage, =
and then insert.</div><div><br></div><div>All of the above, of course, is a=
chievable with an extra level of indirection, with its corresponding (littl=
e) loss of efficiency and effort for the programmer.</div></div></blockquot=
e><div><br></div><div>I assume by this you mean creating a container, inser=
ting an item into it, manipulating it in whatever way you prefer, and then =
extracting it into a node_handle, yes?</div><div><br></div><div>With the ex=
ception of node containers that do allocation when empty, I don&#39;t see w=
hy this would cause &quot;loss of efficiency and effort for the programmer&=
quot;. You could wrap it in your own function easily enough.</div><div><br>=
</div><div>Also there is enough variance in terms of how you would insert a=
nd manipulate such an element that it&#39;s best to leave that to the user.=
<br></div></div>

<p></p>

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

------=_Part_79296_608481726.1528646569219--

------=_Part_79295_2001730612.1528646569219--

.

--000000000000622f4c056e4c0554
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 10, 2018 at 6:02 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Sunday, June 10, 2018 at 11:36:00 AM UTC-4, Viacheslav Usov wrote:
>>
>> The associative containers' "node handle" can either be constructed in an
>> empty state or be moved from another node handle. It is not possible to
>> create a node handle with arbitrary content "from scratch", without having
>> it extracted from a container.
>>
>> A typical case when the currently impossible creation of node handles
>> with arbitrary content would be beneficial is a multi-threaded program
>> where access to a container has to be synchronised. In such a case it might
>> be beneficial to construct "the content", synchronise and and then insert
>> pre-created content.
>>
>> Another, related, case occurs when the value needs some extra massage
>> after construction to make it fully usable, in which case it would be
>> desirable to pre-create it, massage, and then insert.
>>
>> All of the above, of course, is achievable with an extra level of
>> indirection, with its corresponding (little) loss of efficiency and effort
>> for the programmer.
>>
>
> I assume by this you mean creating a container, inserting an item into it,
> manipulating it in whatever way you prefer, and then extracting it into a
> node_handle, yes?
>

I actually meant that instead of storing "values" in containers, you would
store pointers.

What you describe eliminates the need of that kind of indirection, but it
introduces other inefficiencies, like the allocation that you mentioned. It
may also be messy when said container has an optimised allocator. And,
frankly, it is conceptually ugly.

With the exception of node containers that do allocation when empty, I
> don't see why this would cause "loss of efficiency and effort for the
> programmer". You could wrap it in your own function easily enough.
>

That's a pretty significant exception to ignore, and such a wrapper is just
one of those things that makes one sink in boilerplate.

Also there is enough variance in terms of how you would insert and
> manipulate such an element that it's best to leave that to the user.
>

Node handles are already part of the standard. Once most of the work to
standardise node handles and especially the concept behind them has been
done, the lack of orthogonality is rather odd.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1PbE02veCdrLBsWxZ1L9RpNfUqH0CHwgtLZk9HqO5ksA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 10, 2018 at 6:02 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On S=
unday, June 10, 2018 at 11:36:00 AM UTC-4, Viacheslav Usov wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">The associative containers&#=
39; &quot;node handle&quot; can either be constructed in an empty state or =
be moved from another node handle. It is not possible to create a node hand=
le with arbitrary content &quot;from scratch&quot;, without having it extra=
cted from a container.<div><br></div><div>A typical case when the currently=
 impossible creation of node handles with arbitrary content would be benefi=
cial is a multi-threaded program where access to a container has to be sync=
hronised. In such a case it might be beneficial to construct &quot;the cont=
ent&quot;, synchronise and and then insert pre-created content.</div><div><=
br></div><div>Another, related, case occurs when the value needs some extra=
 massage after construction to make it fully usable, in which case it would=
 be desirable to pre-create it, massage, and then insert.</div><div><br></d=
iv><div>All of the above, of course, is achievable with an extra level of i=
ndirection, with its corresponding (little) loss of efficiency and effort f=
or the programmer.</div></div></blockquote><div><br></div><div>I assume by =
this you mean creating a container, inserting an item into it, manipulating=
 it in whatever way you prefer, and then extracting it into a node_handle, =
yes?</div></div></blockquote><div><br></div><div>I actually meant that inst=
ead of storing &quot;values&quot; in containers, you would store pointers.<=
/div><div><br></div><div>What you describe eliminates the need of that kind=
 of indirection, but it introduces other inefficiencies, like the allocatio=
n that you mentioned. It may also be messy when said container has an optim=
ised allocator. And, frankly, it is conceptually ugly.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>With the exception of =
node containers that do allocation when empty, I don&#39;t see why this wou=
ld cause &quot;loss of efficiency and effort for the programmer&quot;. You =
could wrap it in your own function easily enough.</div></div></blockquote><=
div><br></div><div>That&#39;s a pretty significant exception to ignore, and=
 such a wrapper is just one of those things that makes one sink in boilerpl=
ate.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>Also there is enough variance in terms of how you would insert and manip=
ulate such an element that it&#39;s best to leave that to the user.<br></di=
v></div></blockquote><div><br></div><div>Node handles are already part of t=
he standard. Once most of the work to standardise node handles and especial=
ly the concept behind them has been done, the lack of orthogonality is rath=
er odd.=C2=A0</div><div><br></div><div>Cheers,</div><div>V.</div></div></di=
v></div>

<p></p>

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

--000000000000622f4c056e4c0554--

.

------=_Part_79021_1691086490.1528655788782
Content-Type: multipart/alternative;
 boundary="----=_Part_79022_170805366.1528655788782"

------=_Part_79022_170805366.1528655788782
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 10, 2018 at 12:21:12 PM UTC-4, Viacheslav Usov wrote:
>
> On Sun, Jun 10, 2018 at 6:02 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Sunday, June 10, 2018 at 11:36:00 AM UTC-4, Viacheslav Usov wrote:
>>>
>>> The associative containers' "node handle" can either be constructed in
>>> an empty state or be moved from another node handle. It is not possible to
>>> create a node handle with arbitrary content "from scratch", without having
>>> it extracted from a container.
>>>
>>> A typical case when the currently impossible creation of node handles
>>> with arbitrary content would be beneficial is a multi-threaded program
>>> where access to a container has to be synchronised. In such a case it might
>>> be beneficial to construct "the content", synchronise and and then insert
>>> pre-created content.
>>>
>>> Another, related, case occurs when the value needs some extra massage
>>> after construction to make it fully usable, in which case it would be
>>> desirable to pre-create it, massage, and then insert.
>>>
>>> All of the above, of course, is achievable with an extra level of
>>> indirection, with its corresponding (little) loss of efficiency and effort
>>> for the programmer.
>>>
>>
>> I assume by this you mean creating a container, inserting an item into
>> it, manipulating it in whatever way you prefer, and then extracting it into
>> a node_handle, yes?
>>
>
> I actually meant that instead of storing "values" in containers, you would
> store pointers.
>
> What you describe eliminates the need of that kind of indirection, but it
> introduces other inefficiencies, like the allocation that you mentioned. It
> may also be messy when said container has an optimised allocator. And,
> frankly, it is conceptually ugly.
>

It's no more conceptually ugly than doing the same with `std::list`. I have
used a temporary list for the purpose of creating nodes, then quickly
`splice`d them into the list I actually wanted them stored in.

With the exception of node containers that do allocation when empty, I
>> don't see why this would cause "loss of efficiency and effort for the
>> programmer". You could wrap it in your own function easily enough.
>>
>
> That's a pretty significant exception to ignore,
>

It's also something that can be expunged by the standard forbidding it.
This would be a significant improvement, as it would make move constructors
`noexcept` for these types.

and such a wrapper is just one of those things that makes one sink in
> boilerplate.
>
> Also there is enough variance in terms of how you would insert and
>> manipulate such an element that it's best to leave that to the user.
>>
>
> Node handles are already part of the standard. Once most of the work to
> standardise node handles and especially the concept behind them has been
> done, the lack of orthogonality is rather odd.
>

It's merely a matter of what the feature is meant to accomplish. Node
handles are a way to transfer nodes across containers (ala
`std::list::splice`) and to manipulate the key of a node without having to
pay removal/insertion/allocation costs.

Nowhere on this list of use cases is manifesting a node_handle out of thin
air.

--
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/743db303-3e9d-469b-af71-dc5fafb07cdf%40isocpp.org.

------=_Part_79022_170805366.1528655788782
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, June 10, 2018 at 12:21:12 PM UTC-4, Viacheslav =
Usov 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"><d=
iv><div class=3D"gmail_quote">On Sun, Jun 10, 2018 at 6:02 PM, Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"s8JIeKzRBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Sunday, June 10, 2018 at 11:36:00 AM UT=
C-4, Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">The associative containers&#39; &quot;node handle&quot; can either=
 be constructed in an empty state or be moved from another node handle. It =
is not possible to create a node handle with arbitrary content &quot;from s=
cratch&quot;, without having it extracted from a container.<div><br></div><=
div>A typical case when the currently impossible creation of node handles w=
ith arbitrary content would be beneficial is a multi-threaded program where=
 access to a container has to be synchronised. In such a case it might be b=
eneficial to construct &quot;the content&quot;, synchronise and and then in=
sert pre-created content.</div><div><br></div><div>Another, related, case o=
ccurs when the value needs some extra massage after construction to make it=
 fully usable, in which case it would be desirable to pre-create it, massag=
e, and then insert.</div><div><br></div><div>All of the above, of course, i=
s achievable with an extra level of indirection, with its corresponding (li=
ttle) loss of efficiency and effort for the programmer.</div></div></blockq=
uote><div><br></div><div>I assume by this you mean creating a container, in=
serting an item into it, manipulating it in whatever way you prefer, and th=
en extracting it into a node_handle, yes?</div></div></blockquote><div><br>=
</div><div>I actually meant that instead of storing &quot;values&quot; in c=
ontainers, you would store pointers.</div><div><br></div><div>What you desc=
ribe eliminates the need of that kind of indirection, but it introduces oth=
er inefficiencies, like the allocation that you mentioned. It may also be m=
essy when said container has an optimised allocator. And, frankly, it is co=
nceptually ugly.</div></div></div></div></blockquote><div><br></div><div>It=
&#39;s no more conceptually ugly than doing the same with `std::list`. I ha=
ve used a temporary list for the purpose of creating nodes, then quickly `s=
plice`d them into the list I actually wanted them stored in.<br></div><div>=
<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"><di=
v><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>With the exception of node containers that do allocation =
when empty, I don&#39;t see why this would cause &quot;loss of efficiency a=
nd effort for the programmer&quot;. You could wrap it in your own function =
easily enough.</div></div></blockquote><div><br></div><div>That&#39;s a pre=
tty significant exception to ignore,</div></div></div></div></blockquote><d=
iv><br></div><div>It&#39;s also something that can be expunged by the stand=
ard forbidding it. This would be a significant improvement, as it would mak=
e move constructors `noexcept` for these types.<br></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>and such a wrapper is just one of those things that m=
akes one sink in boilerplate.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Also there is enough variance in terms of how y=
ou would insert and manipulate such an element that it&#39;s best to leave =
that to the user.<br></div></div></blockquote><div><br></div><div>Node hand=
les are already part of the standard. Once most of the work to standardise =
node handles and especially the concept behind them has been done, the lack=
 of orthogonality is rather odd.=C2=A0</div></div></div></div></blockquote>=
<div><br></div><div>It&#39;s merely a matter of what the feature is meant t=
o accomplish. Node handles are a way to transfer nodes across containers (a=
la `std::list::splice`) and to manipulate the key of a node without having =
to pay removal/insertion/allocation costs.</div><div><br></div><div>Nowhere=
 on this list of use cases is manifesting a node_handle out of thin air.</d=
iv></div>

<p></p>

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

------=_Part_79022_170805366.1528655788782--

------=_Part_79021_1691086490.1528655788782--

.

--000000000000762cc2056e5c3b72
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 10, 2018 at 8:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:


> It's no more conceptually ugly than doing the same with `std::list`. I
> have used a temporary list for the purpose of creating nodes, then quickly
> `splice`d them into the list I actually wanted them stored in.
>

I said "ugly". Saying "no more ugly" is barking up the wrong tree.

It's also something that can be expunged by the standard forbidding it.
> This would be a significant improvement, as it would make move constructors
> `noexcept` for these types.
>

You are free to make that proposal. Some private communications I have had
on this subject suggest (to me) it is going to be a tough call.

Regardless, is is still *ugly* to create a temporary container in order to
pre-create a node for another container. Not only is this ugly, this
eliminates a straight-forward expressly stated optimisation; instead, the
compiler would need to figure our that one container is created for the
sole purpose of pre-creating a node for another container and hopefully
optimise insertion/extraction completely away.


> It's merely a matter of what the feature is meant to accomplish. Node
> handles are a way to transfer nodes across containers (ala
> `std::list::splice`) and to manipulate the key of a node without having to
> pay removal/insertion/allocation costs.
>
> Nowhere on this list of use cases is manifesting a node_handle out of thin
> air.
>

That is saying "a standard interface is not extensible because the
extension is not part of the standard".

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg14zKxv%3DrtvmE4eDe-QV7vPhz6eJZGzSNk4aTFS9tJW9A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 10, 2018 at 8:36 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>It&#39;s no more conceptually ugly than doing the same with `std:=
:list`. I have used a temporary list for the purpose of creating nodes, the=
n quickly `splice`d them into the list I actually wanted them stored in.<br=
></div></div></blockquote><div><br></div><div>I said &quot;ugly&quot;. Sayi=
ng &quot;no more ugly&quot; is barking up the wrong tree.</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s also somet=
hing that can be expunged by the standard forbidding it. This would be a si=
gnificant improvement, as it would make move constructors `noexcept` for th=
ese types.<br></div></div></blockquote><div><br></div><div>You are free to =
make that proposal. Some private communications I have had on this subject =
suggest (to me) it is going to be a tough call.</div><div><br></div><div>Re=
gardless, is is still <i>ugly</i>=C2=A0to create a temporary container in o=
rder to pre-create a node for another container. Not only is this ugly, thi=
s eliminates a straight-forward expressly stated optimisation; instead, the=
 compiler would need to figure our that one container is created for the so=
le purpose of pre-creating a node for another container and hopefully optim=
ise insertion/extraction completely away.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><div>It&#39;s merely a matt=
er of what the feature is meant to accomplish. Node handles are a way to tr=
ansfer nodes across containers (ala `std::list::splice`) and to manipulate =
the key of a node without having to pay removal/insertion/allocation costs.=
<br></div><div><br></div><div>Nowhere on this list of use cases is manifest=
ing a node_handle out of thin air.</div></div></blockquote><div><br></div><=
div>That is saying &quot;a standard interface is not extensible because the=
 extension is not part of the standard&quot;.</div><div><br></div><div>Chee=
rs,</div><div>V.</div></div></div></div>

<p></p>

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

--000000000000762cc2056e5c3b72--

.

--000000000000a540d5056e5c7ba6
Content-Type: text/plain; charset="UTF-8"

It seems to me that in the case of:
1. container is protected by mutex and has much concurrent access and,
2. object is expensive to construct or requires secondary initialisation
and,
3. object is not movable

Then there is a case for (say) std::create_node

But I don't know - I wonder if an object with such constraints cannot be
built less restrictively?

anyway here's my working:

#include <map>
#include <mutex>

struct Expensive
{
    void long_time_init();
};

void current_situation(std::map<int, Expensive>& l, std::mutex& lm)
{
    // generate the object
    auto lock = std::unique_lock(lm);
    auto n = l.extract(l.emplace
    (
        std::piecewise_construct,
        std::make_tuple(1),
        std::make_tuple()
    ).first);
    lock.unlock();

    // perform initialisation without blocking the map
    n.mapped().long_time_init();

    // re-insert
    lock.lock();
    l.insert(std::move(n));
    lock.unlock();
}

// possible extension
namespace std
{
    template<class Container, class...Args>
    auto make_node(Container&& container, Args&&...args) -> typename
std::decay_t<Container>::node_type;
}

void possibly_desirable(std::map<int, Expensive>& l, std::mutex& lm)
{
    // generate the object
    // no lock required as long as the allocator is thread-safe
    // is this a potential source of UB?
    auto n = std::make_node(l, std::piecewise_construct,
std::make_tuple(1), std::make_tuple());

    // perform initialisation without blocking the map
    n.mapped().long_time_init();

    // re-insert
    auto lock = std::unique_lock(lm);
    l.insert(std::move(n));
    lock.unlock();
}


On Mon, 11 Jun 2018 at 13:41, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Sun, Jun 10, 2018 at 8:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
>> It's no more conceptually ugly than doing the same with `std::list`. I
>> have used a temporary list for the purpose of creating nodes, then quickly
>> `splice`d them into the list I actually wanted them stored in.
>>
>
> I said "ugly". Saying "no more ugly" is barking up the wrong tree.
>
> It's also something that can be expunged by the standard forbidding it.
>> This would be a significant improvement, as it would make move constructors
>> `noexcept` for these types.
>>
>
> You are free to make that proposal. Some private communications I have had
> on this subject suggest (to me) it is going to be a tough call.
>
> Regardless, is is still *ugly* to create a temporary container in order
> to pre-create a node for another container. Not only is this ugly, this
> eliminates a straight-forward expressly stated optimisation; instead, the
> compiler would need to figure our that one container is created for the
> sole purpose of pre-creating a node for another container and hopefully
> optimise insertion/extraction completely away.
>
>
>> It's merely a matter of what the feature is meant to accomplish. Node
>> handles are a way to transfer nodes across containers (ala
>> `std::list::splice`) and to manipulate the key of a node without having to
>> pay removal/insertion/allocation costs.
>>
>> Nowhere on this list of use cases is manifesting a node_handle out of
>> thin air.
>>
>
> That is saying "a standard interface is not extensible because the
> extension is not part of the standard".
>
> Cheers,
> V.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg14zKxv%3DrtvmE4eDe-QV7vPhz6eJZGzSNk4aTFS9tJW9A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg14zKxv%3DrtvmE4eDe-QV7vPhz6eJZGzSNk4aTFS9tJW9A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZdNbEFnoTLj-gXa055v3ZiQddRLVCDBLQevCR6sG2dfQ%40mail.gmail.com.

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

<div dir=3D"ltr">It seems to me that in the case of:<div>1. container is pr=
otected by mutex and has much concurrent access and,</div><div>2. object is=
 expensive to construct or requires secondary initialisation and,</div><div=
>3. object is not movable</div><div><br></div><div>Then there is a case for=
 (say) std::create_node</div><div><br></div><div>But I don&#39;t know - I w=
onder if an object with such constraints cannot be built less restrictively=
?</div><div><br></div><div>anyway here&#39;s my working:</div><div><br></di=
v><div><div><font face=3D"monospace, monospace">#include &lt;map&gt;</font>=
</div><div><font face=3D"monospace, monospace">#include &lt;mutex&gt;</font=
></div><div><font face=3D"monospace, monospace"><br></font></div><div><font=
 face=3D"monospace, monospace">struct Expensive</font></div><div><font face=
=3D"monospace, monospace">{</font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 void long_time_init();</font></div><div><font face=3D"m=
onospace, monospace">};</font></div><div><font face=3D"monospace, monospace=
"><br></font></div><div><font face=3D"monospace, monospace">void current_si=
tuation(std::map&lt;int, Expensive&gt;&amp; l, std::mutex&amp; lm)</font></=
div><div><font face=3D"monospace, monospace">{</font></div><div><span style=
=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 // generate the object</=
span><br></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto =
lock =3D std::unique_lock(lm);</font></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 =C2=A0 auto n =3D l.extract(l.emplace</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 (</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::piecewise_constr=
uct,=C2=A0</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 std::make_tuple(1),=C2=A0</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::make_tuple()</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 ).first);</font=
></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 lock.unlock()=
;</font></div><div><font face=3D"monospace, monospace"><br></font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // perform initialisati=
on without blocking the map</font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 n.mapped().long_time_init();</font></div><div><font fac=
e=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 // re-insert</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 lock.lock();</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 =C2=A0 l.insert(std::move(n));</font></div><div>=
<font face=3D"monospace, monospace">=C2=A0 =C2=A0 lock.unlock();</font></di=
v><div><font face=3D"monospace, monospace">}</font></div><div><font face=3D=
"monospace, monospace"><br></font></div><div><font face=3D"monospace, monos=
pace">// possible extension</font></div><div><font face=3D"monospace, monos=
pace">namespace std</font></div><div><font face=3D"monospace, monospace">{<=
/font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template=
&lt;class Container, class...Args&gt;</font></div><div><font face=3D"monosp=
ace, monospace">=C2=A0 =C2=A0 auto make_node(Container&amp;&amp; container,=
 Args&amp;&amp;...args) -&gt; typename std::decay_t&lt;Container&gt;::node_=
type;</font></div><div><font face=3D"monospace, monospace">}</font></div><d=
iv><font face=3D"monospace, monospace"><br></font></div><div><font face=3D"=
monospace, monospace">void possibly_desirable(std::map&lt;int, Expensive&gt=
;&amp; l, std::mutex&amp; lm)</font></div><div><font face=3D"monospace, mon=
ospace">{</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 // generate the object</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 // no lock required as long as the allocator is thread-s=
afe</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // i=
s this a potential source of UB?</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 auto n =3D std::make_node(l, std::piecewise_constr=
uct, std::make_tuple(1), std::make_tuple());</font></div><div><font face=3D=
"monospace, monospace"><br></font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 // perform initialisation without blocking the map</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 n.mapped().l=
ong_time_init();</font></div><div><font face=3D"monospace, monospace"><br><=
/font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // re-in=
sert</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 aut=
o lock =3D std::unique_lock(lm);</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 l.insert(std::move(n));</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0 lock.unlock();</font></div><div><f=
ont face=3D"monospace, monospace">}</font></div></div><div><br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 11 Jun 2018 at 13:4=
1, Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.com">via.usov@gmail=
..com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, Jun 10, 201=
8 at 8:36 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson=
@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It&#3=
9;s no more conceptually ugly than doing the same with `std::list`. I have =
used a temporary list for the purpose of creating nodes, then quickly `spli=
ce`d them into the list I actually wanted them stored in.<br></div></div></=
blockquote><div><br></div><div>I said &quot;ugly&quot;. Saying &quot;no mor=
e ugly&quot; is barking up the wrong tree.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s also something that can b=
e expunged by the standard forbidding it. This would be a significant impro=
vement, as it would make move constructors `noexcept` for these types.<br><=
/div></div></blockquote><div><br></div><div>You are free to make that propo=
sal. Some private communications I have had on this subject suggest (to me)=
 it is going to be a tough call.</div><div><br></div><div>Regardless, is is=
 still <i>ugly</i>=C2=A0to create a temporary container in order to pre-cre=
ate a node for another container. Not only is this ugly, this eliminates a =
straight-forward expressly stated optimisation; instead, the compiler would=
 need to figure our that one container is created for the sole purpose of p=
re-creating a node for another container and hopefully optimise insertion/e=
xtraction completely away.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div></div><div>It&#39;s merely a matter of what the =
feature is meant to accomplish. Node handles are a way to transfer nodes ac=
ross containers (ala `std::list::splice`) and to manipulate the key of a no=
de without having to pay removal/insertion/allocation costs.<br></div><div>=
<br></div><div>Nowhere on this list of use cases is manifesting a node_hand=
le out of thin air.</div></div></blockquote><div><br></div><div>That is say=
ing &quot;a standard interface is not extensible because the extension is n=
ot part of the standard&quot;.</div><div><br></div><div>Cheers,</div><div>V=
..</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg14zKxv%3DrtvmE4eDe-QV7vPhz6eJZ=
GzSNk4aTFS9tJW9A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAA7YVg14zKxv%3DrtvmE4eDe-QV7vPhz6eJZGzSNk4aTFS9tJW9A%40mail.gmail.c=
om</a>.<br>
</blockquote></div>

<p></p>

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

--000000000000a540d5056e5c7ba6--

.

--0000000000006590e1056e5ca3bb
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 11, 2018 at 1:59 PM, Richard Hodges <hodges.r@gmail.com> wrote:

    // no lock required as long as the allocator is thread-safe
>     // is this a potential source of UB?
>     auto n = std::make_node(l, std::piecewise_construct,
> std::make_tuple(1), std::make_tuple());
>

As I mentioned earlier, we will have to use the container's allocator,
explicitly or implicitly, so make_node() needs to be a member, or have a
parameter for that.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQJTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 11, 2018 at 1:59 PM, Richard Hodges <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;=
</span> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 // no lock required as long as the allocator is thread-safe</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // is this a=
 potential source of UB?</font></div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 auto n =3D std::make_node(l, std::piecewise_construct, std=
::make_tuple(1), std::make_tuple());</font></div></div></div></blockquote><=
div><br></div><div>As I mentioned earlier, we will have to use the containe=
r&#39;s allocator, explicitly or implicitly, so make_node() needs to be a m=
ember, or have a parameter for that.</div><div><br></div><div>Cheers,</div>=
<div>V.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQ=
JTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3D=
VzYy0R%3DEsbmnw9C%2Bf_EY%3DQJTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com</a>.<br=
 />

--0000000000006590e1056e5ca3bb--

.

--00000000000056b9ed056e5f6327
Content-Type: text/plain; charset="UTF-8"

On Mon, 11 Jun 2018 at 14:10, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Mon, Jun 11, 2018 at 1:59 PM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>     // no lock required as long as the allocator is thread-safe
>>     // is this a potential source of UB?
>>     auto n = std::make_node(l, std::piecewise_construct,
>> std::make_tuple(1), std::make_tuple());
>>
>
> As I mentioned earlier, we will have to use the container's allocator,
> explicitly or implicitly, so make_node() needs to be a member, or have a
> parameter for that.
>
>
The allocator is available to the implementation of make_node. It can call
l.get_allocator();




> Cheers,
> V.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQJTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQJTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hY3Dg9RZx-2qwwHW14sfH-jccFS%2BKr57zy_sywx6ai0gg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 11 Jun 2018 at 14:10, Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmai=
l.com">via.usov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On Mon, Jun 11, 2018 at 1:59 PM, Richard Hodges <span dir=3D"ltr">&lt;<a =
href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>=
&gt;</span> wrote:</div><div class=3D"gmail_quote"><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 // no lock required as long as the allocator is thread-safe</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // is thi=
s a potential source of UB?</font></div><div><font face=3D"monospace, monos=
pace">=C2=A0 =C2=A0 auto n =3D std::make_node(l, std::piecewise_construct, =
std::make_tuple(1), std::make_tuple());</font></div></div></div></blockquot=
e><div><br></div><div>As I mentioned earlier, we will have to use the conta=
iner&#39;s allocator, explicitly or implicitly, so make_node() needs to be =
a member, or have a parameter for that.</div><div><br></div></div></div></d=
iv></blockquote><div><br></div><div>The allocator is available to the imple=
mentation of <font face=3D"monospace, monospace">make_node</font>. It can c=
all <font face=3D"monospace, monospace">l.get_allocator()</font>;</div><div=
><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
</div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQ=
JTXpBfyuDE7Q4%2B2hBKjg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CAA7YVg3DVzYy0R%3DEsbmnw9C%2Bf_EY%3DQJTXpBfyuDE7Q4%2B2hBKjg%=
40mail.gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

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

--00000000000056b9ed056e5f6327--

.

--0000000000004b8519056e5fc955
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 11, 2018 at 5:27 PM, Richard Hodges <hodges.r@gmail.com> wrote:


> The allocator is available to the implementation of make_node. It can
> call l.get_allocator();
>

Ah, I missed the 'l' argument completely. Then that is more or less
equivalent to a member function.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg017iJQzgLuTsAiFDe6XHSbEpLg%2B6NYOYjT-1_ijD8ecQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 11, 2018 at 5:27 PM, Richard Hodges <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt;=
</span> wrote:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div></div><div>The allocator is availa=
ble to the implementation of <font face=3D"monospace, monospace">make_node<=
/font>. It can call <font face=3D"monospace, monospace">l.get_allocator()</=
font>;</div></div></div></blockquote><div><br></div><div>Ah, I missed the &=
#39;l&#39; argument completely. Then that is more or less equivalent to a m=
ember function.</div><div><br></div><div>Cheers,</div><div>V.</div></div></=
div></div>

<p></p>

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

--0000000000004b8519056e5fc955--

.