------=_Part_2386_2145072166.1531975009376
Content-Type: multipart/alternative;
 boundary="----=_Part_2387_1804153162.1531975009376"

------=_Part_2387_1804153162.1531975009376
Content-Type: text/plain; charset="UTF-8"

I have a draft proposal (here <http://www.plflib.org/list1.htm>) about
deprecating range-based splice in std::list and relaxing time complexity
requirements for singular insertion/erasure from O(1) to O(1) amortised,
in order to allow for implementations using contiguous node allocation such
as plf::list, which have strong performance benefits over std::list.

I have another draft proposal (also here <http://www.plflib.org/list2.htm>)
which is the same thing, but proposes a new container
(std::bidirectional_list, bikeshedding allowed) instead and deprecating
std::list over time.
Please read the benefits via the plf::list page
<http://www.plflib.org/list.htm> or the second proposal, and understand the
problems involved in using an allocator instead (also via plf::list page or
second proposal), before writing a comment.

Which would you prefer and why?

Cheers,
Matt

--
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/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org.

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

<div dir=3D"ltr">I have a draft proposal (<a href=3D"http://www.plflib.org/=
list1.htm">here</a>) about deprecating range-based splice in std::list and =
relaxing time complexity requirements for singular insertion/erasure from O=
(1) to O(1) amortised,<br>in order to allow for implementations using conti=
guous node allocation such as plf::list, which have strong performance bene=
fits over std::list.<br><br>I have another draft proposal (also <a href=3D"=
http://www.plflib.org/list2.htm">here</a>) which is the same thing, but pro=
poses a new container (std::bidirectional_list, bikeshedding allowed) inste=
ad and deprecating std::list over time.<br><div>Please read the benefits vi=
a the <a href=3D"http://www.plflib.org/list.htm">plf::list page</a> or the =
second proposal,=20
and understand the problems involved in using an allocator instead (also
 via plf::list page or second proposal), before writing a comment.</div><di=
v><br></div><div>Which would you prefer and why?</div><br>Cheers,<br>Matt <=
br><br></div>

<p></p>

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

------=_Part_2387_1804153162.1531975009376--

------=_Part_2386_2145072166.1531975009376--

.