Topic: std::segmented_stack proposal
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Sun, 3 Jul 2016 21:27:40 -0700 (PDT)
Raw View
------=_Part_218_187418855.1467606460893
Content-Type: multipart/alternative;
boundary="----=_Part_219_979245690.1467606460893"
------=_Part_219_979245690.1467606460893
Content-Type: text/plain; charset=UTF-8
Hi Guys,
attached is a proposal to introduce the std::segmented_stack container to
the standard library, and subsequently change the default adapted container
of std::stack to std::segmented_stack.
std::segmented_stack is a type of stack that performs better than any
standard library container (across compilers and libraries) in the context
of a stack. Benchmarks are included in the reference section of the
proposal. My implementation, plf::stack, is here:
http://www.plflib.org/stack.htm
which has further details again.
Previously I submitted this proposal to the SG14 working group, but
originally the plan was to replace the std::stack container adaptor with an
actual container. There was some concern that this could cause ABI breakage
in certain cases, so the plan has been scaled back.
Let me know your thoughts,
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/a543212b-89c1-42a7-896c-26cdf96ed394%40isocpp.org.
------=_Part_219_979245690.1467606460893
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Guys,<br>attached is a proposal to introduce the std::s=
egmented_stack container to the standard library, and=20
subsequently change the default adapted container of std::stack to std::seg=
mented_stack.<br><br>std::segmented_stack is a type of stack that performs =
better than any standard library container (across compilers and libraries)=
in the context of a stack. Benchmarks are included in the reference sectio=
n of the proposal. My implementation, plf::stack, is here: <br>http://www.p=
lflib.org/stack.htm<br><br>which has further details again.<br>Previously I=
submitted this proposal to the SG14 working group, but originally the plan=
was to replace the std::stack container adaptor with an actual container. =
There was some concern that this could cause ABI breakage in certain cases,=
so the plan has been scaled back.<br><br>Let me know your thoughts,<br>Che=
ers,<br>Matt<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/a543212b-89c1-42a7-896c-26cdf96ed394%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a543212b-89c1-42a7-896c-26cdf96ed394=
%40isocpp.org</a>.<br />
------=_Part_219_979245690.1467606460893--
------=_Part_218_187418855.1467606460893
Content-Type: text/html; charset=US-ASCII; name=segmented_stack.htm
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=segmented_stack.htm
X-Attachment-Id: 6a19ed0c-5842-492f-9cf2-6ede597092c7
Content-ID: <6a19ed0c-5842-492f-9cf2-6ede597092c7>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Introduction of std::segmented_stack to the standard and=
replacement of std::stack adaptor's default container</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-125=
2">
</HEAD>
<BODY>
Audience: LEWG, SG14<br>
Document number: P0410R0<br>
Date: =092016-06-10<br>
Project: =09Introduction of std::segmented_stack to the standard and replac=
ement of the std::stack adaptor's default container<br>
Reply-to: =09Matthew Bentley <mattreecebentley@gmail.com><br>
<H1>Introduction of std::segmented_stack to the standard and replacement of=
the std::stack adaptor's default container</H1>
<H2>I. Introduction</H2>
<p>This document proposes replacing std::stack's default adapted container =
with a higher-performance implementation of a stack, namely the implementat=
ion used in plf::stack, to achieve greater stack performance and performanc=
e-similarity across compilers and platforms. This implementation can be nam=
ed std::segmented_stack in the standard. Alternatively, if it is deemed wor=
thwhile, the std::stack container adaptor could be replaced by an actual co=
ntainer whose implementation is the same as plf::stack. There has been some=
suggestion that the latter would break ABI compatibility and is therefore =
less desirable.</p>
<H2>II. Motivation and Scope</H2>
<p>Stacks, as one of the simplest of abstract data types, should have adequ=
ate and, ideally, predictable performance across implementations. With the =
current standard, the performance of the default adapted container used by =
the std::stack container adaptor is highly variable, and will perform poorl=
y where the adapted container has low performance (eg. MSVC 2013 uses a low=
-performance std::deque implementation by default). This results in an unre=
liable solution across compilers when performance is a consideration.</p>
<p>plf::stack is a different way of implementing a stack which has better p=
erformance characteristics than current standard library container implemen=
tations in a stack context, including std::vector and std::deque, and acros=
s compilers (tested under GCC 4.3-5.1 and MSVC 2010-2013). In addition it d=
oes not invalidate references to pushed elements (as obtained by the top() =
function) upon subsequent pushes, unlike std::vector, making it more suitab=
le for some use-cases. It is my viewpoint that this should be introduced to=
the standard as std::segmented_stack and that the container should become =
the default adapted container for std::stack.</p>
<p>A full overview of benefits, including graphs of comparative performance=
versus std::stack and std::vector under GCC and MSVC 2013 can be found at =
<a href=3D"http://www.plflib.org/stack.htm">this page</a> or below in the r=
eferences.</p>
<H2>III. Impact On the Standard</H2>
<p>No changes are necessary to the standard's interface for std::stack exce=
pt to change the default adapted container to std::segmented_stack. The und=
erlying architecture would take the form of a chained-group memory allocati=
on structure as described on <a href=3D"http://www.plflib.org/chained_group=
_allocation_pattern.htm">this page</a>.</p>
<h2>IV. Design Decisions</h2>
<p>The proposed internal structure as indicated above has a higher performa=
nce in a stack context due to the reduced complexity compared to a std::deq=
ue implementation (typically a vector of memory blocks as opposed to a link=
ed chain), and the removal of the necessity for reallocation of data as is =
required in a std::vector once insertion breaches current capacity. Because=
a stack does not require the ordered insertion, ordered erasure and other =
operations of a deque or vector, it also does not require the complexity an=
d overhead of these.</p>
<h2>V. Technical Specifications</h2>
<p>The class is made up of a linked chain of groups, structs containing a m=
emory block and metadata, with a growth pattern to be determined by the imp=
lementor (however, 2x is recommended). The metadata within the groups - 'el=
ements' (pointer to the memory block), previous_group (pointer or NULL), ne=
xt_group (pointer or NULL), and 'end' (pointer to last element in memory bl=
ock) - aid respectively in the identification of when when a pop reaches th=
e start of the memory block, iterating backwards to the previous group, ite=
rating forwards to the next group, and identifying when a push reaches the =
capacity of any given memory block.</p>
<p>When capacity of the current memory block is reached, a new group is cre=
ated and linked to via the next_group pointer. The plf::stack implementatio=
n does not release memory blocks to the OS when the beginning of a group is=
reached via pop() and navigation to a previous group completed (this is de=
ferred to the 'shrink_to_fit' function), but the code to do so can be put i=
n the pop() function, with a minor performance cost.</p>
<p>A download of the full plf::stack implementation can be found here <a hr=
ef=3D"https://github.com/WG21-SG14/SG14/blob/master/SG14/plf_stack.h">https=
://github.com/WG21-SG14/SG14/blob/master/SG14/plf_stack.h</a></p>
<h2>VI. Acknowledgements</h2>
<p>Thanks to Jonathan Blow for advice, Mike Acton for influence.</p>
<h2>VII. References</h2>
<h3>Benchmarks</h3>
<p style=3D"font-size: 75%"><i>Last updated 16-04-2016 v3.04</i></p>
<p>The test setup is an E8500 on an Intel motherboard, 8GB ram, running GCC=
5.1 x64 as compiler. Build settings are "-O2;-march=3Dnative;-std=3Dc++11;=
-fomit-frame-pointer". Results for Microsoft Visual Studio 2013 x64 follow =
separately, with "/O2 /Oi /Ot /Oy /GL" release settings. Tests are based on=
a sliding scale of number of runs vs number of elements, so a test with on=
ly 10 elements in a container may average 100000 runs, whereas a test with =
100000 elements may only average 10 runs. This tends to give adequate resul=
ts without overly lengthening test times. I have not included results invol=
ving 'reserve()' functions as the differences to overall insertion performa=
nce were not adequate. Reserve testing does not make significant sense for =
an extensible container, as the entire benefit of such is that we can adapt=
to situations where we do not know the total number of elements in advance=
..</p>
<p>Tests are carried out on the following types: (a) a 8-bit type ie. char,=
(b) a 32-bit type ie. int, (c) a 64-bit type ie. double, (d) a small struc=
t containing two pointers and four scalar types, and (e) a large struct con=
taining 2 pointers, 4 scalar types, a large array of ints and a small array=
of chars. In order to better facilitate accurate time-keeping for short te=
sts, both container construction and destruction times are included in the =
tests. The sequence is as follows: construction, push N elements, read (bac=
k) + pop all elements, destruction. Because unlike a regular container, a s=
tack must be pushed for every pop, and popped for every read, it makes litt=
le sense to analyse these aspects of use separately, as what is most import=
ant is the overall time taken. For that reason (and for the sake of simplic=
ity) only total time benchmarks are presented below, however the separate t=
imings are <a href=3D"http://www.plflib.org/stack_all_gcc_results.htm">here=
for GCC</a> and <a href=3D"http://www.plflib.org/stack_all_msvc_results.ht=
m">here for MSVC</a>, for anyone interested.</p>
<h4>Total Time - GCC 5.1 x64</h4>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/char_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/char_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/int_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/int_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/double_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/double_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/small_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/small_struct_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/large_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/large_struct_total_time_log.png"><br>
<h4>Total Time - MSVC 2013 x64</h4>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/char_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/char_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/int_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/int_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/double_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/double_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/small_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/small_struct_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/large_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/large_struct_total_time_log.png"><br>
</BODY></HTML>
------=_Part_218_187418855.1467606460893--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 4 Jul 2016 07:18:27 +0200
Raw View
2016-07-04 6:27 GMT+02:00 Matthew Bentley <mattreecebentley@gmail.com>:
> Hi Guys,
> attached is a proposal to introduce the std::segmented_stack container to
> the standard library, and subsequently change the default adapted container
> of std::stack to std::segmented_stack.
>
> std::segmented_stack is a type of stack that performs better than any
> standard library container (across compilers and libraries) in the context
> of a stack. Benchmarks are included in the reference section of the
> proposal. My implementation, plf::stack, is here:
> http://www.plflib.org/stack.htm
>
> which has further details again.
> Previously I submitted this proposal to the SG14 working group, but
> originally the plan was to replace the std::stack container adaptor with an
> actual container. There was some concern that this could cause ABI breakage
> in certain cases, so the plan has been scaled back.
>
> Let me know your thoughts,
If you present your proposal to the public expecting potential
improvements due to the feedback, please ensure that the document
number in the presented proposal starts with D instead of P (meaning:
draft version), therefore use D0410R0 instead of P0410R0. This ensures
that people don't get confused what the actual version is. As long as
it is a draft version, everyone expects that it contents might still
change.
Thanks,
- Daniel
--
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/CAGNvRgB5W18RnW_PyzZeRUXXkwiGUNSYpqifUi258NLc07Bm0g%40mail.gmail.com.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jul 2016 08:15:12 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Unfortunately, changing the default container in std::stack als=
o breaks ABI. </div><div style=3D"width: 100%; font-size: initial; fon=
t-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, =
125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div=
><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slat=
e Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initia=
l; background-color: rgb(255, 255, 255);">Anyone who does </div><div s=
tyle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro',=
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; back=
ground-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; fon=
t-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;=
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 2=
55, 255);"> extern int foo(std::stack<Foo> =E2=80=8E&=
s);</div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">Expects that type not to change. </div><div=
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro=
', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; ba=
ckground-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br>=
</div> =
=
<div style=3D"font-size:=
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color:=
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255=
);">Sent from my BlackBerry portable Babbage =
Device</div> =
=
<table width=3D"100%" style=3D"back=
ground-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=
=3D"font-size: initial; text-align: initial; background-color: rgb(255, 255=
, 255);"> <div style=3D"border-style: solid none =
none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding:=
3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size:=
10pt;"> <div><b>From: </b>Matthew Bentley</div><div><b>Sent: </b>Monday, =
July 4, 2016 12:27 AM</div><div><b>To: </b>ISO C++ Standard - Future Propos=
als</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>Subjec=
t: </b>[std-proposals] std::segmented_stack proposal</div></div></td></tr><=
/tbody></table><div style=3D"border-style: solid none none; border-top-colo=
r: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-alig=
n: initial; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_or=
iginalContent" style=3D""><div dir=3D"ltr">Hi Guys,<br>attached is a propos=
al to introduce the std::segmented_stack container to the standard library,=
and=20
subsequently change the default adapted container of std::stack to std::seg=
mented_stack.<br><br>std::segmented_stack is a type of stack that performs =
better than any standard library container (across compilers and libraries)=
in the context of a stack. Benchmarks are included in the reference sectio=
n of the proposal. My implementation, plf::stack, is here: <br>http://www.p=
lflib.org/stack.htm<br><br>which has further details again.<br>Previously I=
submitted this proposal to the SG14 working group, but originally the plan=
was to replace the std::stack container adaptor with an actual container. =
There was some concern that this could cause ABI breakage in certain cases,=
so the plan has been scaled back.<br><br>Let me know your thoughts,<br>Che=
ers,<br>Matt<br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/a543212b-89c1-42a7-896c-26cdf96ed394%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a543212b-89c1-42a7-896c-26cdf96e=
d394%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20160704121512.4898896.86493.13256%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160704121512.4898896.86493.13256%40gm=
ail.com</a>.<br />
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 4 Jul 2016 06:53:28 -0700 (PDT)
Raw View
------=_Part_4278_1706397889.1467640408614
Content-Type: multipart/alternative;
boundary="----=_Part_4279_1477002113.1467640408615"
------=_Part_4279_1477002113.1467640408615
Content-Type: text/plain; charset=UTF-8
On Monday, July 4, 2016 at 12:27:40 AM UTC-4, Matthew Bentley wrote:
>
> Hi Guys,
> attached is a proposal to introduce the std::segmented_stack container to
> the standard library, and subsequently change the default adapted container
> of std::stack to std::segmented_stack.
>
So... where is it?
I see a proposal... kinda. I see a document that contains a lot of
performance charts and a general idea of what you want to standardize. But
I see nothing *specific*; it's just, "I made a better performing stack
implementation; here it is, so let's standardize it!"
We don't standardize *implementations*; we standardize *behavior*. And
you've said almost nothing about the behavior of your stack type here. What
behavior you do talk about isn't generally the kind of behavior that gets
standardized.
You say it has O(1) inserts and removals at the rear. OK, but what is the
performance of inserts/removals at the front? Does it even allow those?
What about inserts/removals in other locations? What kind of iterators does
it have?
You shove all of these *very important* questions off into some
supplementary document. And looking at that, it seems your "container" is
not actually a *container*, by the standard library meaning of that term.
It has no iterator ranges, no generalized insertion/removal, or many other
features expected of a real container.
There's a reason why `stack` is not a container but a container *adapter*.
It provides a simple, uniform stack-like interface to any container for
which a stack-like interface makes sense. It would be much more reasonable
for us to standardize a container who's interface is optimized for
insertions/removals from the end, then allow people to use that with
`stack`. We could even provide a convenient typedef:
template<class T, class Allocator = std::allocator<T>>
using segmented_stack = stack<T, chained_block_vector<T, Allocator>>;
Behaviorally, `chained_block_vector` is almost identical to `deque`, save
that it doesn't support head insertion/removal. Its iterators would be
random-access, but not contiguous. It would have O(1) insertion/removal at
the back. Insertion/removal anywhere but the tail would invalidate
iterators and references (though only for subsequent entries). And so forth.
By doing it this way, `chained_block_vector` gets to be a general
*container*, and therefore is not restricted to a stack-like interface. For
example, in a stack you only push or pop one element at a time. Whereas in
a generalized container, inserting or removing a range of elements from the
end is a perfectly legitimate activity. Similarly, if you want to wipe out
everything after the 20th element, and then add 5 more, why should that be
a difficult operation?
What you have is, from a container and user perspective, is a specialized
`vector`. There's no need to limit the behavior of a segmented vector to
that of a stack.
That's what `std::stack` is for. That's *why* its an adapter and not a
container.
Now, it could have specialized interfaces, in a similar manor to how
`vector` has `capacity` and `reserve`. I think such an interface should
focus on controlling the most important factor: how many items can be
inserted before a new block is created. That is after all the performance
problem: the allocation of new memory. Common `deque` implementations
allocate linearly with `n`. `vector` allocates larger and larger amounts of
memory, but it also copies old elements.
I don't much care for your interface of min/max block sizes. I think that's
giving unnecessary and unimportant control over the type's behavior. I
think there should be two factors the user can set:
1: The minimum capacity, as with `vector` (though unlike C++17 `vector`,
this will not be binding). The goal here is so that the user can specify
the minimum number of elements he can insert before new allocations occur.
2: The size of the *basic* allocation block. That is, the first block size.
Every other block size will be some multiple of this number. Changing this
will naturally provoke *full* reallocation.
If there truly does *need* to be some maximum block size setting, then I
say it should be a multiple of the basic block size. And it should also be
non-binding. Or more to the point, if the implementation already allocated
a block bigger than that, the implementation shouldn't have to reallocate
them to fit your new maximum multiplier.
--
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/c0e52ac6-125e-42ae-8141-7c975dc505a2%40isocpp.org.
------=_Part_4279_1477002113.1467640408615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 4, 2016 at 12:27:40 AM UTC-4, Matthew Bent=
ley 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">Hi =
Guys,<br>attached is a proposal to introduce the std::segmented_stack conta=
iner to the standard library, and=20
subsequently change the default adapted container of std::stack to std::seg=
mented_stack.<br></div></blockquote><div><br>So... where is it?<br><br>I se=
e a proposal... kinda. I see a document that contains a lot of performance =
charts and a general idea of what you want to standardize. But I see nothin=
g <i>specific</i>; it's just, "I made a better performing stack im=
plementation; here it is, so let's standardize it!"<br><br>We don&=
#39;t standardize <i>implementations</i>; we standardize <i>behavior</i>. A=
nd you've said almost nothing about the behavior of your stack type her=
e. What behavior you do talk about isn't generally the kind of behavior=
that gets standardized.<br><br>You say it has O(1) inserts and removals at=
the rear. OK, but what is the performance of inserts/removals at the front=
? Does it even allow those? What about inserts/removals in other locations?=
What kind of iterators does it have?<br><br>You shove all of these <i>very=
important</i> questions off into some supplementary document. And looking =
at that, it seems your "container" is not actually a <i>container=
</i>, by the standard library meaning of that term. It has no iterator rang=
es, no generalized insertion/removal, or many other features expected of a =
real container.<br><br>There's a reason why `stack` is not a container =
but a container <i>adapter</i>. It provides a simple, uniform stack-like in=
terface to any container for which a stack-like interface makes sense. It w=
ould be much more reasonable for us to standardize a container who's in=
terface is optimized for insertions/removals from the end, then allow peopl=
e to use that with `stack`. We could even provide a convenient typedef:<br>=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Allocator</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">allocator</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">>></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> segmented_stack </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> stack</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> chained_block_vector</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Allocator</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">>>;</span></div=
></code></div><br>Behaviorally, `chained_block_vector` is almost identical =
to `deque`, save that it doesn't support head insertion/removal. Its it=
erators would be random-access, but not contiguous. It would have O(1) inse=
rtion/removal at the back. Insertion/removal anywhere but the tail would in=
validate iterators and references (though only for subsequent entries). And=
so forth.<br><br>By doing it this way, `chained_block_vector` gets to be a=
general <i>container</i>, and therefore is not restricted to a stack-like =
interface. For example, in a stack you only push or pop one element at a ti=
me. Whereas in a generalized container, inserting or removing a range of el=
ements from the end is a perfectly legitimate activity. Similarly, if you w=
ant to wipe out everything after the 20th element, and then add 5 more, why=
should that be a difficult operation?<br><br>What you have is, from a cont=
ainer and user perspective, is a specialized `vector`. There's no need =
to limit the behavior of a segmented vector to that of a stack.<br><br>That=
's what `std::stack` is for. That's <i>why</i> its an adapter and n=
ot a container.<br><br>Now, it could have specialized interfaces, in a simi=
lar manor to how `vector` has `capacity` and `reserve`. I think such an int=
erface should focus on controlling the most important factor: how many item=
s can be inserted before a new block is created. That is after all the perf=
ormance problem: the allocation of new memory. Common `deque` implementatio=
ns allocate linearly with `n`. `vector` allocates larger and larger amounts=
of memory, but it also copies old elements.<br><br>I don't much care f=
or your interface of min/max block sizes. I think that's giving unneces=
sary and unimportant control over the type's behavior. I think there sh=
ould be two factors the user can set:<br><br>1: The minimum capacity, as wi=
th `vector` (though unlike C++17 `vector`, this will not be binding). The g=
oal here is so that the user can specify the minimum number of elements he =
can insert before new allocations occur.<br>2: The size of the <i>basic</i>=
allocation block. That is, the first block size. Every other block size wi=
ll be some multiple of this number. Changing this will naturally provoke <i=
>full</i> reallocation.<br><br>If there truly does <i>need</i> to be some m=
aximum block size setting, then I say it should be a multiple of the basic =
block size. And it should also be non-binding. Or more to the point, if the=
implementation already allocated a block bigger than that, the implementat=
ion shouldn't have to reallocate them to fit your new maximum multiplie=
r.</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/c0e52ac6-125e-42ae-8141-7c975dc505a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0e52ac6-125e-42ae-8141-7c975dc505a2=
%40isocpp.org</a>.<br />
------=_Part_4279_1477002113.1467640408615--
------=_Part_4278_1706397889.1467640408614--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 4 Jul 2016 12:21:08 -0700 (PDT)
Raw View
------=_Part_230_1019618692.1467660068281
Content-Type: multipart/alternative;
boundary="----=_Part_231_12134432.1467660068282"
------=_Part_231_12134432.1467660068282
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC+=
8=E4=B8=8B=E5=8D=889:53:28=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, July 4, 2016 at 12:27:40 AM UTC-4, Matthew Bentley wrote:
>>
>> Hi Guys,
>> attached is a proposal to introduce the std::segmented_stack container t=
o=20
>> the standard library, and subsequently change the default adapted contai=
ner=20
>> of std::stack to std::segmented_stack.
>>
>
> So... where is it?
>
> I see a proposal... kinda. I see a document that contains a lot of=20
> performance charts and a general idea of what you want to standardize. Bu=
t=20
> I see nothing *specific*; it's just, "I made a better performing stack=20
> implementation; here it is, so let's standardize it!"
>
> We don't standardize *implementations*; we standardize *behavior*. And=20
> you've said almost nothing about the behavior of your stack type here. Wh=
at=20
> behavior you do talk about isn't generally the kind of behavior that gets=
=20
> standardized.
>
> No, we even don't necessarily standardize the behavior. Description on=20
behavior may be one part of a clear specification, but not always=20
necessary. We standardize the language by demanding *requirements *(providi=
ng=20
to users as *guarantees*) on conforming implementations. (Note the standard=
=20
itself is a guide to write the specification.) For a typical component of=
=20
the standard library, they normally consist of a summary (stated in=20
[structure.summary], at least, a synopsis) and detailed specifications=20
(stated in [structure.specifications]) of each portable *interface*, and=20
perhaps more clauses about overall requirements expressed by well-formed=20
expressions with semantics constraints (extending [structure.requirements],=
=20
e.g. tables of well-formed expressions, or concepts in future) and specific=
=20
terminology (if necessary).
=20
> You say it has O(1) inserts and removals at the rear. OK, but what is the=
=20
> performance of inserts/removals at the front? Does it even allow those?=
=20
> What about inserts/removals in other locations? What kind of iterators do=
es=20
> it have?
>
> You shove all of these *very important* questions off into some=20
> supplementary document. And looking at that, it seems your "container" is=
=20
> not actually a *container*, by the standard library meaning of that term.=
=20
> It has no iterator ranges, no generalized insertion/removal, or many othe=
r=20
> features expected of a real container.
>
> There's a reason why `stack` is not a container but a container *adapter*=
..
>
In the standard it is spelled as "adaptor"...
=20
> It provides a simple, uniform stack-like interface to any container for=
=20
> which a stack-like interface makes sense. It would be much more reasonabl=
e=20
> for us to standardize a container who's interface is optimized for=20
> insertions/removals from the end, then allow people to use that with=20
> `stack`. We could even provide a convenient typedef:
>
> template<class T, class Allocator =3D std::allocator<T>>
> using segmented_stack =3D stack<T, chained_block_vector<T, Allocator>>;
>
> Behaviorally, `chained_block_vector` is almost identical to `deque`, save=
=20
> that it doesn't support head insertion/removal. Its iterators would be=20
> random-access, but not contiguous. It would have O(1) insertion/removal a=
t=20
> the back. Insertion/removal anywhere but the tail would invalidate=20
> iterators and references (though only for subsequent entries). And so for=
th.
>
> By doing it this way, `chained_block_vector` gets to be a general=20
> *container*, and therefore is not restricted to a stack-like interface.=
=20
> For example, in a stack you only push or pop one element at a time. Where=
as=20
> in a generalized container, inserting or removing a range of elements fro=
m=20
> the end is a perfectly legitimate activity. Similarly, if you want to wip=
e=20
> out everything after the 20th element, and then add 5 more, why should th=
at=20
> be a difficult operation?
>
> What you have is, from a container and user perspective, is a specialized=
=20
> `vector`. There's no need to limit the behavior of a segmented vector to=
=20
> that of a stack.
>
> That's what `std::stack` is for. That's *why* its an adapter and not a=20
> container.
>
> Now, it could have specialized interfaces, in a similar manor to how=20
> `vector` has `capacity` and `reserve`. I think such an interface should=
=20
> focus on controlling the most important factor: how many items can be=20
> inserted before a new block is created. That is after all the performance=
=20
> problem: the allocation of new memory. Common `deque` implementations=20
> allocate linearly with `n`. `vector` allocates larger and larger amounts =
of=20
> memory, but it also copies old elements.
>
> I don't much care for your interface of min/max block sizes. I think=20
> that's giving unnecessary and unimportant control over the type's behavio=
r.=20
> I think there should be two factors the user can set:
>
> 1: The minimum capacity, as with `vector` (though unlike C++17 `vector`,=
=20
> this will not be binding). The goal here is so that the user can specify=
=20
> the minimum number of elements he can insert before new allocations occur=
..
> 2: The size of the *basic* allocation block. That is, the first block=20
> size. Every other block size will be some multiple of this number. Changi=
ng=20
> this will naturally provoke *full* reallocation.
>
> If there truly does *need* to be some maximum block size setting, then I=
=20
> say it should be a multiple of the basic block size. And it should also b=
e=20
> non-binding. Or more to the point, if the implementation already allocate=
d=20
> a block bigger than that, the implementation shouldn't have to reallocate=
=20
> them to fit your new maximum multiplier.
>
--=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/5e7212a6-e9ab-4a8a-ac52-e580167b1047%40isocpp.or=
g.
------=_Part_231_12134432.1467660068282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=889:53:28=EF=BC=8CNicol Bolas=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 d=
ir=3D"ltr">On Monday, July 4, 2016 at 12:27:40 AM UTC-4, Matthew Bentley wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Guys,<br>at=
tached is a proposal to introduce the std::segmented_stack container to the=
standard library, and=20
subsequently change the default adapted container of std::stack to std::seg=
mented_stack.<br></div></blockquote><div><br>So... where is it?<br><br>I se=
e a proposal... kinda. I see a document that contains a lot of performance =
charts and a general idea of what you want to standardize. But I see nothin=
g <i>specific</i>; it's just, "I made a better performing stack im=
plementation; here it is, so let's standardize it!"<br><br>We don&=
#39;t standardize <i>implementations</i>; we standardize <i>behavior</i>. A=
nd you've said almost nothing about the behavior of your stack type her=
e. What behavior you do talk about isn't generally the kind of behavior=
that gets standardized.<br><br></div></div></blockquote><div>No, we even d=
on't necessarily standardize the behavior. Description on behavior may =
be one part of a clear specification, but not always necessary. We standard=
ize the language by demanding <i>requirements </i>(providing to users as <i=
>guarantees</i>) on conforming implementations. (Note the standard itself i=
s a guide to write the specification.) For a typical component of the stand=
ard library, they normally consist of a summary (stated in [structure.summa=
ry], at least, a synopsis) and detailed specifications (stated in [structur=
e.specifications]) of each portable <i>interface</i>, and perhaps more clau=
ses about overall requirements expressed by well-formed expressions with se=
mantics constraints (extending [structure.requirements], e.g. tables of wel=
l-formed expressions, or concepts in future) and specific terminology (if n=
ecessary).<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>You say it has O(1) inserts and removals at the rear.=
OK, but what is the performance of inserts/removals at the front? Does it =
even allow those? What about inserts/removals in other locations? What kind=
of iterators does it have?<br><br>You shove all of these <i>very important=
</i> questions off into some supplementary document. And looking at that, i=
t seems your "container" is not actually a <i>container</i>, by t=
he standard library meaning of that term. It has no iterator ranges, no gen=
eralized insertion/removal, or many other features expected of a real conta=
iner.<br><br>There's a reason why `stack` is not a container but a cont=
ainer <i>adapter</i>.</div></div></blockquote><div>In the standard it is sp=
elled as "adaptor"...<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>It provides a simple, uniform stack-=
like interface to any container for which a stack-like interface makes sens=
e. It would be much more reasonable for us to standardize a container who&#=
39;s interface is optimized for insertions/removals from the end, then allo=
w people to use that with `stack`. We could even provide a convenient typed=
ef:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de><div><span style=3D"color:#008">template</span><span style=3D"color:#660=
"><</span><span style=3D"color:#008">class</span><span style=3D"color:#0=
00"> T</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
</span><span style=3D"color:#008">class</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">Allocator</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> =
std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">al=
locator</span><span style=3D"color:#660"><</span><span style=3D"color:#0=
00">T</span><span style=3D"color:#660">>></span><span style=3D"color:=
#000"><br></span><span style=3D"color:#008">using</span><span style=3D"colo=
r:#000"> segmented_stack </span><span style=3D"color:#660">=3D</span><span =
style=3D"color:#000"> stack</span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#000">T</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> chained_block_vector</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Allocato=
r</span><span style=3D"color:#660">>>;</span></div></code></div><br>B=
ehaviorally, `chained_block_vector` is almost identical to `deque`, save th=
at it doesn't support head insertion/removal. Its iterators would be ra=
ndom-access, but not contiguous. It would have O(1) insertion/removal at th=
e back. Insertion/removal anywhere but the tail would invalidate iterators =
and references (though only for subsequent entries). And so forth.<br><br>B=
y doing it this way, `chained_block_vector` gets to be a general <i>contain=
er</i>, and therefore is not restricted to a stack-like interface. For exam=
ple, in a stack you only push or pop one element at a time. Whereas in a ge=
neralized container, inserting or removing a range of elements from the end=
is a perfectly legitimate activity. Similarly, if you want to wipe out eve=
rything after the 20th element, and then add 5 more, why should that be a d=
ifficult operation?<br><br>What you have is, from a container and user pers=
pective, is a specialized `vector`. There's no need to limit the behavi=
or of a segmented vector to that of a stack.<br><br>That's what `std::s=
tack` is for. That's <i>why</i> its an adapter and not a container.<br>=
<br>Now, it could have specialized interfaces, in a similar manor to how `v=
ector` has `capacity` and `reserve`. I think such an interface should focus=
on controlling the most important factor: how many items can be inserted b=
efore a new block is created. That is after all the performance problem: th=
e allocation of new memory. Common `deque` implementations allocate linearl=
y with `n`. `vector` allocates larger and larger amounts of memory, but it =
also copies old elements.<br><br>I don't much care for your interface o=
f min/max block sizes. I think that's giving unnecessary and unimportan=
t control over the type's behavior. I think there should be two factors=
the user can set:<br><br>1: The minimum capacity, as with `vector` (though=
unlike C++17 `vector`, this will not be binding). The goal here is so that=
the user can specify the minimum number of elements he can insert before n=
ew allocations occur.<br>2: The size of the <i>basic</i> allocation block. =
That is, the first block size. Every other block size will be some multiple=
of this number. Changing this will naturally provoke <i>full</i> reallocat=
ion.<br><br>If there truly does <i>need</i> to be some maximum block size s=
etting, then I say it should be a multiple of the basic block size. And it =
should also be non-binding. Or more to the point, if the implementation alr=
eady allocated a block bigger than that, the implementation shouldn't h=
ave to reallocate them to fit your new maximum multiplier.</div></div></blo=
ckquote></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/5e7212a6-e9ab-4a8a-ac52-e580167b1047%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e7212a6-e9ab-4a8a-ac52-e580167b1047=
%40isocpp.org</a>.<br />
------=_Part_231_12134432.1467660068282--
------=_Part_230_1019618692.1467660068281--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Mon, 4 Jul 2016 16:16:56 -0700 (PDT)
Raw View
------=_Part_1571_948204667.1467674217071
Content-Type: multipart/alternative;
boundary="----=_Part_1572_1722709528.1467674217072"
------=_Part_1572_1722709528.1467674217072
Content-Type: text/plain; charset=UTF-8
>
> > Let me know your thoughts,
>
> If you present your proposal to the public expecting potential
> improvements due to the feedback, please ensure that the document
> number in the presented proposal starts with D instead of P (meaning:
> draft version), therefore use D0410R0 instead of P0410R0. This ensures
> that people don't get confused what the actual version is. As long as
> it is a draft version, everyone expects that it contents might still
> change.
>
> Thanks,
>
> - Daniel
>
Thanks Daniel, you're correct, I'd forgotten about that.
Corrected document attached.
--
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/fcce000f-5dd7-4e8b-81d0-57398cb80063%40isocpp.org.
------=_Part_1572_1722709528.1467674217072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">> Let me know your thou=
ghts,
<br>
<br>If you present your proposal to the public expecting potential
<br>improvements due to the feedback, please ensure that the document
<br>number in the presented proposal starts with D instead of P (meaning:
<br>draft version), therefore use D0410R0 instead of P0410R0. This ensures
<br>that people don't get confused what the actual version is. As long =
as
<br>it is a draft version, everyone expects that it contents might still
<br>change.
<br>
<br>Thanks,
<br>
<br>- Daniel
<br></blockquote><div><br>Thanks Daniel, you're correct, I'd forgot=
ten about that.<br>Corrected document attached.<br><br>=C2=A0<br></div></di=
v>
<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/fcce000f-5dd7-4e8b-81d0-57398cb80063%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcce000f-5dd7-4e8b-81d0-57398cb80063=
%40isocpp.org</a>.<br />
------=_Part_1572_1722709528.1467674217072--
------=_Part_1571_948204667.1467674217071
Content-Type: text/html; charset=US-ASCII; name=segmented_stack.htm
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=segmented_stack.htm
X-Attachment-Id: c3c721e4-4fef-40bc-8f90-1f16676ff994
Content-ID: <c3c721e4-4fef-40bc-8f90-1f16676ff994>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Introduction of std::segmented_stack to the standard and=
replacement of std::stack adaptor's default container</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-125=
2">
</HEAD>
<BODY>
Audience: LEWG, SG14<br>
Document number: D0410R0<br>
Date: =092016-06-10<br>
Project: =09Introduction of std::segmented_stack to the standard and replac=
ement of the std::stack adaptor's default container<br>
Reply-to: =09Matthew Bentley <mattreecebentley@gmail.com><br>
<H1>Introduction of std::segmented_stack to the standard and replacement of=
the std::stack adaptor's default container</H1>
<H2>I. Introduction</H2>
<p>This document proposes replacing std::stack's default adapted container =
with a higher-performance implementation of a stack, namely the implementat=
ion used in plf::stack, to achieve greater stack performance and performanc=
e-similarity across compilers and platforms. This implementation can be nam=
ed std::segmented_stack in the standard. Alternatively, if it is deemed wor=
thwhile, the std::stack container adaptor could be replaced by an actual co=
ntainer whose implementation is the same as plf::stack. There has been some=
suggestion that the latter would break ABI compatibility and is therefore =
less desirable.</p>
<H2>II. Motivation and Scope</H2>
<p>Stacks, as one of the simplest of abstract data types, should have adequ=
ate and, ideally, predictable performance across implementations. With the =
current standard, the performance of the default adapted container used by =
the std::stack container adaptor is highly variable, and will perform poorl=
y where the adapted container has low performance (eg. MSVC 2013 uses a low=
-performance std::deque implementation by default). This results in an unre=
liable solution across compilers when performance is a consideration.</p>
<p>plf::stack is a different way of implementing a stack which has better p=
erformance characteristics than current standard library container implemen=
tations in a stack context, including std::vector and std::deque, and acros=
s compilers (tested under GCC 4.3-5.1 and MSVC 2010-2013). In addition it d=
oes not invalidate references to pushed elements (as obtained by the top() =
function) upon subsequent pushes, unlike std::vector, making it more suitab=
le for some use-cases. It is my viewpoint that this should be introduced to=
the standard as std::segmented_stack and that the container should become =
the default adapted container for std::stack.</p>
<p>A full overview of benefits, including graphs of comparative performance=
versus std::stack and std::vector under GCC and MSVC 2013 can be found at =
<a href=3D"http://www.plflib.org/stack.htm">this page</a> or below in the r=
eferences.</p>
<H2>III. Impact On the Standard</H2>
<p>No changes are necessary to the standard's interface for std::stack exce=
pt to change the default adapted container to std::segmented_stack. The und=
erlying architecture would take the form of a chained-group memory allocati=
on structure as described on <a href=3D"http://www.plflib.org/chained_group=
_allocation_pattern.htm">this page</a>.</p>
<h2>IV. Design Decisions</h2>
<p>The proposed internal structure as indicated above has a higher performa=
nce in a stack context due to the reduced complexity compared to a std::deq=
ue implementation (typically a vector of memory blocks as opposed to a link=
ed chain), and the removal of the necessity for reallocation of data as is =
required in a std::vector once insertion breaches current capacity. Because=
a stack does not require the ordered insertion, ordered erasure and other =
operations of a deque or vector, it also does not require the complexity an=
d overhead of these.</p>
<h2>V. Technical Specifications</h2>
<p>The class is made up of a linked chain of groups, structs containing a m=
emory block and metadata, with a growth pattern to be determined by the imp=
lementor (however, 2x is recommended). The metadata within the groups - 'el=
ements' (pointer to the memory block), previous_group (pointer or NULL), ne=
xt_group (pointer or NULL), and 'end' (pointer to last element in memory bl=
ock) - aid respectively in the identification of when when a pop reaches th=
e start of the memory block, iterating backwards to the previous group, ite=
rating forwards to the next group, and identifying when a push reaches the =
capacity of any given memory block.</p>
<p>When capacity of the current memory block is reached, a new group is cre=
ated and linked to via the next_group pointer. The plf::stack implementatio=
n does not release memory blocks to the OS when the beginning of a group is=
reached via pop() and navigation to a previous group completed (this is de=
ferred to the 'shrink_to_fit' function), but the code to do so can be put i=
n the pop() function, with a minor performance cost.</p>
<p>A download of the full plf::stack implementation can be found here <a hr=
ef=3D"https://github.com/WG21-SG14/SG14/blob/master/SG14/plf_stack.h">https=
://github.com/WG21-SG14/SG14/blob/master/SG14/plf_stack.h</a></p>
<h2>VI. Acknowledgements</h2>
<p>Thanks to Jonathan Blow for advice, Mike Acton for influence.</p>
<h2>VII. References</h2>
<h3>Benchmarks</h3>
<p style=3D"font-size: 75%"><i>Last updated 16-04-2016 v3.04</i></p>
<p>The test setup is an E8500 on an Intel motherboard, 8GB ram, running GCC=
5.1 x64 as compiler. Build settings are "-O2;-march=3Dnative;-std=3Dc++11;=
-fomit-frame-pointer". Results for Microsoft Visual Studio 2013 x64 follow =
separately, with "/O2 /Oi /Ot /Oy /GL" release settings. Tests are based on=
a sliding scale of number of runs vs number of elements, so a test with on=
ly 10 elements in a container may average 100000 runs, whereas a test with =
100000 elements may only average 10 runs. This tends to give adequate resul=
ts without overly lengthening test times. I have not included results invol=
ving 'reserve()' functions as the differences to overall insertion performa=
nce were not adequate. Reserve testing does not make significant sense for =
an extensible container, as the entire benefit of such is that we can adapt=
to situations where we do not know the total number of elements in advance=
..</p>
<p>Tests are carried out on the following types: (a) a 8-bit type ie. char,=
(b) a 32-bit type ie. int, (c) a 64-bit type ie. double, (d) a small struc=
t containing two pointers and four scalar types, and (e) a large struct con=
taining 2 pointers, 4 scalar types, a large array of ints and a small array=
of chars. In order to better facilitate accurate time-keeping for short te=
sts, both container construction and destruction times are included in the =
tests. The sequence is as follows: construction, push N elements, read (bac=
k) + pop all elements, destruction. Because unlike a regular container, a s=
tack must be pushed for every pop, and popped for every read, it makes litt=
le sense to analyse these aspects of use separately, as what is most import=
ant is the overall time taken. For that reason (and for the sake of simplic=
ity) only total time benchmarks are presented below, however the separate t=
imings are <a href=3D"http://www.plflib.org/stack_all_gcc_results.htm">here=
for GCC</a> and <a href=3D"http://www.plflib.org/stack_all_msvc_results.ht=
m">here for MSVC</a>, for anyone interested.</p>
<h4>Total Time - GCC 5.1 x64</h4>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/char_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/char_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/int_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/int_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/double_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/double_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/small_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/small_struct_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/large_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/gcc/stack=
/large_struct_total_time_log.png"><br>
<h4>Total Time - MSVC 2013 x64</h4>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/char_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/char_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/int_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/int_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/double_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/double_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/small_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/small_struct_total_time_log.png"><br>
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/large_struct_total_time.png">
<img alt=3D"test result graph" src=3D"http://www.plflib.org/tests/msvc/stac=
k/large_struct_total_time_log.png"><br>
</BODY></HTML>
------=_Part_1571_948204667.1467674217071--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Mon, 4 Jul 2016 16:19:07 -0700 (PDT)
Raw View
------=_Part_11027_471166276.1467674347761
Content-Type: multipart/alternative;
boundary="----=_Part_11028_18560967.1467674347761"
------=_Part_11028_18560967.1467674347761
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, July 5, 2016 at 12:15:18 AM UTC+12, Tony V E wrote:
>
> Unfortunately, changing the default container in std::stack also breaks=
=20
> ABI.=20
>
> Anyone who does=20
>
> extern int foo(std::stack<Foo> =E2=80=8E& s);
>
> Expects that type not to change.=20
>
Since the std::stack layer functions don't change, and the only change=20
would be a positive performance advantage, how exactly would this break=20
someone's program in the use-case described?
--=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/4e388a52-cbc8-4ad5-aed4-7fe6d33da687%40isocpp.or=
g.
------=_Part_11028_18560967.1467674347761
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, July 5, 2016 at 12:15:18 AM UTC+12, Tony V=
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"backgro=
und-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
<=
div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)">Unfortunately, changing the default container =
in std::stack also breaks ABI.=C2=A0</div><div style=3D"width:100%;font-siz=
e:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;col=
or:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br=
></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,'=
Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initia=
l;background-color:rgb(255,255,255)">Anyone who does=C2=A0</div><div style=
=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:initial;fo=
nt-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73=
,125);text-align:initial;background-color:rgb(255,255,255)">=C2=A0 =C2=A0ex=
tern int foo(std::stack<Foo> =E2=80=8E& s);</div><div style=3D"wi=
dth:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-ser=
if,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(=
255,255,255)"><br></div><div style=3D"width:100%;font-size:initial;font-fam=
ily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);=
text-align:initial;background-color:rgb(255,255,255)">Expects that type not=
to change. <br></div></div></blockquote><div><br>Since the std::stack laye=
r functions don't change, and the only change=20
would be a positive performance advantage, how exactly would this break=20
someone's program in the use-case described?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e388a52-cbc8-4ad5-aed4-7fe6d33da687%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e388a52-cbc8-4ad5-aed4-7fe6d33da687=
%40isocpp.org</a>.<br />
------=_Part_11028_18560967.1467674347761--
------=_Part_11027_471166276.1467674347761--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jul 2016 19:32:02 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">It doesn't break a program compiled afresh, but it breaks a lib=
rary compiled with the old stack being linked into a program =E2=80=8Ecompi=
led with the new stack. That foo() function gets mangled with a different n=
ame (the default template param of std::deque (old library) or segemented_s=
tack (new exe) gets mangled into the name). So you get linker errors that a=
function foo() is missing, but looking at the headers, there it is. With _=
seemingly_ the same signature. </div><div style=3D"width: 100%; font-s=
ize: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; co=
lor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255,=
255);"><br></div><div style=3D"width: 100%; font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">Sent from my&=
nbsp;BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-s=
pacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; tex=
t-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb=
(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: =
Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b=
>Matthew Bentley</div><div><b>Sent: </b>Monday, July 4, 2016 7:19 PM</div><=
div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: <=
/b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] s=
td::segmented_stack proposal</div></div></td></tr></tbody></table><div styl=
e=3D"border-style: solid none none; border-top-color: rgb(186, 188, 209); b=
order-top-width: 1pt; font-size: initial; text-align: initial; background-c=
olor: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D"=
"><div dir=3D"ltr"><br>On Tuesday, July 5, 2016 at 12:15:18 AM UTC+12, Tony=
V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"backg=
round-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro'=
,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-c=
olor:rgb(255,255,255)">Unfortunately, changing the default container in std=
::stack also breaks ABI. </div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,1=
25);text-align:initial;background-color:rgb(255,255,255)"><br></div><div st=
yle=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)">Anyone who does </div><div style=3D"width:100%;font-siz=
e:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(3=
1,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div><=
div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"> extern int foo(std::stack<Foo> =E2=
=80=8E& s);</div><div style=3D"width:100%;font-size:initial;font-family=
:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:=
initial;background-color:rgb(255,255,255)"><br></div><div style=3D"width:10=
0%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;=
color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">=
Expects that type not to change. <br></div></div></blockquote><div><br>Sinc=
e the std::stack layer functions don't change, and the only change=20
would be a positive performance advantage, how exactly would this break=20
someone's program in the use-case described?<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/4e388a52-cbc8-4ad5-aed4-7fe6d33da687%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/4e388a52-cbc8-4ad5-aed4-7fe6d33d=
a687%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20160704233202.4898896.34755.13281%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160704233202.4898896.34755.13281%40gm=
ail.com</a>.<br />
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Mon, 4 Jul 2016 16:34:30 -0700 (PDT)
Raw View
------=_Part_19_1775290783.1467675270346
Content-Type: multipart/alternative;
boundary="----=_Part_20_998501147.1467675270346"
------=_Part_20_998501147.1467675270346
Content-Type: text/plain; charset=UTF-8
> I see a proposal... kinda. I see a document that contains a lot of
> performance charts and a general idea of what you want to standardize. But
> I see nothing *specific*; it's just, "I made a better performing stack
> implementation; here it is, so let's standardize it!"
>
>
.... No. Most proposals don't even go as far as I have done, in terms of
describing both behaviour and practice. Please review your behaviour here,
as you're coming off as aggressive, and for no reason.
> We don't standardize *implementations*; we standardize *behavior*. And
> you've said almost nothing about the behavior of your stack type here. What
> behavior you do talk about isn't generally the kind of behavior that gets
> standardized.
>
> You say it has O(1) inserts and removals at the rear. OK, but what is the
> performance of inserts/removals at the front? Does it even allow those?
> What about inserts/removals in other locations? What kind of iterators does
> it have?
>
> You shove all of these *very important* questions off into some
> supplementary document. And looking at that, it seems your "container" is
> not actually a *container*, by the standard library meaning of that term.
> It has no iterator ranges, no generalized insertion/removal, or many other
> features expected of a real container.
>
Obviously these questions are important to you, but not to anyone who
understands the subject. It's a drop-in replacement for std::stack. It has
the same functionality. This is made clear in the first paragraph. I'm not
interested in answering any further questions from you, as your grasp on
the subject is lacking. And the only reason it is lacking is because you
haven't bothered to read the material supplied. If you continue to compare
the structure to a vector, expect derision. If you continue to insist that
a container should include iterators, expect derision. If you can't
interpret graphs, expect derision. The fact that it doesn't attempt to
replicate deque/vector functionality is the same reason it performs better
than both of them in a stack context.
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/f5ca860a-bb45-4912-bee7-1a7115248f9d%40isocpp.org.
------=_Part_20_998501147.1467675270346
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I see a proposal... kinda. I see a document that contains a l=
ot of performance charts and a general idea of what you want to standardize=
.. But I see nothing <i>specific</i>; it's just, "I made a better p=
erforming stack implementation; here it is, so let's standardize it!&qu=
ot;<br><br></div></div></blockquote><div><br>... No. Most proposals don'=
;t even go as far as I have done, in terms of describing both behaviour and=
practice. Please review your behaviour here, as you're coming off as a=
ggressive, and for no reason.<br><br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>We don't standardize <i>im=
plementations</i>; we standardize <i>behavior</i>. And you've said almo=
st nothing about the behavior of your stack type here. What behavior you do=
talk about isn't generally the kind of behavior that gets standardized=
..<br><br>You say it has O(1) inserts and removals at the rear. OK, but what=
is the performance of inserts/removals at the front? Does it even allow th=
ose? What about inserts/removals in other locations? What kind of iterators=
does it have?<br><br>You shove all of these <i>very important</i> question=
s off into some supplementary document. And looking at that, it seems your =
"container" is not actually a <i>container</i>, by the standard l=
ibrary meaning of that term. It has no iterator ranges, no generalized inse=
rtion/removal, or many other features expected of a real container.<br></di=
v></div></blockquote><div><br>Obviously these questions are important to yo=
u, but not to anyone who understands the subject. It's a drop-in replac=
ement for std::stack. It has the same functionality. This is made clear in =
the first paragraph. I'm not interested in answering any further questi=
ons from you, as your grasp on the subject is lacking. And the only reason =
it is lacking is because you haven't bothered to read the material supp=
lied. If you continue to compare the structure to a vector, expect derision=
.. If you continue to insist that a container should include iterators, expe=
ct derision. If you can't interpret graphs, expect derision. The fact t=
hat it doesn't attempt to replicate deque/vector functionality is the s=
ame reason it performs better than both of them in a stack context.<br>Chee=
rs,<br>Matt<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f5ca860a-bb45-4912-bee7-1a7115248f9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f5ca860a-bb45-4912-bee7-1a7115248f9d=
%40isocpp.org</a>.<br />
------=_Part_20_998501147.1467675270346--
------=_Part_19_1775290783.1467675270346--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Mon, 4 Jul 2016 16:40:02 -0700 (PDT)
Raw View
------=_Part_16_1033321398.1467675602540
Content-Type: multipart/alternative;
boundary="----=_Part_17_1382902011.1467675602540"
------=_Part_17_1382902011.1467675602540
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, July 5, 2016 at 11:32:06 AM UTC+12, Tony V E wrote:
>
> It doesn't break a program compiled afresh, but it breaks a library=20
> compiled with the old stack being linked into a program =E2=80=8Ecompiled=
with the=20
> new stack. That foo() function gets mangled with a different name (the=20
> default template param of std::deque (old library) or segemented_stack (n=
ew=20
> exe) gets mangled into the name). So you get linker errors that a functio=
n=20
> foo() is missing, but looking at the headers, there it is. With _seemingl=
y_=20
> the same signature.=20
>
>
Right, I understand now. Thank you.
Do you have any alternative suggestions?
So I guess the only non-breaking solution would be to introduce the=20
container, with the explanation that it's structure guarantee's higher=20
performance (particularly in the case of libraries like Dinkumware's which=
=20
have poorly-performing deque implementations)?
--=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/a754b280-807f-4c34-bd33-c2e054f0a1e0%40isocpp.or=
g.
------=_Part_17_1382902011.1467675602540
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, July 5, 2016 at 11:32:06 AM UTC+12, Tony V=
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"backgro=
und-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
<=
div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)">It doesn't break a program compiled afresh=
, but it breaks a library compiled with the old stack being linked into a p=
rogram =E2=80=8Ecompiled with the new stack. That foo() function gets mangl=
ed with a different name (the default template param of std::deque (old lib=
rary) or segemented_stack (new exe) gets mangled into the name). So you get=
linker errors that a function foo() is missing, but looking at the headers=
, there it is. With _seemingly_ the same signature.=C2=A0</div><br></div></=
blockquote><div><br>Right, I understand now. Thank you.<br>Do you have any =
alternative suggestions?<br>So I guess the only non-breaking solution would=
be to introduce the container, with the explanation that it's structur=
e guarantee's higher performance (particularly in the case of libraries=
like Dinkumware's which have poorly-performing deque implementations)?=
<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a754b280-807f-4c34-bd33-c2e054f0a1e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a754b280-807f-4c34-bd33-c2e054f0a1e0=
%40isocpp.org</a>.<br />
------=_Part_17_1382902011.1467675602540--
------=_Part_16_1033321398.1467675602540--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 04 Jul 2016 20:13:40 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">One thing would be to see how good you could get the performanc=
e of deque to be. Maybe it can be made somewhat better without chang=
=E2=80=8Eing it's interface or guarantees? </div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
73, 125); text-align: initial; background-color: rgb(255, 255, 255);">In p=
articular, are your performance numbers fundamentally because of an API/beh=
aviour/guarantees change, or just because you tried, and no one has really =
tried to write a better performing deque. </div><div style=3D"width: 1=
00%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial;=
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, =
73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br><=
/div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, '=
Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: in=
itial; background-color: rgb(255, 255, 255);">Otherwise we just offer segem=
ented_stack as an alternative. Which then leads to the questions of whether=
it should be a full container (with iterators etc) or whether it is only u=
seful for a stack. If it is only useful for a stack, maybe it should be a s=
tack replacement instead of something that plugs into stack?</div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial; fon=
t-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, =
125); text-align: initial; background-color: rgb(255, 255, 255);"><br style=
=3D"display:initial"></div> =
=
<di=
v style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);">Sent from my BlackBerry portab=
le Babbage Device</div> =
=
<table width=
=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><tr>=
<td colspan=3D"2" style=3D"font-size: initial; text-align: initial; backgro=
und-color: rgb(255, 255, 255);"> <div style=3D"bo=
rder-style: solid none none; border-top-color: rgb(181, 196, 223); border-t=
op-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', =
'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Matthew Bentley</div><di=
v><b>Sent: </b>Monday, July 4, 2016 7:40 PM</div><div><b>To: </b>ISO C++ St=
andard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.o=
rg</div><div><b>Subject: </b>Re: [std-proposals] std::segmented_stack propo=
sal</div></div></td></tr></tbody></table><div style=3D"border-style: solid =
none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; fon=
t-size: initial; text-align: initial; background-color: rgb(255, 255, 255);=
"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr"><br>On=
Tuesday, July 5, 2016 at 11:32:06 AM UTC+12, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div style=3D"background-color:rgb(255,255,2=
55);line-height:initial" lang=3D"en-US"> =
<div style=3D"width:100%=
;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;co=
lor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">It=
doesn't break a program compiled afresh, but it breaks a library compiled =
with the old stack being linked into a program =E2=80=8Ecompiled with the n=
ew stack. That foo() function gets mangled with a different name (the defau=
lt template param of std::deque (old library) or segemented_stack (new exe)=
gets mangled into the name). So you get linker errors that a function foo(=
) is missing, but looking at the headers, there it is. With _seemingly_ the=
same signature. </div><br></div></blockquote><div><br>Right, I unders=
tand now. Thank you.<br>Do you have any alternative suggestions?<br>So I gu=
ess the only non-breaking solution would be to introduce the container, wit=
h the explanation that it's structure guarantee's higher performance (parti=
cularly in the case of libraries like Dinkumware's which have poorly-perfor=
ming deque implementations)?<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/a754b280-807f-4c34-bd33-c2e054f0a1e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a754b280-807f-4c34-bd33-c2e054f0=
a1e0%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20160705001340.4898896.7843.13285%40g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/20160705001340.4898896.7843.13285%40gmai=
l.com</a>.<br />
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 4 Jul 2016 19:08:44 -0700 (PDT)
Raw View
------=_Part_230_1473713597.1467684524844
Content-Type: multipart/alternative;
boundary="----=_Part_231_1561689892.1467684524845"
------=_Part_231_1561689892.1467684524845
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8A=E5=8D=887:34:30=EF=BC=8CMatthew Bentley=E5=86=99=E9=81=93=EF=BC=
=9A
>
>
> I see a proposal... kinda. I see a document that contains a lot of=20
>> performance charts and a general idea of what you want to standardize. B=
ut=20
>> I see nothing *specific*; it's just, "I made a better performing stack=
=20
>> implementation; here it is, so let's standardize it!"
>>
>>
> ... No. Most proposals don't even go as far as I have done, in terms of=
=20
> describing both behaviour and practice. Please review your behaviour here=
,=20
> as you're coming off as aggressive, and for no reason.
>
> =20
>
>> We don't standardize *implementations*; we standardize *behavior*. And=
=20
>> you've said almost nothing about the behavior of your stack type here. W=
hat=20
>> behavior you do talk about isn't generally the kind of behavior that get=
s=20
>> standardized.
>>
>> You say it has O(1) inserts and removals at the rear. OK, but what is th=
e=20
>> performance of inserts/removals at the front? Does it even allow those?=
=20
>> What about inserts/removals in other locations? What kind of iterators d=
oes=20
>> it have?
>>
>> You shove all of these *very important* questions off into some=20
>> supplementary document. And looking at that, it seems your "container" i=
s=20
>> not actually a *container*, by the standard library meaning of that=20
>> term. It has no iterator ranges, no generalized insertion/removal, or ma=
ny=20
>> other features expected of a real container.
>>
>
> Obviously these questions are important to you, but not to anyone who=20
> understands the subject. It's a drop-in replacement for std::stack. It ha=
s=20
> the same functionality. This is made clear in the first paragraph. I'm no=
t=20
> interested in answering any further questions from you, as your grasp on=
=20
> the subject is lacking. And the only reason it is lacking is because you=
=20
> haven't bothered to read the material supplied. If you continue to compar=
e=20
> the structure to a vector, expect derision. If you continue to insist tha=
t=20
> a container should include iterators, expect derision. If you can't=20
> interpret graphs, expect derision. The fact that it doesn't attempt to=20
> replicate deque/vector functionality is the same reason it performs bette=
r=20
> than both of them in a stack context.
>
At least one problem here is important to anyone who understands the=20
subject. That is, you claim you have provided something to be the=20
underlying "container" of `std::stack`, but it actually contradicts the=20
meaning of "container" by definition in current standard, since your=20
"container" does not meet the container requirements (e.g. well-formed=20
expressions in Table 103) and it is not hidden from public interface of=20
`std::stack`, so code like `std::stack<T>::container_type::iterator_type`=
=20
would break. (Also note [container.adaptors.general]/1 specifies the copy=
=20
of container in initialization, which may be implemented involving=20
iterators.) This is a bug more obvious than any ABI issue (which is merely=
=20
a QoI problem rather than introducing defect into the standard), until some=
=20
modification of [container.adaptors] is included in the proposed=20
specification.
The second problem meaningful making sense to everyone here is the section=
=20
"technical specification". The expected contents are totally left out. The=
=20
easiest way to fix it is to rename the title to something else, probably.
Cheers,
> Matt
>
--=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/72fc0fa5-1294-4a2d-8c4e-d6b1ccf3388e%40isocpp.or=
g.
------=_Part_231_1561689892.1467684524845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=887:34:30=EF=BC=8CMatthew Bentle=
y=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I see a proposal... kinda. I see a document that contains a lot of pe=
rformance charts and a general idea of what you want to standardize. But I =
see nothing <i>specific</i>; it's just, "I made a better performin=
g stack implementation; here it is, so let's standardize it!"<br><=
br></div></div></blockquote><div><br>... No. Most proposals don't even =
go as far as I have done, in terms of describing both behaviour and practic=
e. Please review your behaviour here, as you're coming off as aggressiv=
e, and for no reason.<br><br>=C2=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>We don't standardize <i>implementations=
</i>; we standardize <i>behavior</i>. And you've said almost nothing ab=
out the behavior of your stack type here. What behavior you do talk about i=
sn't generally the kind of behavior that gets standardized.<br><br>You =
say it has O(1) inserts and removals at the rear. OK, but what is the perfo=
rmance of inserts/removals at the front? Does it even allow those? What abo=
ut inserts/removals in other locations? What kind of iterators does it have=
?<br><br>You shove all of these <i>very important</i> questions off into so=
me supplementary document. And looking at that, it seems your "contain=
er" is not actually a <i>container</i>, by the standard library meanin=
g of that term. It has no iterator ranges, no generalized insertion/removal=
, or many other features expected of a real container.<br></div></div></blo=
ckquote><div><br>Obviously these questions are important to you, but not to=
anyone who understands the subject. It's a drop-in replacement for std=
::stack. It has the same functionality. This is made clear in the first par=
agraph. I'm not interested in answering any further questions from you,=
as your grasp on the subject is lacking. And the only reason it is lacking=
is because you haven't bothered to read the material supplied. If you =
continue to compare the structure to a vector, expect derision. If you cont=
inue to insist that a container should include iterators, expect derision. =
If you can't interpret graphs, expect derision. The fact that it doesn&=
#39;t attempt to replicate deque/vector functionality is the same reason it=
performs better than both of them in a stack context.<br></div></div></blo=
ckquote><div><br>At least one problem here is important to anyone who under=
stands the subject. That is, you claim you have provided something to be th=
e underlying "container" of `std::stack`, but it actually contrad=
icts the meaning of "container" by definition in current standard=
, since your "container" does not meet the container requirements=
(e.g. well-formed expressions in Table 103) and it is not hidden from publ=
ic interface of `std::stack`, so code like `std::stack<T>::container_=
type::iterator_type` would break. (Also note [container.adaptors.general]/1=
specifies the copy of container
in initialization, which may be implemented involving iterators.) This is =
a bug more obvious than any ABI issue (which is merely a QoI problem rather=
than introducing defect into the standard), until some modification of [co=
ntainer.adaptors] is included in the proposed specification.<br><br>The sec=
ond problem meaningful making sense to everyone here is the section "t=
echnical specification". The expected contents are totally left out. T=
he easiest way to fix it is to rename the title to something else, probably=
..<br><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>Cheers,<br>Matt<br></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/72fc0fa5-1294-4a2d-8c4e-d6b1ccf3388e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72fc0fa5-1294-4a2d-8c4e-d6b1ccf3388e=
%40isocpp.org</a>.<br />
------=_Part_231_1561689892.1467684524845--
------=_Part_230_1473713597.1467684524844--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Mon, 4 Jul 2016 22:26:17 -0400
Raw View
--001a114094da7f4d0f0536da2d71
Content-Type: text/plain; charset=UTF-8
But...a container *must *include iterators. The very concept of a
container *requires
iteration.*
Why would you ridicule someone for pointing out that which is true?
On Mon, Jul 4, 2016 at 7:34 PM, Matthew Bentley <mattreecebentley@gmail.com>
wrote:
>
> I see a proposal... kinda. I see a document that contains a lot of
>> performance charts and a general idea of what you want to standardize. But
>> I see nothing *specific*; it's just, "I made a better performing stack
>> implementation; here it is, so let's standardize it!"
>>
>>
> ... No. Most proposals don't even go as far as I have done, in terms of
> describing both behaviour and practice. Please review your behaviour here,
> as you're coming off as aggressive, and for no reason.
>
>
>
>> We don't standardize *implementations*; we standardize *behavior*. And
>> you've said almost nothing about the behavior of your stack type here. What
>> behavior you do talk about isn't generally the kind of behavior that gets
>> standardized.
>>
>> You say it has O(1) inserts and removals at the rear. OK, but what is the
>> performance of inserts/removals at the front? Does it even allow those?
>> What about inserts/removals in other locations? What kind of iterators does
>> it have?
>>
>> You shove all of these *very important* questions off into some
>> supplementary document. And looking at that, it seems your "container" is
>> not actually a *container*, by the standard library meaning of that
>> term. It has no iterator ranges, no generalized insertion/removal, or many
>> other features expected of a real container.
>>
>
> Obviously these questions are important to you, but not to anyone who
> understands the subject. It's a drop-in replacement for std::stack. It has
> the same functionality. This is made clear in the first paragraph. I'm not
> interested in answering any further questions from you, as your grasp on
> the subject is lacking. And the only reason it is lacking is because you
> haven't bothered to read the material supplied. If you continue to compare
> the structure to a vector, expect derision. If you continue to insist that
> a container should include iterators, expect derision. If you can't
> interpret graphs, expect derision. The fact that it doesn't attempt to
> replicate deque/vector functionality is the same reason it performs better
> than both of them in a stack context.
> 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/f5ca860a-bb45-4912-bee7-1a7115248f9d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f5ca860a-bb45-4912-bee7-1a7115248f9d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_m%3DxcqGjX8_uE3%2BwsyQwuJsvNg7HiT%3DFXuwfMVCRN7FQ%40mail.gmail.com.
--001a114094da7f4d0f0536da2d71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">But...a container <i>must </i>include iterators. The very =
concept of a container <i>requires iteration.</i><div>Why would you ridicul=
e someone for pointing out that which is true?</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Mon, Jul 4, 2016 at 7:34 PM, Ma=
tthew Bentley <span dir=3D"ltr"><<a href=3D"mailto:mattreecebentley@gmai=
l.com" target=3D"_blank">mattreecebentley@gmail.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I see a proposal.=
... kinda. I see a document that contains a lot of performance charts and a =
general idea of what you want to standardize. But I see nothing <i>specific=
</i>; it's just, "I made a better performing stack implementation;=
here it is, so let's standardize it!"<br><br></div></div></blockq=
uote></span><div><br>... No. Most proposals don't even go as far as I h=
ave done, in terms of describing both behaviour and practice. Please review=
your behaviour here, as you're coming off as aggressive, and for no re=
ason.<br><br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>We don't standardize <i>implementation=
s</i>; we standardize <i>behavior</i>. And you've said almost nothing a=
bout the behavior of your stack type here. What behavior you do talk about =
isn't generally the kind of behavior that gets standardized.<br><br>You=
say it has O(1) inserts and removals at the rear. OK, but what is the perf=
ormance of inserts/removals at the front? Does it even allow those? What ab=
out inserts/removals in other locations? What kind of iterators does it hav=
e?<br><br>You shove all of these <i>very important</i> questions off into s=
ome supplementary document. And looking at that, it seems your "contai=
ner" is not actually a <i>container</i>, by the standard library meani=
ng of that term. It has no iterator ranges, no generalized insertion/remova=
l, or many other features expected of a real container.<br></div></div></bl=
ockquote></span><div><br>Obviously these questions are important to you, bu=
t not to anyone who understands the subject. It's a drop-in replacement=
for std::stack. It has the same functionality. This is made clear in the f=
irst paragraph. I'm not interested in answering any further questions f=
rom you, as your grasp on the subject is lacking. And the only reason it is=
lacking is because you haven't bothered to read the material supplied.=
If you continue to compare the structure to a vector, expect derision. If =
you continue to insist that a container should include iterators, expect de=
rision. If you can't interpret graphs, expect derision. The fact that i=
t doesn't attempt to replicate deque/vector functionality is the same r=
eason it performs better than both of them in a stack context.<br>Cheers,<b=
r>Matt<br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f5ca860a-bb45-4912-bee7-1a7115248f9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f5ca860a-bb45-=
4912-bee7-1a7115248f9d%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAMD6iD_m%3DxcqGjX8_uE3%2BwsyQwuJsvNg=
7HiT%3DFXuwfMVCRN7FQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_m%3=
DxcqGjX8_uE3%2BwsyQwuJsvNg7HiT%3DFXuwfMVCRN7FQ%40mail.gmail.com</a>.<br />
--001a114094da7f4d0f0536da2d71--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jul 2016 07:45:56 -0700 (PDT)
Raw View
------=_Part_1513_1190487131.1467729957026
Content-Type: multipart/alternative;
boundary="----=_Part_1514_65679888.1467729957026"
------=_Part_1514_65679888.1467729957026
Content-Type: text/plain; charset=UTF-8
On Monday, July 4, 2016 at 7:34:30 PM UTC-4, Matthew Bentley wrote:
>
>
> I see a proposal... kinda. I see a document that contains a lot of
>> performance charts and a general idea of what you want to standardize. But
>> I see nothing *specific*; it's just, "I made a better performing stack
>> implementation; here it is, so let's standardize it!"
>>
>>
> ... No. Most proposals don't even go as far as I have done, in terms of
> describing both behaviour and practice.
>
Most proposals where? I'd say that the majority of papers actually published
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/> provide actual
standards wording. And those that don't go into more detail about the
specific behavior desired than you have.
The point I was trying to make is that the details you consider important
are not the details which are important for *standardization*. Yes,
performance numbers are good to have, when proposing performance-based
features. But literally *80 percent* of the vertical space of your proposal
is taken up by a bunch of graphs.
Please review your behaviour here, as you're coming off as aggressive, and
> for no reason.
>
I'm being aggressive, yet you tacitly insult everyone else who makes
proposals by suggesting that yours is more detailed than theirs?
We don't standardize *implementations*; we standardize *behavior*. And
>> you've said almost nothing about the behavior of your stack type here. What
>> behavior you do talk about isn't generally the kind of behavior that gets
>> standardized.
>>
>> You say it has O(1) inserts and removals at the rear. OK, but what is the
>> performance of inserts/removals at the front? Does it even allow those?
>> What about inserts/removals in other locations? What kind of iterators does
>> it have?
>>
>> You shove all of these *very important* questions off into some
>> supplementary document. And looking at that, it seems your "container" is
>> not actually a *container*, by the standard library meaning of that
>> term. It has no iterator ranges, no generalized insertion/removal, or many
>> other features expected of a real container.
>>
>
> Obviously these questions are important to you, but not to anyone who
> understands the subject. It's a drop-in replacement for std::stack. It has
> the same functionality. This is made clear in the first paragraph. I'm not
> interested in answering any further questions from you, as your grasp on
> the subject is lacking. And the only reason it is lacking is because you
> haven't bothered to read the material supplied. If you continue to compare
> the structure to a vector, expect derision.
>
But it *is* like a vector; there's no way to get around that fact. Its has
many of the same behavioral elements of a vector: fast end insertion being
the most obvious. Obviously it has other behavioral elements too.
Conceptually speaking, your class is a specialized vector which focuses on
avoiding reallocation overhead instead of contiguous access to the elements.
If you continue to insist that a container should include iterators, expect
> derision.
>
Should I "expect derision" if I cite the C++ standard section
[container.requirements.general], which makes it abundantly clear that C++
standard containers have iterators?
You're making a proposal for adding something to the C++ standard. Using
vernacular language is not going to cut it. You have to use terminology as
it is used by the C++ standard. So if you claim that a proposed type is a
"container", then it actually needs to conform to [container.requirements],
the standard section that defines what a container has to have.
Again, there's a reason why `std::stack` is not a container.
If you can't interpret graphs, expect derision.
>
The interpretation of your graphs is that your proposed stack performs
faster under most circumstances than similar standard library classes. But
nobody claimed that your stack was not faster performing.
If you can't focus on what was actually said, expect derision ;)
The fact that it doesn't attempt to replicate deque/vector functionality is
> the same reason it performs better than both of them in a stack context.
>
No, it's not. Well, not the way you mean.
There is nothing special about your segmented stack object which would
prevent adding a proper, C++ container interface. Adding iterators would
not make it one bit slower. Adding the ability to insert or remove
arbitrarily would not make the object's *preferred* operations any slower.
Adding the ability to insert or remove multiple elements from the end would
not make it any slower; indeed, it would make its preferred operations
*faster*.
Adding all of the little things that a C++ container is expected to have
would not change any of the things about your type that make it faster in
those situations where it is faster than what we currently have.
Also, it would be a useful container class to have. Why? Because unlike
`vector`, insertion at the end will *never* invalidate iterators or
pointers. It also has a nice `trim_trailing_groups` operation that
preserves iterators. Removal from a particular point to the end would never
invalidate iterators before that point, unlike a `deque`, where iterators
are invalidated anytime internal removal happens.
The limitation of only being able to inspect/manipulate the top element is
*unnecessary*.
Now, we can discuss what *kind* of iterators it should have. I don't know
the details of the implementation, but I think random access or even
bidirectional would probably require more deque-like overhead. Limiting
them to forward iterators would seem more prudent.
--
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/09dbf27d-e04b-4028-93d5-deffadc024ed%40isocpp.org.
------=_Part_1514_65679888.1467729957026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 4, 2016 at 7:34:30 PM UTC-4, Matthew Bentl=
ey 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"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I see a propo=
sal... kinda. I see a document that contains a lot of performance charts an=
d a general idea of what you want to standardize. But I see nothing <i>spec=
ific</i>; it's just, "I made a better performing stack implementat=
ion; here it is, so let's standardize it!"<br><br></div></div></bl=
ockquote><div><br>... No. Most proposals don't even go as far as I have=
done, in terms of describing both behaviour and practice.</div></div></blo=
ckquote><div><br>Most proposals where? I'd say that the majority of <a =
href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/">papers actuall=
y published</a> provide actual standards wording. And those that don't =
go into more detail about the specific behavior desired than you have.<br><=
br>The point I was trying to make is that the details you consider importan=
t are not the details which are important for <i>standardization</i>. Yes, =
performance numbers are good to have, when proposing performance-based feat=
ures. But literally <i>80 percent</i> of the vertical space of your proposa=
l is taken up by a bunch of graphs.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>Please review your behaviour here,=
as you're coming off as aggressive, and for no reason.<br></div></div>=
</blockquote><div><br>I'm being aggressive, yet you tacitly insult ever=
yone else who makes proposals by suggesting that yours is more detailed tha=
n theirs?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>We =
don't standardize <i>implementations</i>; we standardize <i>behavior</i=
>. And you've said almost nothing about the behavior of your stack type=
here. What behavior you do talk about isn't generally the kind of beha=
vior that gets standardized.<br><br>You say it has O(1) inserts and removal=
s at the rear. OK, but what is the performance of inserts/removals at the f=
ront? Does it even allow those? What about inserts/removals in other locati=
ons? What kind of iterators does it have?<br><br>You shove all of these <i>=
very important</i> questions off into some supplementary document. And look=
ing at that, it seems your "container" is not actually a <i>conta=
iner</i>, by the standard library meaning of that term. It has no iterator =
ranges, no generalized insertion/removal, or many other features expected o=
f a real container.<br></div></div></blockquote><div><br>Obviously these qu=
estions are important to you, but not to anyone who understands the subject=
.. It's a drop-in replacement for std::stack. It has the same functional=
ity. This is made clear in the first paragraph. I'm not interested in a=
nswering any further questions from you, as your grasp on the subject is la=
cking. And the only reason it is lacking is because you haven't bothere=
d to read the material supplied. If you continue to compare the structure t=
o a vector, expect derision.</div></div></blockquote><div><br>But it <b>is<=
/b> like a vector; there's no way to get around that fact. Its has many=
of the same behavioral elements of a vector: fast end insertion being the =
most obvious. Obviously it has other behavioral elements too.<br><br>Concep=
tually speaking, your class is a specialized vector which focuses on avoidi=
ng reallocation overhead instead of contiguous access to the elements.<br><=
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=
>If you continue to insist that a container should include iterators, expec=
t derision.</div></div></blockquote><div><br>Should I "expect derision=
" if I cite the C++ standard section [container.requirements.general],=
which makes it abundantly clear that C++ standard containers have iterator=
s?<br><br>You're making a proposal for adding something to the C++ stan=
dard. Using vernacular language is not going to cut it. You have to use ter=
minology as it is used by the C++ standard. So if you claim that a proposed=
type is a "container", then it actually needs to conform to [con=
tainer.requirements], the standard section that defines what a container ha=
s to have.<br><br>Again, there's a reason why `std::stack` is not a con=
tainer.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div> If you can't interpret graphs, expect derision.</div></d=
iv></blockquote><div><br>The interpretation of your graphs is that your pro=
posed stack performs faster under most circumstances than similar standard =
library classes. But nobody claimed that your stack was not faster performi=
ng.<br><br>If you can't focus on what was actually said, expect derisio=
n ;)<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div> The fact that it doesn't attempt to replicate deque/vector f=
unctionality is the same reason it performs better than both of them in a s=
tack context.<br></div></div></blockquote><div><br>No, it's not. Well, =
not the way you mean.<br><br>There is nothing special about your segmented =
stack object which would prevent adding a proper, C++ container interface. =
Adding iterators would not make it one bit slower. Adding the ability to in=
sert or remove arbitrarily would not make the object's <i>preferred</i>=
operations any slower. Adding the ability to insert or remove multiple ele=
ments from the end would not make it any slower; indeed, it would make its =
preferred operations <i>faster</i>.<br><br>Adding all of the little things =
that a C++ container is expected to have would not change any of the things=
about your type that make it faster in those situations where it is faster=
than what we currently have.<br><br>Also, it would be a useful container c=
lass to have. Why? Because unlike `vector`, insertion at the end will <i>ne=
ver</i> invalidate iterators or pointers. It also has a nice `trim_trailing=
_groups` operation that preserves iterators. Removal from a particular poin=
t to the end would never invalidate iterators before that point, unlike a `=
deque`, where iterators are invalidated anytime internal removal happens.<b=
r><br>The limitation of only being able to inspect/manipulate the top eleme=
nt is <i>unnecessary</i>.<br><br>Now, we can discuss what <i>kind</i> of it=
erators it should have. I don't know the details of the implementation,=
but I think random access or even bidirectional would probably require mor=
e deque-like overhead. Limiting them to forward iterators would seem more p=
rudent.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09dbf27d-e04b-4028-93d5-deffadc024ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09dbf27d-e04b-4028-93d5-deffadc024ed=
%40isocpp.org</a>.<br />
------=_Part_1514_65679888.1467729957026--
------=_Part_1513_1190487131.1467729957026--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 6 Jul 2016 16:22:54 -0700 (PDT)
Raw View
------=_Part_12103_880754057.1467847374768
Content-Type: multipart/alternative;
boundary="----=_Part_12104_746119675.1467847374769"
------=_Part_12104_746119675.1467847374769
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:
> Removal from a particular point to the end would never invalidate
> iterators before that point, unlike a `deque`, where iterators are
> invalidated anytime internal removal happens.
>
If an erase operation erases either the first or the last element of the
deque, then iterators to elements not erased are unaffected - even if it
also erases other elements. See [deque.modifiers]/4.
--
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/ab8d9f86-861a-478b-9596-5e93920b30f7%40isocpp.org.
------=_Part_12104_746119675.1467847374769
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol B=
olas wrote:<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"lt=
r"><div>Removal from a particular point to the end would never invalidate i=
terators before that point, unlike a `deque`, where iterators are invalidat=
ed anytime internal removal happens.</div></div></blockquote><div><br></div=
><div>If an erase operation erases either the first or the last element of =
the deque, then iterators to elements not erased are unaffected - even if i=
t also erases other elements. See [deque.modifiers]/4.</div></div><div><br>=
</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ab8d9f86-861a-478b-9596-5e93920b30f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab8d9f86-861a-478b-9596-5e93920b30f7=
%40isocpp.org</a>.<br />
------=_Part_12104_746119675.1467847374769--
------=_Part_12103_880754057.1467847374768--
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Fri, 08 Jul 2016 11:28:32 +1200
Raw View
On 5/07/2016 2:26 p.m., Ren Industries wrote:
> But...a container /must /include iterators. The very concept of a
> container /requires iteration./
> Why would you ridicule someone for pointing out that which is true?
Please point me to the technical specification that points this out.
As for the ridicule part, well, why would you allow him to ridicule me
in the first place?
> At least one problem here is important to anyone who understands the
> subject. That is, you claim you have provided something to be the
> underlying "container" of `std::stack`, but it actually contradicts the
> meaning of "container" by definition in current standard, since your
> "container" does not meet the container requirements (e.g. well-formed
> expressions in Table 103) and it is not hidden from public interface of
> `std::stack`, so code like
> `std::stack<T>::container_type::iterator_type` would break. (Also note
> [container.adaptors.general]/1 specifies the copy of container in
> initialization, which may be implemented involving iterators.) This is a
> bug more obvious than any ABI issue (which is merely a QoI problem
> rather than introducing defect into the standard), until some
> modification of [container.adaptors] is included in the proposed
> specification.
Okay, that makes more sense, but which version of the standard are you
looking at? Table 103 gives me unordered associative container data in
n4296. Also, are there any ways to introduce this class without having
to include functionality that is not required ie. iterators? As making
the modifications to include this functionality will, in fact (I did
write the damn thing), force changes that will decrease performance
without adding anything useful for a stack.
> The second problem meaningful making sense to everyone here is the
> section "technical specification". The expected contents are totally
> left out. The easiest way to fix it is to rename the title to something
> else, probably.
Okay, that's fair enough.
M@
--
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/577EE5A0.1000101%40gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 7 Jul 2016 18:38:57 -0500
Raw View
--001a11c14d40f6a113053714329f
Content-Type: text/plain; charset=UTF-8
On 7 July 2016 at 18:28, Matt Bentley <mattreecebentley@gmail.com> wrote:
> Also, are there any ways to introduce this class without having to include
> functionality that is not required ie. iterators?
As multiple people have already told you, propose it as a new independent
class instead of trying to pigeonhole it into std::stack.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BOqBx9scDtbNVwLsfk-3fptm529Qvh0F3_WiHaZq6gQ8w%40mail.gmail.com.
--001a11c14d40f6a113053714329f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 7 July 2016 at 18:28, Matt Bentley <span dir=3D"ltr">&l=
t;<a href=3D"mailto:mattreecebentley@gmail.com" target=3D"_blank">mattreece=
bentley@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, are there any wa=
ys to introduce this class without having to include functionality that is =
not required ie. iterators? </blockquote><div><br></div><div>As multiple pe=
ople have already told you, propose it as a new independent class instead o=
f trying to pigeonhole it into std::stack.</div></div>-- <br><div class=3D"=
gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><=
div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOqBx9scDtbNVwLsfk-3fptm529Qv=
h0F3_WiHaZq6gQ8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOqBx9s=
cDtbNVwLsfk-3fptm529Qvh0F3_WiHaZq6gQ8w%40mail.gmail.com</a>.<br />
--001a11c14d40f6a113053714329f--
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Fri, 08 Jul 2016 12:04:07 +1200
Raw View
Sorry, I missed this earlier.
On 5/07/2016 12:13 p.m., Tony V E wrote:
> One thing would be to see how good you could get the performance of
> deque to be. Maybe it can be made somewhat better without chang=E2=80=8E=
ing
> it's interface or guarantees?
I'm not sure that you can. The GCC (libstdC++) deque I'm comparing=20
against outperforms GCC's vector in stack tests, and from other tests=20
I've done I can see that it has very close iteration performance to vector.
Although I haven't implemented a deque using the chained-group pattern=20
as mentioned in the text, I think getting iteration performance that=20
close would be hard.
I don't have the time to implement a full deque as I have another=20
container I'm working on.
But it remains that this particular structural allocation pattern seems=20
to work particularly well for stacks.
Adding in deque functionality would double the amount of metadata=20
necessary per group. As to whether it would work better than the=20
libstdC++ implementation, that's a task for someone else I'm afraid.
> In particular, are your performance numbers fundamentally because of an
> API/behaviour/guarantees change, or just because you tried, and no one
> has really tried to write a better performing deque.
A bit of both. The behaviour at least should be the same as std::stack.=20
I don't know how every library implements deque, so I can't guarantee=20
that chained-block pattern hasn't been tried, I gather the most common=20
approach is a vector of memory blocks.
> Otherwise we just offer segemented_stack as an alternative. Which then
> leads to the questions of whether it should be a full container (with
> iterators etc) or whether it is only useful for a stack. If it is only
> useful for a stack, maybe it should be a stack replacement instead of
> something that plugs into stack?
I think the general consensus is that it should avoid referencing=20
std::stack at all and just be an alternative. My problem is I have no=20
idea how to phrase that. It's not a container, apparently, according to=20
the standard, and it's not a container adaptor, but it is a container,=20
because it contains elements, and that's it's purpose. So what do I call=20
it? A container-type class? I have no idea.
--=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/577EEDF7.8080102%40gmail.com.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 7 Jul 2016 19:07:59 -0500
Raw View
On Thu, Jul 7, 2016 at 7:04 PM, Matt Bentley <mattreecebentley@gmail.com> wrote:
> It's not a container, apparently, according to the standard, and it's not a
> container adaptor, but it is a container, because it contains elements, and
> that's it's purpose. So what do I call it? A container-type class? I have no
> idea.
Define a new Concept: stack.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuALm3tGP_NTaAc1t1KhF6ZC7ydupKBvh9B%3DKRW7qkpBsQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 7 Jul 2016 18:45:51 -0700 (PDT)
Raw View
------=_Part_4951_1862050289.1467942352031
Content-Type: multipart/alternative;
boundary="----=_Part_4952_697899315.1467942352031"
------=_Part_4952_697899315.1467942352031
Content-Type: text/plain; charset=UTF-8
On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:
>
> On 5/07/2016 2:26 p.m., Ren Industries wrote:
> > But...a container /must /include iterators. The very concept of a
> > container /requires iteration./
> > Why would you ridicule someone for pointing out that which is true?
>
> Please point me to the technical specification that points this out.
>
N4852 <http://wg21.link/N4852>(PDF), [container.requirements.general],
Table 103.
As for the ridicule part, well, why would you allow him to ridicule me
> in the first place?
>
1: He doesn't control what other people do.
2: I didn't ridicule you.
> > At least one problem here is important to anyone who understands the
> > subject. That is, you claim you have provided something to be the
> > underlying "container" of `std::stack`, but it actually contradicts the
> > meaning of "container" by definition in current standard, since your
> > "container" does not meet the container requirements (e.g. well-formed
> > expressions in Table 103) and it is not hidden from public interface of
> > `std::stack`, so code like
> > `std::stack<T>::container_type::iterator_type` would break. (Also note
> > [container.adaptors.general]/1 specifies the copy of container in
> > initialization, which may be implemented involving iterators.) This is a
> > bug more obvious than any ABI issue (which is merely a QoI problem
> > rather than introducing defect into the standard), until some
> > modification of [container.adaptors] is included in the proposed
> > specification.
>
> Okay, that makes more sense, but which version of the standard are you
> looking at? Table 103 gives me unordered associative container data in
> n4296. Also, are there any ways to introduce this class without having
> to include functionality that is not required ie. iterators?
Sure. Step 1 in that is to not call it a container.
Step 2 is to *prove* (perhaps by detailing the particulars of your
implementation) that support for generalized container functionality would
*require* degrading the performance of the object in its natural
environment.
My point here is that it's not something you should leave unaddressed; it's
very much an "elephant in the room" for this type. People will wonder why
it's not a full-fledged container. And as I pointed out before, there are
use cases which could benefit from this type's allocation and iterator
invalidation pattern with more generalized container functionality.
Step 3: propose a change of `std::stack`'s requirements. Right now, it
requires that the type be a "sequence container". But that's unnecessary.
All it really needs is a type which is copyable and supports `back`,
`push/emplace_back`, `size`, `empty`, and `pop_back`. Iterator support and
other container features are unnecessary.
As making
> the modifications to include this functionality will, in fact (I did
> write the damn thing), force changes that will decrease performance
> without adding anything useful for a stack.
>
Could you explain what those changes would be?
I obviously haven't implemented such a container. But I imagine the most
obvious implementation would be as a linked list of data blocks that
contain each segment. Each block has the linked list pointer(s), probably a
size/capacity pair, and then the actual storage for that block's elements.
In order to perform forward iteration, all you would need is the ability to
go from one block to the next, which the linked list provides
The only thing I can imagine that would cause any kind of change is if your
linked list of blocks is a *singly*-linked list. That is, the head block is
the most recent block. This would naturally require the segmented_stack
class itself to store two pointers in the linked list: one to the true head
(in terms of allocations) and one to the head that contains the actual head
element in the stack. These may be different, and since you can only
iterate down the stack, your object would need to be able to jump from the
back to the front.
In which case... just reverse the meaning of the sequence. Rather than
pushing and popping to the back, you're pushing and popping from the *front*.
Thus, `begin` would return the most recently inserted element, while `end`
would be just after the last element. And therefore, the only thing you
would need that you don't have is a pointer to the last block.
Which would hardly be a burden performance-wise.
--
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/49f8066e-ef87-48ab-aa34-d334a51125b8%40isocpp.org.
------=_Part_4952_697899315.1467942352031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Ben=
tley wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 5/07/2016 2:26 p=
..m., Ren Industries wrote:
<br>=C2=A0> But...a container /must /include iterators. The very concept=
of a
<br>=C2=A0> container /requires iteration./
<br>=C2=A0> Why would you ridicule someone for pointing out that which i=
s true?
<br>
<br>Please point me to the technical specification that points this out.<br=
></blockquote><div><br><a href=3D"http://wg21.link/N4852">N4852</a>(PDF), [=
container.requirements.general], Table 103.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">As for the ridicule part, well, why would you a=
llow him to ridicule me=20
<br>in the first place?<br></blockquote><div><br>1: He doesn't control =
what other people do.<br><br>2: I didn't ridicule you.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
> At least one problem here is important to anyone who understands the
<br>> subject. That is, you claim you have provided something to be the
<br>> underlying "container" of `std::stack`, but it actually =
contradicts the
<br>> meaning of "container" by definition in current standard=
, since your
<br>> "container" does not meet the container requirements (e.=
g. well-formed
<br>> expressions in Table 103) and it is not hidden from public interfa=
ce of
<br>> `std::stack`, so code like
<br>> `std::stack<T>::container_<wbr>type::iterator_type` would br=
eak. (Also note
<br>> [container.adaptors.general]/1 specifies the copy of container in
<br>> initialization, which may be implemented involving iterators.) Thi=
s is a
<br>> bug more obvious than any ABI issue (which is merely a QoI problem
<br>> rather than introducing defect into the standard), until some
<br>> modification of [container.adaptors] is included in the proposed
<br>> specification.
<br>
<br>Okay, that makes more sense, but which version of the standard are you=
=20
<br>looking at? Table 103 gives me unordered associative container data in=
=20
<br>n4296. Also, are there any ways to introduce this class without having=
=20
<br>to include functionality that is not required ie. iterators?</blockquot=
e><div><br>Sure. Step 1 in that is to not call it a container.<br><br>Step =
2 is to <i>prove</i> (perhaps by detailing the particulars of your implemen=
tation) that support for generalized container functionality would <i>requi=
re</i> degrading the performance of the object in its natural environment.<=
br><br>My point here is that it's not something you should leave unaddr=
essed; it's very much an "elephant in the room" for this type=
.. People will wonder why it's not a full-fledged container. And as I po=
inted out before, there are use cases which could benefit from this type=
9;s allocation and iterator invalidation pattern with more generalized cont=
ainer functionality.<br><br>Step 3: propose a change of `std::stack`'s =
requirements. Right now, it requires that the type be a "sequence cont=
ainer". But that's unnecessary. All it really needs is a type whic=
h is copyable and supports `back`, `push/emplace_back`, `size`, `empty`, an=
d `pop_back`. Iterator support and other container features are unnecessary=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As making=20
<br>the modifications to include this functionality will, in fact (I did=20
<br>write the damn thing), force changes that will decrease performance=20
<br>without adding anything useful for a stack.<br></blockquote><div><br>Co=
uld you explain what those changes would be?<br><br>I obviously haven't=
implemented such a container. But I imagine the most obvious implementatio=
n would be as a linked list of data blocks that contain each segment. Each =
block has the linked list pointer(s), probably a size/capacity pair, and th=
en the actual storage for that block's elements.<br><br>In order to per=
form forward iteration, all you would need is the ability to go from one bl=
ock to the next, which the linked list provides<br><br>The only thing I can=
imagine that would cause any kind of change is if your linked list of bloc=
ks is a <i>singly</i>-linked list. That is, the head block is the most rece=
nt block. This would naturally require the segmented_stack class itself to =
store two pointers in the linked list: one to the true head (in terms of al=
locations) and one to the head that contains the actual head element in the=
stack. These may be different, and since you can only iterate down the sta=
ck, your object would need to be able to jump from the back to the front.<b=
r><br>In which case... just reverse the meaning of the sequence. Rather tha=
n pushing and popping to the back, you're pushing and popping from the =
<i>front</i>. Thus, `begin` would return the most recently inserted element=
, while `end` would be just after the last element. And therefore, the only=
thing you would need that you don't have is a pointer to the last bloc=
k.<br><br>Which would hardly be a burden performance-wise.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/49f8066e-ef87-48ab-aa34-d334a51125b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49f8066e-ef87-48ab-aa34-d334a51125b8=
%40isocpp.org</a>.<br />
------=_Part_4952_697899315.1467942352031--
------=_Part_4951_1862050289.1467942352031--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 7 Jul 2016 18:50:32 -0700 (PDT)
Raw View
------=_Part_4588_1724665606.1467942632245
Content-Type: multipart/alternative;
boundary="----=_Part_4589_1219843249.1467942632245"
------=_Part_4589_1219843249.1467942632245
Content-Type: text/plain; charset=UTF-8
On Wednesday, July 6, 2016 at 7:22:55 PM UTC-4, T. C. wrote:
>
>
> On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:
>
>> Removal from a particular point to the end would never invalidate
>> iterators before that point, unlike a `deque`, where iterators are
>> invalidated anytime internal removal happens.
>>
>
> If an erase operation erases either the first or the last element of the
> deque, then iterators to elements not erased are unaffected - even if it
> also erases other elements. See [deque.modifiers]/4.
>
That's why I meant by "*internal* removal". The front and the back are at
the edges of the sequence and thus not be considered internal.
--
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/162782cc-2463-44c0-ae94-7a7f07ab9ea1%40isocpp.org.
------=_Part_4589_1219843249.1467942632245
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 6, 2016 at 7:22:55 PM UTC-4, T.=
C. 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"><br=
>On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:<div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Removal from a pa=
rticular point to the end would never invalidate iterators before that poin=
t, unlike a `deque`, where iterators are invalidated anytime internal remov=
al happens.</div></div></blockquote><div><br></div><div>If an erase operati=
on erases either the first or the last element of the deque, then iterators=
to elements not erased are unaffected - even if it also erases other eleme=
nts. See [deque.modifiers]/4.</div></div></div></blockquote><div><br>That&#=
39;s why I meant by "<i>internal</i> removal". The front and the =
back are at the edges of the sequence and thus not be considered internal.<=
/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/162782cc-2463-44c0-ae94-7a7f07ab9ea1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/162782cc-2463-44c0-ae94-7a7f07ab9ea1=
%40isocpp.org</a>.<br />
------=_Part_4589_1219843249.1467942632245--
------=_Part_4588_1724665606.1467942632245--
.
Author: "T. C." <rs2740@gmail.com>
Date: Thu, 7 Jul 2016 19:34:42 -0700 (PDT)
Raw View
------=_Part_7570_575419215.1467945282525
Content-Type: multipart/alternative;
boundary="----=_Part_7571_286290795.1467945282525"
------=_Part_7571_286290795.1467945282525
Content-Type: text/plain; charset=UTF-8
On Thursday, July 7, 2016 at 9:50:32 PM UTC-4, Nicol Bolas wrote:
>
>
>
> On Wednesday, July 6, 2016 at 7:22:55 PM UTC-4, T. C. wrote:
>>
>>
>> On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:
>>
>>> Removal from a particular point to the end would never invalidate
>>> iterators before that point, unlike a `deque`, where iterators are
>>> invalidated anytime internal removal happens.
>>>
>>
>> If an erase operation erases either the first or the last element of the
>> deque, then iterators to elements not erased are unaffected - even if it
>> also erases other elements. See [deque.modifiers]/4.
>>
>
> That's why I meant by "*internal* removal". The front and the back are at
> the edges of the sequence and thus not be considered internal.
>
I must have misunderstood what you meant by "from a particular point to the
end" then. I thought you meant erase(particular_point, end()) - but perhaps
you just mean it has vector-like invalidation semantics?
--
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/8759252b-cde0-4bc4-a1f5-7d209ce5069d%40isocpp.org.
------=_Part_7571_286290795.1467945282525
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 7, 2016 at 9:50:32 PM UTC-4, Nic=
ol Bolas 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=
"><br><br>On Wednesday, July 6, 2016 at 7:22:55 PM UTC-4, T. C. wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Tuesday, July 5,=
2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:<div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Removal from a particular point to th=
e end would never invalidate iterators before that point, unlike a `deque`,=
where iterators are invalidated anytime internal removal happens.</div></d=
iv></blockquote><div><br></div><div>If an erase operation erases either the=
first or the last element of the deque, then iterators to elements not era=
sed are unaffected - even if it also erases other elements. See [deque.modi=
fiers]/4.</div></div></div></blockquote><div><br>That's why I meant by =
"<i>internal</i> removal". The front and the back are at the edge=
s of the sequence and thus not be considered internal.</div></div></blockqu=
ote><div><br></div><div>I must have misunderstood what you meant by "f=
rom a particular point to the end" then. I thought you meant erase(par=
ticular_point, end()) - but perhaps you just mean it has vector-like invali=
dation semantics?</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/8759252b-cde0-4bc4-a1f5-7d209ce5069d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8759252b-cde0-4bc4-a1f5-7d209ce5069d=
%40isocpp.org</a>.<br />
------=_Part_7571_286290795.1467945282525--
------=_Part_7570_575419215.1467945282525--
.
Author: "T. C." <rs2740@gmail.com>
Date: Thu, 7 Jul 2016 19:38:16 -0700 (PDT)
Raw View
------=_Part_7445_1324998546.1467945496078
Content-Type: multipart/alternative;
boundary="----=_Part_7446_1826321807.1467945496079"
------=_Part_7446_1826321807.1467945496079
Content-Type: text/plain; charset=UTF-8
On Thursday, July 7, 2016 at 9:45:52 PM UTC-4, Nicol Bolas wrote:
>
> On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:
>>
>> On 5/07/2016 2:26 p.m., Ren Industries wrote:
>> > But...a container /must /include iterators. The very concept of a
>> > container /requires iteration./
>> > Why would you ridicule someone for pointing out that which is true?
>>
>> Please point me to the technical specification that points this out.
>>
>
> N4852
> <http://www.google.com/url?q=http%3A%2F%2Fwg21.link%2FN4852&sa=D&sntz=1&usg=AFQjCNE-8nGAOEyO0mB6_peswpD3jGKYOg>(PDF),
> [container.requirements.general], Table 103.
>
N4582 <http://wg21.link/N4582>, you mean. With the new numbering system, we
won't be seeing N4852 in a while...
--
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/b6eb0fee-5072-473c-b16d-a3193a53ad13%40isocpp.org.
------=_Part_7446_1826321807.1467945496079
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 7, 2016 at 9:45:52 PM UTC-4, Nic=
ol Bolas 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=
">On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On 5/07/2016 2:26 p.m., Ren Industries =
wrote:
<br>=C2=A0> But...a container /must /include iterators. The very concept=
of a
<br>=C2=A0> container /requires iteration./
<br>=C2=A0> Why would you ridicule someone for pointing out that which i=
s true?
<br>
<br>Please point me to the technical specification that points this out.<br=
></blockquote><div><br><a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%=
2Fwg21.link%2FN4852&sa=3DD&sntz=3D1&usg=3DAFQjCNE-8nGAOEyO0mB6_=
peswpD3jGKYOg" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FN4852\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-8nGAOEyO0mB6_peswpD3jGKYOg';return=
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwg21.link%2FN4852\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-8nGAOEyO0m=
B6_peswpD3jGKYOg';return true;">N4852</a>(PDF), [container.requirements=
..<wbr>general], Table 103.<br></div></div></blockquote><div><br></div><div>=
<a href=3D"http://wg21.link/N4582">N4582</a>, you mean. With the new number=
ing system, we won't be seeing N4852 in a while...</div><div>=C2=A0</di=
v></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/b6eb0fee-5072-473c-b16d-a3193a53ad13%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6eb0fee-5072-473c-b16d-a3193a53ad13=
%40isocpp.org</a>.<br />
------=_Part_7446_1826321807.1467945496079--
------=_Part_7445_1324998546.1467945496078--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 7 Jul 2016 23:16:51 -0400
Raw View
--089e013d1c64ec4c4d0537173bee
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 7, 2016 at 9:45 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:
>>
>> On 5/07/2016 2:26 p.m., Ren Industries wrote:
>> > But...a container /must /include iterators. The very concept of a
>> > container /requires iteration./
>> > Why would you ridicule someone for pointing out that which is true?
>>
>> Please point me to the technical specification that points this out.
>>
>
> N4852 <http://wg21.link/N4852>(PDF), [container.requirements.general],
> Table 103.
>
> As for the ridicule part, well, why would you allow him to ridicule me
>> in the first place?
>>
>
> 1: He doesn't control what other people do.
>
> 2: I didn't ridicule you.
>
>
Let me try to be an impartial observer (if that is ever really possible for
a human being).
I don't think ridicule would describe it. But I would say the tone was
somehow overly negative. I'm not quite sure what the right description
would be. Maybe 'harsh'?
Overall, to everyone on this list,
I - and many others I've spoken with (mostly on the committee) - have been
finding this list gets too critical/harsh/something (again, loss of words)
too quickly. Let's nurture ideas. That's the point of the list. Yes, we
need to break them down and dissect them in order to understand and improve
them, but we don't need to destroy/eviscerate them.
I would like, in the most respectful way I can, to call out you, Nicol, in
particular as someone that I find heavy handed in this direction. Whether
intentional or not. Which is often a problem with the email medium. Lots
of intention and nuance is lost.
But it isn't just one person. We all need to be mindful of this. I may
very well come off the wrong way at times - I know that sometimes my
replies are short and "to the point" (as programmers, I find we tend to
talk in short facts that "real" people often find curt to the point of
rude). It is easy to have your replies read the wrong way if we aren't
careful.
So please, everyone, let's try to be a bit more graceful. We don't need
flowery "my most honoured and respected friend, I find your proposal...",
but "I think that"... "maybe"... "this might cause a problem here"... go
along way towards taking the edge of absolute statements which, only
slightly exaggerated, sound like that quote: "At no point in *your*
rambling, incoherent response were you even close to anything that could be
considered a rational thought. Everyone in this room is now dumber for
having listened to it. I award you no points, *and may God have mercy on
your soul*.".
Don't be afraid to point out the good stuff while also mentioning the
things you disagree with. It helps. We are all only human.
Thank you.
Tony
--
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/CAOHCbit9GQ7LhM_YQXQ4TAD471-0TChjnFHLjsgfPt65qcJ5CA%40mail.gmail.com.
--089e013d1c64ec4c4d0537173bee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jul 7, 2016 at 9:45 PM, Nicol Bolas <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><span class=3D"">On Thursday, July 7, 2016 at 7:28:35 PM UTC-=
4, Matthew Bentley wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
On 5/07/2016 2:26 p.m., Ren Industries wrote:
<br>=C2=A0> But...a container /must /include iterators. The very concept=
of a
<br>=C2=A0> container /requires iteration./
<br>=C2=A0> Why would you ridicule someone for pointing out that which i=
s true?
<br>
<br>Please point me to the technical specification that points this out.<br=
></blockquote></span><div><br><a href=3D"http://wg21.link/N4852" target=3D"=
_blank">N4852</a>(PDF), [container.requirements.general], Table 103.<br><br=
></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A=
s for the ridicule part, well, why would you allow him to ridicule me=20
<br>in the first place?<br></blockquote></span><div><br>1: He doesn't c=
ontrol what other people do.<br><br>2: I didn't ridicule you.<br>=C2=A0=
</div></div></blockquote><div><br></div><div>Let me try to be an impartial =
observer (if that is ever really possible for a human being).<br><br>I don&=
#39;t think ridicule would describe it.=C2=A0 But I would say the tone was =
somehow overly negative. I'm not quite sure what the right description =
would be.=C2=A0 Maybe 'harsh'?<br><br></div><div>Overall, to everyo=
ne on this list,<br><br>I - and many others I've spoken with (mostly on=
the committee) - have been finding this list gets too critical/harsh/somet=
hing (again, loss of words) too quickly.=C2=A0 Let's nurture ideas.=C2=
=A0 That's the point of the list.=C2=A0 Yes, we need to break them down=
and dissect them in order to understand and improve them, but we don't=
need to destroy/eviscerate them.<br><br></div><div>I would like, in the mo=
st respectful way I can, to call out you, Nicol, in particular as someone t=
hat I find heavy handed in this direction.=C2=A0 Whether intentional or not=
..=C2=A0 Which is often a problem with the email medium.=C2=A0 Lots of inten=
tion and nuance is lost.<br><br></div><div>But it isn't just one person=
..=C2=A0 We all need to be mindful of this.=C2=A0 I may very well come off t=
he wrong way at times - I know that sometimes my replies are short and &quo=
t;to the point" (as programmers, I find we tend to talk in short facts=
that "real" people often find curt to the point of rude).=C2=A0 =
It is easy to have your replies read the wrong way if we aren't careful=
..<br><br></div><div>So please, everyone, let's try to be a bit more gra=
ceful.=C2=A0 We don't need flowery "my most honoured and respected=
friend, I find your proposal...", but "I think that"... &qu=
ot;maybe"... "this might cause a problem here"...=C2=A0 go a=
long way towards taking the edge of absolute statements which, only slightl=
y exaggerated, sound like that quote: "<span class=3D"">At no point in=
<em>your</em> rambling,=20
incoherent response were you even close to anything that could be=20
considered a rational thought. Everyone in this room is now dumber for=20
having listened to it. I award you no points, <em>and may God have mercy on=
your soul</em>.</span>".<br><br>Don't be afraid to point out the =
good stuff while also mentioning the things you disagree with.=C2=A0 It hel=
ps.=C2=A0 We are all only human.<br><br></div><div>Thank you.<br></div><div=
>Tony<br><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/CAOHCbit9GQ7LhM_YQXQ4TAD471-0TChjnFHL=
jsgfPt65qcJ5CA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbit9GQ7LhM_Y=
QXQ4TAD471-0TChjnFHLjsgfPt65qcJ5CA%40mail.gmail.com</a>.<br />
--089e013d1c64ec4c4d0537173bee--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jul 2016 06:30:38 -0700 (PDT)
Raw View
------=_Part_38_484150601.1467984639039
Content-Type: multipart/alternative;
boundary="----=_Part_39_1831364945.1467984639039"
------=_Part_39_1831364945.1467984639039
Content-Type: text/plain; charset=UTF-8
On Thursday, July 7, 2016 at 10:34:42 PM UTC-4, T. C. wrote:
>
>
>
> On Thursday, July 7, 2016 at 9:50:32 PM UTC-4, Nicol Bolas wrote:
>>
>>
>>
>> On Wednesday, July 6, 2016 at 7:22:55 PM UTC-4, T. C. wrote:
>>>
>>>
>>> On Tuesday, July 5, 2016 at 10:45:57 AM UTC-4, Nicol Bolas wrote:
>>>
>>>> Removal from a particular point to the end would never invalidate
>>>> iterators before that point, unlike a `deque`, where iterators are
>>>> invalidated anytime internal removal happens.
>>>>
>>>
>>> If an erase operation erases either the first or the last element of the
>>> deque, then iterators to elements not erased are unaffected - even if it
>>> also erases other elements. See [deque.modifiers]/4.
>>>
>>
>> That's why I meant by "*internal* removal". The front and the back are
>> at the edges of the sequence and thus not be considered internal.
>>
>
> I must have misunderstood what you meant by "from a particular point to
> the end" then. I thought you meant erase(particular_point, end()) - but
> perhaps you just mean it has vector-like invalidation semantics?
>
Yes, that's what I was going for.
--
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/bc67c849-d958-439a-a608-e5a57d2aa863%40isocpp.org.
------=_Part_39_1831364945.1467984639039
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 7, 2016 at 10:34:42 PM UTC-4, T.=
C. 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"><br=
><br>On Thursday, July 7, 2016 at 9:50:32 PM UTC-4, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, J=
uly 6, 2016 at 7:22:55 PM UTC-4, T. C. wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br>On Tuesday, July 5, 2016 at 10:45:57 AM UTC-=
4, Nicol Bolas wrote:<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>Removal from a particular point to the end would never invali=
date iterators before that point, unlike a `deque`, where iterators are inv=
alidated anytime internal removal happens.</div></div></blockquote><div><br=
></div><div>If an erase operation erases either the first or the last eleme=
nt of the deque, then iterators to elements not erased are unaffected - eve=
n if it also erases other elements. See [deque.modifiers]/4.</div></div></d=
iv></blockquote><div><br>That's why I meant by "<i>internal</i> re=
moval". The front and the back are at the edges of the sequence and th=
us not be considered internal.</div></div></blockquote><div><br></div><div>=
I must have misunderstood what you meant by "from a particular point t=
o the end" then. I thought you meant erase(particular_point, end()) - =
but perhaps you just mean it has vector-like invalidation semantics?</div><=
/div></blockquote><div><br>Yes, that's what I was going for. <br></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bc67c849-d958-439a-a608-e5a57d2aa863%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bc67c849-d958-439a-a608-e5a57d2aa863=
%40isocpp.org</a>.<br />
------=_Part_39_1831364945.1467984639039--
------=_Part_38_484150601.1467984639039--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jul 2016 06:36:58 -0700 (PDT)
Raw View
------=_Part_1086_1773737112.1467985018272
Content-Type: multipart/alternative;
boundary="----=_Part_1087_835683291.1467985018272"
------=_Part_1087_835683291.1467985018272
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 4, 2016 at 8:13:43 PM UTC-4, Tony V E wrote:
>
> One thing would be to see how good you could get the performance of deque=
=20
> to be. Maybe it can be made somewhat better without chang=E2=80=8Eing it=
's=20
> interface or guarantees?=20
>
I've figured out what it is about `deque` that makes implementing it as a=
=20
"segmented stack" not workable.
It's the requirement that its iterators be random-access.
What makes segmented stack work is that the segments get *bigger* as more=
=20
values are added to the end. And therefore, as the stack increases in size,=
=20
you have a lower frequency of memory allocations, while `deque`'s frequency=
=20
remains the same. But `deque`'s frequency being constant is exactly what=20
makes it possible to implement `advance` in something like constant time.=
=20
Without a constant block size, you can't necessarily know exactly how far=
=20
to advance the iterator.
So I don't think it's possible to use this as a different back-end for=20
`deque`.
--=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/5519cfb1-f41a-4406-82c9-088d77585e0f%40isocpp.or=
g.
------=_Part_1087_835683291.1467985018272
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 4, 2016 at 8:13:43 PM UTC-4, Tony V E wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"background-col=
or:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
<div sty=
le=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',=
sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)">One thing would be to see how good you could get the =
performance of deque to be. Maybe it can be made somewhat =C2=A0better with=
out chang=E2=80=8Eing it's interface or guarantees?=C2=A0</div></div></=
blockquote><div><br>I've figured out what it is about `deque` that make=
s implementing it as a "segmented stack" not workable.<br><br>It&=
#39;s the requirement that its iterators be random-access.<br><br>What make=
s segmented stack work is that the segments get <i>bigger</i> as more value=
s are added to the end. And therefore, as the stack increases in size, you =
have a lower frequency of memory allocations, while `deque`'s frequency=
remains the same. But `deque`'s frequency being constant is exactly wh=
at makes it possible to implement `advance` in something like constant time=
.. Without a constant block size, you can't necessarily know exactly how=
far to advance the iterator.<br><br>So I don't think it's possible=
to use this as a different back-end for `deque`.</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/5519cfb1-f41a-4406-82c9-088d77585e0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5519cfb1-f41a-4406-82c9-088d77585e0f=
%40isocpp.org</a>.<br />
------=_Part_1087_835683291.1467985018272--
------=_Part_1086_1773737112.1467985018272--
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Fri, 8 Jul 2016 17:54:23 +0200
Raw View
I believe that as long as you know the way to extend the size in
advance, nothing prohibits it from having random access in linear
time. Say you double the allocated size each time, having
1,2,4,8,....2**n elements in each bucket. You can get to the correct
bucket in 0(1) time quite easily if only you know the "index" of the
current iterator (which can be stored within the iterator without any
problems).
/Peter
On Fri, Jul 8, 2016 at 3:36 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, July 4, 2016 at 8:13:43 PM UTC-4, Tony V E wrote:
>>
>> One thing would be to see how good you could get the performance of dequ=
e
>> to be. Maybe it can be made somewhat better without chang=E2=80=8Eing i=
t's
>> interface or guarantees?
>
>
> I've figured out what it is about `deque` that makes implementing it as a
> "segmented stack" not workable.
>
> It's the requirement that its iterators be random-access.
>
> What makes segmented stack work is that the segments get bigger as more
> values are added to the end. And therefore, as the stack increases in siz=
e,
> you have a lower frequency of memory allocations, while `deque`'s frequen=
cy
> remains the same. But `deque`'s frequency being constant is exactly what
> makes it possible to implement `advance` in something like constant time.
> Without a constant block size, you can't necessarily know exactly how far=
to
> advance the iterator.
>
> So I don't think it's possible to use this as a different back-end for
> `deque`.
>
> --
> 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/5519cfb1-f41=
a-4406-82c9-088d77585e0f%40isocpp.org.
--=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/CANPtkny3wh6JZdvZohbsL%3Dr%3DoXTKWtTGaYsAnME%3Dr=
Vjyw7F99g%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jul 2016 09:35:34 -0700 (PDT)
Raw View
------=_Part_170_1229278026.1467995734121
Content-Type: multipart/alternative;
boundary="----=_Part_171_12732714.1467995734121"
------=_Part_171_12732714.1467995734121
Content-Type: text/plain; charset=UTF-8
On Friday, July 8, 2016 at 11:54:26 AM UTC-4, Peter Koch Larsen wrote:
>
> I believe that as long as you know the way to extend the size in
> advance, nothing prohibits it from having random access in linear
> time.
Are random access iterators allowed to have `i + n` act in linear time?
Granted, I know that `deque`'s iterators kinda fudge the rules here.
Say you double the allocated size each time, having
> 1,2,4,8,....2**n elements in each bucket. You can get to the correct
> bucket in 0(1) time quite easily if only you know the "index" of the
> current iterator (which can be stored within the iterator without any
> problems).
Also, I just remembered something: deque is double-ended; pushing to the
front is no different from pushing to the back. So a segmented stack could
never be the implementation for a deque. After all, segment sizes are
supposed to decrease towards the front, not increase.
You could try to develop some kind of segmented deque, which increases the
size of segments in either direction. But that makes random access much
harder, since a mere index is not enough to know whether previous segments
are larger or smaller.
--
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/1950cfcc-ffc1-43e6-864c-66b756f61320%40isocpp.org.
------=_Part_171_12732714.1467995734121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 8, 2016 at 11:54:26 AM UTC-4, Peter Koch L=
arsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> I believe that as=
long as you know the way to extend the size in
<br>advance, nothing prohibits it from having random access in linear
<br>time.</blockquote><div><br>Are random access iterators allowed to have =
`i + n` act in linear time? Granted, I know that `deque`'s iterators ki=
nda fudge the rules here.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"> Say you double the allocated size each time, having
<br>1,2,4,8,....2**n elements in each bucket. You can get to the correct
<br>bucket in 0(1) time quite easily if only you know the "index"=
of the
<br>current iterator (which can be stored within the iterator without any
<br>problems).</blockquote><br>Also, I just remembered something: deque is =
double-ended; pushing to the front is no different from pushing to the back=
.. So a segmented stack could never be the implementation for a deque. After=
all, segment sizes are supposed to decrease towards the front, not increas=
e.<br><br>You could try to develop some kind of segmented deque, which incr=
eases the size of segments in either direction. But that makes random acces=
s much harder, since a mere index is not enough to know whether previous se=
gments are larger or smaller.<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/1950cfcc-ffc1-43e6-864c-66b756f61320%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1950cfcc-ffc1-43e6-864c-66b756f61320=
%40isocpp.org</a>.<br />
------=_Part_171_12732714.1467995734121--
------=_Part_170_1229278026.1467995734121--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 8 Jul 2016 11:44:58 -0500
Raw View
--001a11408d9c4906420537228814
Content-Type: text/plain; charset=UTF-8
On 8 July 2016 at 11:35, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, July 8, 2016 at 11:54:26 AM UTC-4, Peter Koch Larsen wrote:
>>
>> I believe that as long as you know the way to extend the size in
>> advance, nothing prohibits it from having random access in linear
>> time.
>
>
> Are random access iterators allowed to have `i + n` act in linear time?
>
No. It must be constant time.
> Granted, I know that `deque`'s iterators kinda fudge the rules here.
>
They do? Could you elaborate?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BP0ftm%2BmHQeNawLUOqGXrg2GJE1X8%2BYwE2q%2BH_xLHB18w%40mail.gmail.com.
--001a11408d9c4906420537228814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 8 July 2016 at 11:35, Nicol Bolas <span dir=3D"ltr"><=
;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.c=
om</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, Jul=
y 8, 2016 at 11:54:26 AM UTC-4, Peter Koch Larsen wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"> I believe that as long as you know the way to exten=
d the size in
<br>advance, nothing prohibits it from having random access in linear
<br>time.</blockquote></span><div><br>Are random access iterators allowed t=
o have `i + n` act in linear time?</div></div></blockquote><div><br></div><=
div>No.=C2=A0 It must be constant time.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div> Granted, I know that `deque`'s=
iterators kinda fudge the rules here.<br></div></div></blockquote><div><br=
></div><div>They do?=C2=A0 Could you elaborate?</div><div>--=C2=A0<br></div=
></div><div data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div d=
ir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>> =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" tar=
get=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP0ftm%2BmHQeNawLUOqGXrg2GJE1=
X8%2BYwE2q%2BH_xLHB18w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
P0ftm%2BmHQeNawLUOqGXrg2GJE1X8%2BYwE2q%2BH_xLHB18w%40mail.gmail.com</a>.<br=
/>
--001a11408d9c4906420537228814--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Fri, 8 Jul 2016 18:31:25 -0300
Raw View
Hi Matthew,
2016-07-04 1:27 GMT-03:00 Matthew Bentley <mattreecebentley@gmail.com>:
> Hi Guys,
> attached is a proposal to introduce the std::segmented_stack container to
> the standard library, and subsequently change the default adapted container
> of std::stack to std::segmented_stack.
>
> std::segmented_stack is a type of stack that performs better than any
> standard library container (across compilers and libraries) in the context
> of a stack.
It seems to me that your speed-up may be related to a better cache use
and not to the data structure itself. Deque allocates small chunks and
you improved this by using a growth factor of two. Actually your
*chained-group memory allocation pattern* is a linked list of nodes
with different sizes, so I do not see why you cannot build it up in an
allocator instead of binding the stack implementation (and users) to
your specific growth strategy. That would be more flexible.
>Benchmarks are included in the reference section of the
> proposal.
I see the following issues with your benchmarks
1) The times scales are pretty short. You are using microseconds
(0,000001) as unit and your range of time intervals in many of the
graphs is less than 0.1 seconds. Seems too short.
2) The range of the X axis (number of elements) is too big as a
result the graphs overlap for in-between values and I can only see a
difference for big n. Except for large structs, but what is large and
small struct, I missed that in the text.
Marcelo
--
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/CAPGXEnFe%3DyTKY3U7ovr87LU2%2BtjuRKxUGw-JFe7X%3DvuuhxeLCg%40mail.gmail.com.
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Sat, 09 Jul 2016 11:12:51 +1200
Raw View
> Let me try to be an impartial observer (if that is ever really possible
> for a human being).
>
> I don't think ridicule would describe it. But I would say the tone was
> somehow overly negative. I'm not quite sure what the right description
> would be. Maybe 'harsh'?
>
> Overall, to everyone on this list,
>
> I - and many others I've spoken with (mostly on the committee) - have
> been finding this list gets too critical/harsh/something (again, loss of
> words) too quickly. Let's nurture ideas. That's the point of the
> list. Yes, we need to break them down and dissect them in order to
> understand and improve them, but we don't need to destroy/eviscerate them.
>
> I would like, in the most respectful way I can, to call out you, Nicol,
> in particular as someone that I find heavy handed in this direction.
> Whether intentional or not. Which is often a problem with the email
> medium. Lots of intention and nuance is lost.
>
> But it isn't just one person. We all need to be mindful of this. I may
> very well come off the wrong way at times - I know that sometimes my
> replies are short and "to the point" (as programmers, I find we tend to
> talk in short facts that "real" people often find curt to the point of
> rude). It is easy to have your replies read the wrong way if we aren't
> careful.
>
> So please, everyone, let's try to be a bit more graceful. We don't need
> flowery "my most honoured and respected friend, I find your
> proposal...", but "I think that"... "maybe"... "this might cause a
> problem here"... go along way towards taking the edge of absolute
> statements which, only slightly exaggerated, sound like that quote: "At
> no point in /your/ rambling, incoherent response were you even close to
> anything that could be considered a rational thought. Everyone in this
> room is now dumber for having listened to it. I award you no points,
> /and may God have mercy on your soul/.".
>
> Don't be afraid to point out the good stuff while also mentioning the
> things you disagree with. It helps. We are all only human.
I think this is a good summary. I apologise for whatever heartache (or
similar appropriate word) I may've caused, but I certainly didn't expect
to be set upon once posting. That's a bit more harsh than what I was
expecting.
--
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/57803373.3060209%40gmail.com.
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Sat, 09 Jul 2016 11:13:02 +1200
Raw View
> It seems to me that your speed-up may be related to a better cache use
> and not to the data structure itself. Deque allocates small chunks and
> you improved this by using a growth factor of two. Actually your
Only benchmarking would prove/disprove that, and I don't have
time/initiative to do write an alternative container.
> *chained-group memory allocation pattern* is a linked list of nodes
> with different sizes, so I do not see why you cannot build it up in an
> allocator instead of binding the stack implementation (and users) to
> your specific growth strategy. That would be more flexible.
I'm not sure from your phrasing whether you mean you want me to provide
flexible growth factors (doable) or use a different allocation pattern
(don't have time) or both.
> I see the following issues with your benchmarks
>
> 1) The times scales are pretty short. You are using microseconds
> (0,000001) as unit and your range of time intervals in many of the
> graphs is less than 0.1 seconds. Seems too short.
Those are the times. If you examine the paragraphs at the top of the
benchmarks you'll find they're averaged across multiple runs, and the
counter doesn't measure each run, it measures all runs and divides by
the number of runs.
> 2) The range of the X axis (number of elements) is too big as a
> result the graphs overlap for in-between values and I can only see a
> difference for big n. Except for large structs, but what is large and
> small struct, I missed that in the text.
I'm not sure what you're proposing I do differently -
surely the logarithmic scale graphics display what you need to see at
the lower levels of N?
--
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/5780337E.30809%40gmail.com.
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Sat, 9 Jul 2016 06:10:22 +0200
Raw View
On Fri, Jul 8, 2016 at 6:35 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, July 8, 2016 at 11:54:26 AM UTC-4, Peter Koch Larsen wrote:
>>
>> I believe that as long as you know the way to extend the size in
>> advance, nothing prohibits it from having random access in linear
>> time.
>
>
> Are random access iterators allowed to have `i + n` act in linear time?
Perhaps I have fatally misunderstood something. Advance should be O(1) always,
but I do not see anything that prevents it from being so.
I have not looked at the code behind this proposal, so this is not a
claim that the
proposal does have an O(1) advance.
> Granted, I know that `deque`'s iterators kinda fudge the rules here.
>
>> Say you double the allocated size each time, having
>> 1,2,4,8,....2**n elements in each bucket. You can get to the correct
>> bucket in 0(1) time quite easily if only you know the "index" of the
>> current iterator (which can be stored within the iterator without any
>> problems).
>
--
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/CANPtknwvSARpsbi7Jy_U2e4bnAVoR9RNO%2BsmZs-Kgu7KMi0WXw%40mail.gmail.com.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sat, 9 Jul 2016 11:55:26 -0300
Raw View
--001a114b17880727f40537351c0b
Content-Type: text/plain; charset=UTF-8
2016-07-08 20:13 GMT-03:00 Matt Bentley <mattreecebentley@gmail.com>:
>> It seems to me that your speed-up may be related to a better cache use
>> and not to the data structure itself. Deque allocates small chunks and
>> you improved this by using a growth factor of two. Actually your
>
>
> Only benchmarking would prove/disprove that, and I don't have
> time/initiative to do write an alternative container.
>
>
>> *chained-group memory allocation pattern* is a linked list of nodes
>> with different sizes, so I do not see why you cannot build it up in an
>> allocator instead of binding the stack implementation (and users) to
>> your specific growth strategy. That would be more flexible.
>
>
> I'm not sure from your phrasing whether you mean you want me to provide
> flexible growth factors (doable) or use a different allocation pattern
> (don't have time) or both.
My point is that the current std::stack interface already allows you to
achieve these speed-ups by providing a deque with the growth
characteristics you wish (and lack of random access, which is not important
here). But you merged the two (std::stack + deque) in a single and less
flexible entity.
Marcelo
--
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/CAPGXEnH4oUZRcwOjgXgmq4iEnr9EKULwQMerioMYkaJTcRSvqA%40mail.gmail.com.
--001a114b17880727f40537351c0b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
2016-07-08 20:13 GMT-03:00 Matt Bentley <<a href=3D"mailto:mattreecebent=
ley@gmail.com">mattreecebentley@gmail.com</a>>:<br>
>> It seems to me that your speed-up may be related to a better cache=
use<br>
>> and not to the data structure itself. Deque allocates small chunks=
and<br>
>> you improved this by using a growth factor of two. Actually your<b=
r>
><br>
><br>
> Only benchmarking would prove/disprove that, and I don't have<br>
> time/initiative to do write an alternative container.<br>
><br>
><br>
>> *chained-group memory allocation pattern* is a linked list of node=
s<br>
>> with different sizes, so I do not see why you cannot build it up i=
n an<br>
>> allocator instead of binding the stack implementation (and users) =
to<br>
>> your specific growth strategy. That would be more flexible.<br>
><br>
><br>
> I'm not sure from your phrasing whether you mean you want me to pr=
ovide<br>
> flexible growth factors (doable) or use a different allocation pattern=
<br>
> (don't have time) or both.</p>
<p dir=3D"ltr">My point is that the current std::stack interface already al=
lows you to achieve these speed-ups by providing a deque with the growth ch=
aracteristics you wish (and lack of random access, which is not important h=
ere). But you merged the two (std::stack + deque) in a single and less flex=
ible entity.</p>
<p dir=3D"ltr">Marcelo<br>
</p>
<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/CAPGXEnH4oUZRcwOjgXgmq4iEnr9EKULwQMer=
ioMYkaJTcRSvqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPGXEnH4oUZRcwOj=
gXgmq4iEnr9EKULwQMerioMYkaJTcRSvqA%40mail.gmail.com</a>.<br />
--001a114b17880727f40537351c0b--
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Sun, 10 Jul 2016 10:45:32 +1200
Raw View
> My point is that the current std::stack interface already allows you to
> achieve these speed-ups by providing a deque with the growth
> characteristics you wish (and lack of random access, which is not
> important here). But you merged the two (std::stack + deque) in a single
> and less flexible entity.
After I posted yesterday I realised it was simple to prove/disprove your
theory. I simply re-ran the tests with the min and max group sizes set
to the same amount for plf::stack.
The results for a 2x growth factor vs a couple of fixed-size results are
here (32-element, 128-element, 512-element and 2048-element groups):
http://www.mediafire.com/view/iag72gn0ur90u9c/group_sizes_compared.png
http://www.mediafire.com/view/r1i0q3c2696r5zr/group_sizes_compared_log.png
There is little difference, but a growth factor of 2x makes actual sense
from a usage vs performance perspective, and a fixed size doesn't. So
you're wrong.
BTW, the ability to specify min-max group sizes is not incidental or
replaceable with reserve. I'll fill you in on the details if I'm feeling
up to writing a second draft.
This is as much time as I'm willing to put into this at the moment, so
I'll bid you all good day, for now at least.
--
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/57817E8C.5080804%40gmail.com.
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sun, 10 Jul 2016 03:48:15 -0300
Raw View
2016-07-09 19:45 GMT-03:00 Matt Bentley <mattreecebentley@gmail.com>:
>> My point is that the current std::stack interface already allows you to
>> achieve these speed-ups by providing a deque with the growth
>> characteristics you wish (and lack of random access, which is not
>> important here). But you merged the two (std::stack + deque) in a single
>> and less flexible entity.
>
>
>
> After I posted yesterday I realised it was simple to prove/disprove your
> theory. I simply re-ran the tests with the min and max group sizes set to
> the same amount for plf::stack.
> The results for a 2x growth factor vs a couple of fixed-size results are
> here (32-element, 128-element, 512-element and 2048-element groups):
> http://www.mediafire.com/view/iag72gn0ur90u9c/group_sizes_compared.png
> http://www.mediafire.com/view/r1i0q3c2696r5zr/group_sizes_compared_log.png
>
>
> There is little difference, but a growth factor of 2x makes actual sense
> from a usage vs performance perspective, and a fixed size doesn't. So you're
> wrong.
1) Your proposal leads us to believe that the *chained-group memory
allocation pattern* and the growth factor plays and important role in
the speed-ups. Now you are saying it makes little difference *but
makes actual sense*. Even if it makes sense, it is likely to use much
more memory than usual std::deque implementations.
2) The graphs does show that there is a performance penalty for less
elements (128, 32) in the groups, than for larger number of elements
(2048, 512). Which shows that fragmentation is playing a role.
4) The size of the blocks you are using do not correspond to the
gcc-std::deque you are benchmarking against. See for example comments
on stl_deque.h header in libstdc++
* A @a node has no specific type name as such, but it is referred
* to as @a node in this file. It is a simple array-of-Tp. If Tp
* is very large, there will be one Tp element per node (i.e., an
* @a array of one). For non-huge Tp's, node size is inversely
* related to Tp size: the larger the Tp, the fewer Tp's will fit
* in a node. The goal here is to keep the total size of a node
* relatively small and constant over different Tp's, to improve
* allocator efficiency.
Now we look in the function that calculates the deque node size
#ifndef _GLIBCXX_DEQUE_BUF_SIZE
#define _GLIBCXX_DEQUE_BUF_SIZE 512
#endif
_GLIBCXX_CONSTEXPR inline size_t
__deque_buf_size(size_t __size)
{ return (__size < _GLIBCXX_DEQUE_BUF_SIZE
? size_t(_GLIBCXX_DEQUE_BUF_SIZE / __size) : size_t(1)); }
which means that for larger value_types, where you are observing
speedups, the nodes have only one element (as stated in the quoted
text). That would be a possible reason on why you see the speed-ups.
3) You are saying we should replace the std::stack adaptor with your
container due to performance, but the source of speed-ups is far from
clear. It does not seem to have anything to do with the adaptor itself
but with the underlying container.
4) *I don't have time/initiative to do write an alternative container*
and *I'll fill you in on the details if I'm feeling up
to writing a second draft*
Never asked for this. But it sounds like it is a pain to you to make
the points clear.
Marcelo
--
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/CAPGXEnFxQnXDKy9PToNY4Om0tooscXYgomUxho8vsdOEMNrLHg%40mail.gmail.com.
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Mon, 11 Jul 2016 10:31:13 +1200
Raw View
As I said, I don't have any more time to contribute to this discussion,
so your attempt to draw me back in - based on points which have already
been raised and addressed I might add - is noted and ignored.
> 1) Your proposal leads us to believe that the *chained-group memory
> allocation pattern* and the growth factor plays and important role in
> the speed-ups. Now you are saying it makes little difference *but
> makes actual sense*. Even if it makes sense, it is likely to use much
> more memory than usual std::deque implementations.
>
> 2) The graphs does show that there is a performance penalty for less
> elements (128, 32) in the groups, than for larger number of elements
> (2048, 512). Which shows that fragmentation is playing a role.
>
> 4) The size of the blocks you are using do not correspond to the
> gcc-std::deque you are benchmarking against. See for example comments
> on stl_deque.h header in libstdc++
>
> * A @a node has no specific type name as such, but it is referred
> * to as @a node in this file. It is a simple array-of-Tp. If Tp
> * is very large, there will be one Tp element per node (i.e., an
> * @a array of one). For non-huge Tp's, node size is inversely
> * related to Tp size: the larger the Tp, the fewer Tp's will fit
> * in a node. The goal here is to keep the total size of a node
> * relatively small and constant over different Tp's, to improve
> * allocator efficiency.
>
> Now we look in the function that calculates the deque node size
>
> #ifndef _GLIBCXX_DEQUE_BUF_SIZE
> #define _GLIBCXX_DEQUE_BUF_SIZE 512
> #endif
>
> _GLIBCXX_CONSTEXPR inline size_t
> __deque_buf_size(size_t __size)
> { return (__size < _GLIBCXX_DEQUE_BUF_SIZE
> ? size_t(_GLIBCXX_DEQUE_BUF_SIZE / __size) : size_t(1)); }
>
> which means that for larger value_types, where you are observing
> speedups, the nodes have only one element (as stated in the quoted
> text). That would be a possible reason on why you see the speed-ups.
>
> 3) You are saying we should replace the std::stack adaptor with your
> container due to performance, but the source of speed-ups is far from
> clear. It does not seem to have anything to do with the adaptor itself
> but with the underlying container.
>
> 4) *I don't have time/initiative to do write an alternative container*
> and *I'll fill you in on the details if I'm feeling up
> to writing a second draft*
>
> Never asked for this. But it sounds like it is a pain to you to make
> the points clear.
>
> Marcelo
>
--
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/5782CCB1.1060408%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 10 Jul 2016 16:57:58 -0700 (PDT)
Raw View
------=_Part_24_1604099755.1468195079102
Content-Type: multipart/alternative;
boundary="----=_Part_25_609808825.1468195079102"
------=_Part_25_609808825.1468195079102
Content-Type: text/plain; charset=UTF-8
On Friday, July 8, 2016 at 12:45:40 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 8 July 2016 at 11:35, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> On Friday, July 8, 2016 at 11:54:26 AM UTC-4, Peter Koch Larsen wrote:
>>>
>>> I believe that as long as you know the way to extend the size in
>>> advance, nothing prohibits it from having random access in linear
>>> time.
>>
>>
>> Are random access iterators allowed to have `i + n` act in linear time?
>>
>
> No. It must be constant time.
>
>
>> Granted, I know that `deque`'s iterators kinda fudge the rules here.
>>
>
> They do? Could you elaborate?
>
My mistake; I was thinking of a deque-style implementation based on a
linked-list of blocks, rather than an array of pointers to blocks. With the
latter, you can have constant-time access.
--
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/1d795f3a-7410-4631-8fb2-0fa461fc3866%40isocpp.org.
------=_Part_25_609808825.1468195079102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 8, 2016 at 12:45:40 PM UTC-4, Nevi=
n ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">On 8 July 2016 at 11:35, Nicol Bolas <span dir=3D"ltr"><=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PZuIGNR=
4CQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck=
....@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, July 8, 2016 a=
t 11:54:26 AM UTC-4, Peter Koch Larsen wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"> I believe that as long as you know the way to extend the size in
<br>advance, nothing prohibits it from having random access in linear
<br>time.</blockquote></span><div><br>Are random access iterators allowed t=
o have `i + n` act in linear time?</div></div></blockquote><div><br></div><=
div>No.=C2=A0 It must be constant time.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div> Granted, I know that `deque`'s=
iterators kinda fudge the rules here.<br></div></div></blockquote><div><br=
></div><div>They do?=C2=A0 Could you elaborate?</div></div></div></div></bl=
ockquote><div><br>My mistake; I was thinking of a deque-style implementatio=
n based on a linked-list of blocks, rather than an array of pointers to blo=
cks. With the latter, you can have constant-time access.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1d795f3a-7410-4631-8fb2-0fa461fc3866%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d795f3a-7410-4631-8fb2-0fa461fc3866=
%40isocpp.org</a>.<br />
------=_Part_25_609808825.1468195079102--
------=_Part_24_1604099755.1468195079102--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 10 Jul 2016 17:55:52 -0700 (PDT)
Raw View
------=_Part_299_1564425033.1468198552238
Content-Type: multipart/alternative;
boundary="----=_Part_300_426336230.1468198552238"
------=_Part_300_426336230.1468198552238
Content-Type: text/plain; charset=UTF-8
On Saturday, July 9, 2016 at 10:55:28 AM UTC-4, Marcelo Zimbres wrote:
>
>
> 2016-07-08 20:13 GMT-03:00 Matt Bentley <mattreec...@gmail.com
> <javascript:>>:
> >> It seems to me that your speed-up may be related to a better cache use
> >> and not to the data structure itself. Deque allocates small chunks and
> >> you improved this by using a growth factor of two. Actually your
> >
> >
> > Only benchmarking would prove/disprove that, and I don't have
> > time/initiative to do write an alternative container.
> >
> >
> >> *chained-group memory allocation pattern* is a linked list of nodes
> >> with different sizes, so I do not see why you cannot build it up in an
> >> allocator instead of binding the stack implementation (and users) to
> >> your specific growth strategy. That would be more flexible.
> >
> >
> > I'm not sure from your phrasing whether you mean you want me to provide
> > flexible growth factors (doable) or use a different allocation pattern
> > (don't have time) or both.
>
> My point is that the current std::stack interface already allows you to
> achieve these speed-ups by providing a deque with the growth
> characteristics you wish (and lack of random access, which is not important
> here).
>
It might be possible to do so, but I think doing so would require an
allocator to have specific knowledge of the properties of the `deque`
implementation it is used with. There's nothing that guarantees how `deque`
may allocate from an allocator, after all. A more pathological-yet-valid
implementation of `deque` might do things like reallocate all of the blocks
if you insert an element in the middle.
--
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/d8c8f6d4-7d8a-430c-97a3-bc51aa1ec9be%40isocpp.org.
------=_Part_300_426336230.1468198552238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 9, 2016 at 10:55:28 AM UTC-4, Ma=
rcelo Zimbres wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"=
ltr"><br>
2016-07-08 20:13 GMT-03:00 Matt Bentley <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"zvMeTmXBCQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">mattreec...@gmail.com</a>>:<br>
>> It seems to me that your speed-up may be related to a better cache=
use<br>
>> and not to the data structure itself. Deque allocates small chunks=
and<br>
>> you improved this by using a growth factor of two. Actually your<b=
r>
><br>
><br>
> Only benchmarking would prove/disprove that, and I don't have<br>
> time/initiative to do write an alternative container.<br>
><br>
><br>
>> *chained-group memory allocation pattern* is a linked list of node=
s<br>
>> with different sizes, so I do not see why you cannot build it up i=
n an<br>
>> allocator instead of binding the stack implementation (and users) =
to<br>
>> your specific growth strategy. That would be more flexible.<br>
><br>
><br>
> I'm not sure from your phrasing whether you mean you want me to pr=
ovide<br>
> flexible growth factors (doable) or use a different allocation pattern=
<br>
> (don't have time) or both.</p>
<p dir=3D"ltr">My point is that the current std::stack interface already al=
lows you to achieve these speed-ups by providing a deque with the growth ch=
aracteristics you wish (and lack of random access, which is not important h=
ere).</p></blockquote><div><br>It might be possible to do so, but I think d=
oing so would require an allocator to have specific knowledge of the proper=
ties of the `deque` implementation it is used with. There's nothing tha=
t guarantees how `deque` may allocate from an allocator, after all. A more =
pathological-yet-valid implementation of `deque` might do things like reall=
ocate all of the blocks if you insert an element in the middle.<br></div></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d8c8f6d4-7d8a-430c-97a3-bc51aa1ec9be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d8c8f6d4-7d8a-430c-97a3-bc51aa1ec9be=
%40isocpp.org</a>.<br />
------=_Part_300_426336230.1468198552238--
------=_Part_299_1564425033.1468198552238--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 11 Jul 2016 01:34:16 -0700 (PDT)
Raw View
------=_Part_173_1745254159.1468226056428
Content-Type: multipart/alternative;
boundary="----=_Part_174_879048802.1468226056428"
------=_Part_174_879048802.1468226056428
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=887:28:35=EF=BC=8CMatthew Bentley=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 5/07/2016 2:26 p.m., Ren Industries wrote:=20
> > But...a container /must /include iterators. The very concept of a=20
> > container /requires iteration./=20
> > Why would you ridicule someone for pointing out that which is true?=20
>
> Please point me to the technical specification that points this out.=20
> As for the ridicule part, well, why would you allow him to ridicule me=20
> in the first place?=20
>
>
> > At least one problem here is important to anyone who understands the=20
> > subject. That is, you claim you have provided something to be the=20
> > underlying "container" of `std::stack`, but it actually contradicts the=
=20
> > meaning of "container" by definition in current standard, since your=20
> > "container" does not meet the container requirements (e.g. well-formed=
=20
> > expressions in Table 103) and it is not hidden from public interface of=
=20
> > `std::stack`, so code like=20
> > `std::stack<T>::container_type::iterator_type` would break. (Also note=
=20
> > [container.adaptors.general]/1 specifies the copy of container in=20
> > initialization, which may be implemented involving iterators.) This is =
a=20
> > bug more obvious than any ABI issue (which is merely a QoI problem=20
> > rather than introducing defect into the standard), until some=20
> > modification of [container.adaptors] is included in the proposed=20
> > specification.=20
>
> Okay, that makes more sense, but which version of the standard are you=20
> looking at? Table 103 gives me unordered associative container data in=20
> n4296. Also, are there any ways to introduce this class without having=20
> to include functionality that is not required ie. iterators? As making=20
> the modifications to include this functionality will, in fact (I did=20
> write the damn thing), force changes that will decrease performance=20
> without adding anything useful for a stack.=20
>
> A recent revision of working draft would be better here. I was referring=
=20
to Table 103 =E2=80=94 Container requirements of N4594.
I don't know how to omit the requirements intentionally without=20
modification on other clauses.
>
> > The second problem meaningful making sense to everyone here is the=20
> > section "technical specification". The expected contents are totally=20
> > left out. The easiest way to fix it is to rename the title to something=
=20
> > else, probably.=20
>
> Okay, that's fair enough.=20
> M@=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/473af3a5-eb9f-44e7-82df-c5d21c157e79%40isocpp.or=
g.
------=_Part_174_879048802.1468226056428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=887:28:35=EF=BC=8CMatthew Bentle=
y=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
5/07/2016 2:26 p.m., Ren Industries wrote:
<br>=C2=A0> But...a container /must /include iterators. The very concept=
of a
<br>=C2=A0> container /requires iteration./
<br>=C2=A0> Why would you ridicule someone for pointing out that which i=
s true?
<br>
<br>Please point me to the technical specification that points this out.
<br>As for the ridicule part, well, why would you allow him to ridicule me=
=20
<br>in the first place?
<br>
<br>
<br>> At least one problem here is important to anyone who understands t=
he
<br>> subject. That is, you claim you have provided something to be the
<br>> underlying "container" of `std::stack`, but it actually =
contradicts the
<br>> meaning of "container" by definition in current standard=
, since your
<br>> "container" does not meet the container requirements (e.=
g. well-formed
<br>> expressions in Table 103) and it is not hidden from public interfa=
ce of
<br>> `std::stack`, so code like
<br>> `std::stack<T>::container_<wbr>type::iterator_type` would br=
eak. (Also note
<br>> [container.adaptors.general]/1 specifies the copy of container in
<br>> initialization, which may be implemented involving iterators.) Thi=
s is a
<br>> bug more obvious than any ABI issue (which is merely a QoI problem
<br>> rather than introducing defect into the standard), until some
<br>> modification of [container.adaptors] is included in the proposed
<br>> specification.
<br>
<br>Okay, that makes more sense, but which version of the standard are you=
=20
<br>looking at? Table 103 gives me unordered associative container data in=
=20
<br>n4296. Also, are there any ways to introduce this class without having=
=20
<br>to include functionality that is not required ie. iterators? As making=
=20
<br>the modifications to include this functionality will, in fact (I did=20
<br>write the damn thing), force changes that will decrease performance=20
<br>without adding anything useful for a stack.
<br>
<br></blockquote><div>A recent revision of working draft would be better he=
re. I was referring to Table 103 =E2=80=94 Container requirements of N4594.=
<br><br>I don't know how to omit the requirements intentionally without=
modification on other clauses.<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
<br>> The second problem meaningful making sense to everyone here is the
<br>> section "technical specification". The expected contents=
are totally
<br>> left out. The easiest way to fix it is to rename the title to some=
thing
<br>> else, probably.
<br>
<br>Okay, that's fair enough.
<br>M@
<br></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/473af3a5-eb9f-44e7-82df-c5d21c157e79%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/473af3a5-eb9f-44e7-82df-c5d21c157e79=
%40isocpp.org</a>.<br />
------=_Part_174_879048802.1468226056428--
------=_Part_173_1745254159.1468226056428--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Mon, 11 Jul 2016 01:46:16 -0700 (PDT)
Raw View
------=_Part_425_1771040152.1468226776311
Content-Type: multipart/alternative;
boundary="----=_Part_426_1724365072.1468226776312"
------=_Part_426_1724365072.1468226776312
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC+=
8=E4=B8=8A=E5=8D=889:45:52=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:
>>
>> On 5/07/2016 2:26 p.m., Ren Industries wrote:=20
>> > But...a container /must /include iterators. The very concept of a=20
>> > container /requires iteration./=20
>> > Why would you ridicule someone for pointing out that which is true?=
=20
>>
>> Please point me to the technical specification that points this out.
>>
>
> N4852 <http://wg21.link/N4852>(PDF), [container.requirements.general],=20
> Table 103.
>
This is a dead link (404). Did you mean N4582 <http://wg21.link/N4582>?=20
>
> As for the ridicule part, well, why would you allow him to ridicule me=20
>> in the first place?
>>
>
> 1: He doesn't control what other people do.
>
> 2: I didn't ridicule you.
> =20
>
>> > At least one problem here is important to anyone who understands the=
=20
>> > subject. That is, you claim you have provided something to be the=20
>> > underlying "container" of `std::stack`, but it actually contradicts th=
e=20
>> > meaning of "container" by definition in current standard, since your=
=20
>> > "container" does not meet the container requirements (e.g. well-formed=
=20
>> > expressions in Table 103) and it is not hidden from public interface o=
f=20
>> > `std::stack`, so code like=20
>> > `std::stack<T>::container_type::iterator_type` would break. (Also note=
=20
>> > [container.adaptors.general]/1 specifies the copy of container in=20
>> > initialization, which may be implemented involving iterators.) This is=
=20
>> a=20
>> > bug more obvious than any ABI issue (which is merely a QoI problem=20
>> > rather than introducing defect into the standard), until some=20
>> > modification of [container.adaptors] is included in the proposed=20
>> > specification.=20
>>
>> Okay, that makes more sense, but which version of the standard are you=
=20
>> looking at? Table 103 gives me unordered associative container data in=
=20
>> n4296. Also, are there any ways to introduce this class without having=
=20
>> to include functionality that is not required ie. iterators?
>
>
> Sure. Step 1 in that is to not call it a container.
>
> Step 2 is to *prove* (perhaps by detailing the particulars of your=20
> implementation) that support for generalized container functionality woul=
d=20
> *require* degrading the performance of the object in its natural=20
> environment.
>
> My point here is that it's not something you should leave unaddressed;=20
> it's very much an "elephant in the room" for this type. People will wonde=
r=20
> why it's not a full-fledged container. And as I pointed out before, there=
=20
> are use cases which could benefit from this type's allocation and iterato=
r=20
> invalidation pattern with more generalized container functionality.
>
> Step 3: propose a change of `std::stack`'s requirements. Right now, it=20
> requires that the type be a "sequence container". But that's unnecessary.=
=20
> All it really needs is a type which is copyable and supports `back`,=20
> `push/emplace_back`, `size`, `empty`, and `pop_back`. Iterator support an=
d=20
> other container features are unnecessary.
>
> As making=20
>> the modifications to include this functionality will, in fact (I did=20
>> write the damn thing), force changes that will decrease performance=20
>> without adding anything useful for a stack.
>>
>
> Could you explain what those changes would be?
>
> I obviously haven't implemented such a container. But I imagine the most=
=20
> obvious implementation would be as a linked list of data blocks that=20
> contain each segment. Each block has the linked list pointer(s), probably=
a=20
> size/capacity pair, and then the actual storage for that block's elements=
..
>
> In order to perform forward iteration, all you would need is the ability=
=20
> to go from one block to the next, which the linked list provides
>
> The only thing I can imagine that would cause any kind of change is if=20
> your linked list of blocks is a *singly*-linked list. That is, the head=
=20
> block is the most recent block. This would naturally require the=20
> segmented_stack class itself to store two pointers in the linked list: on=
e=20
> to the true head (in terms of allocations) and one to the head that=20
> contains the actual head element in the stack. These may be different, an=
d=20
> since you can only iterate down the stack, your object would need to be=
=20
> able to jump from the back to the front.
>
> In which case... just reverse the meaning of the sequence. Rather than=20
> pushing and popping to the back, you're pushing and popping from the=20
> *front*. Thus, `begin` would return the most recently inserted element,=
=20
> while `end` would be just after the last element. And therefore, the only=
=20
> thing you would need that you don't have is a pointer to the last block.
>
> Which would hardly be a burden performance-wise.
>
--=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/25d378e2-f8ba-43f8-b32b-91962a53f88d%40isocpp.or=
g.
------=_Part_426_1724365072.1468226776312
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=888=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=889:45:52=EF=BC=8CNicol Bolas=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 d=
ir=3D"ltr">On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 5/07/2016 2:26 p.m., Ren In=
dustries wrote:
<br>=C2=A0> But...a container /must /include iterators. The very concept=
of a
<br>=C2=A0> container /requires iteration./
<br>=C2=A0> Why would you ridicule someone for pointing out that which i=
s true?
<br>
<br>Please point me to the technical specification that points this out.<br=
></blockquote><div><br><a href=3D"http://wg21.link/N4852" target=3D"_blank"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwg21.link%2FN4852\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNE-8nGAOEyO0mB6_peswpD3jGKYOg';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FN4852\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNE-8nGAOEyO0mB6_peswpD3jGKYOg';return true=
;">N4852</a>(PDF), [container.requirements.<wbr>general], Table 103.<br></d=
iv></div></blockquote><div>This is a dead link (404). Did you mean <a href=
=3D"http://wg21.link/N4582">N4582</a>? <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">As for the ridicule part, well, why would you allow him to =
ridicule me=20
<br>in the first place?<br></blockquote><div><br>1: He doesn't control =
what other people do.<br><br>2: I didn't ridicule you.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">
> At least one problem here is important to anyone who understands the
<br>> subject. That is, you claim you have provided something to be the
<br>> underlying "container" of `std::stack`, but it actually =
contradicts the
<br>> meaning of "container" by definition in current standard=
, since your
<br>> "container" does not meet the container requirements (e.=
g. well-formed
<br>> expressions in Table 103) and it is not hidden from public interfa=
ce of
<br>> `std::stack`, so code like
<br>> `std::stack<T>::container_<wbr>type::iterator_type` would br=
eak. (Also note
<br>> [container.adaptors.general]/1 specifies the copy of container in
<br>> initialization, which may be implemented involving iterators.) Thi=
s is a
<br>> bug more obvious than any ABI issue (which is merely a QoI problem
<br>> rather than introducing defect into the standard), until some
<br>> modification of [container.adaptors] is included in the proposed
<br>> specification.
<br>
<br>Okay, that makes more sense, but which version of the standard are you=
=20
<br>looking at? Table 103 gives me unordered associative container data in=
=20
<br>n4296. Also, are there any ways to introduce this class without having=
=20
<br>to include functionality that is not required ie. iterators?</blockquot=
e><div><br>Sure. Step 1 in that is to not call it a container.<br><br>Step =
2 is to <i>prove</i> (perhaps by detailing the particulars of your implemen=
tation) that support for generalized container functionality would <i>requi=
re</i> degrading the performance of the object in its natural environment.<=
br><br>My point here is that it's not something you should leave unaddr=
essed; it's very much an "elephant in the room" for this type=
.. People will wonder why it's not a full-fledged container. And as I po=
inted out before, there are use cases which could benefit from this type=
9;s allocation and iterator invalidation pattern with more generalized cont=
ainer functionality.<br><br>Step 3: propose a change of `std::stack`'s =
requirements. Right now, it requires that the type be a "sequence cont=
ainer". But that's unnecessary. All it really needs is a type whic=
h is copyable and supports `back`, `push/emplace_back`, `size`, `empty`, an=
d `pop_back`. Iterator support and other container features are unnecessary=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As making=20
<br>the modifications to include this functionality will, in fact (I did=20
<br>write the damn thing), force changes that will decrease performance=20
<br>without adding anything useful for a stack.<br></blockquote><div><br>Co=
uld you explain what those changes would be?<br><br>I obviously haven't=
implemented such a container. But I imagine the most obvious implementatio=
n would be as a linked list of data blocks that contain each segment. Each =
block has the linked list pointer(s), probably a size/capacity pair, and th=
en the actual storage for that block's elements.<br><br>In order to per=
form forward iteration, all you would need is the ability to go from one bl=
ock to the next, which the linked list provides<br><br>The only thing I can=
imagine that would cause any kind of change is if your linked list of bloc=
ks is a <i>singly</i>-linked list. That is, the head block is the most rece=
nt block. This would naturally require the segmented_stack class itself to =
store two pointers in the linked list: one to the true head (in terms of al=
locations) and one to the head that contains the actual head element in the=
stack. These may be different, and since you can only iterate down the sta=
ck, your object would need to be able to jump from the back to the front.<b=
r><br>In which case... just reverse the meaning of the sequence. Rather tha=
n pushing and popping to the back, you're pushing and popping from the =
<i>front</i>. Thus, `begin` would return the most recently inserted element=
, while `end` would be just after the last element. And therefore, the only=
thing you would need that you don't have is a pointer to the last bloc=
k.<br><br>Which would hardly be a burden performance-wise.<br></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/25d378e2-f8ba-43f8-b32b-91962a53f88d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25d378e2-f8ba-43f8-b32b-91962a53f88d=
%40isocpp.org</a>.<br />
------=_Part_426_1724365072.1468226776312--
------=_Part_425_1771040152.1468226776311--
.
Author: Marcelo Zimbres <mzimbres@gmail.com>
Date: Sat, 16 Jul 2016 04:28:05 -0300
Raw View
Hi,
for those still interested in the topic, I have make some benchmarks
of std::stack with different data structures. Please find results here
https://github.com/mzimbres/rtcpp/blob/master/doc/fig/stack_bench.pdf
My conclusions
1) std::stack with std::vector is the slowest as expected since it
incurs linear time on every reallocation.
2) std::stack with std::list and std::deque: Both are very fragmented
and have poor performance but the std::deque is faster and I do not
know really why, as I have chosen a value_type size to make the node
size in the std::deque to have only one element in my gcc.
3) std::stack with std2::deque and plf::stack: They both perform
faster than the others. std2::deque is a change I have made in the
std::deque to make it always allocate 4096 elements in the node.
Making this number bigger would eventually make it as fast as
plf::stack(see [1]).
The growth factor of of too seems to have an asymptotic advantage but
the disadvantage of wasting 25% of the allocated memory (if we agree
it is on average half of the last node), whereas in common std::deque
implementations it tends to zero.
This is a big behavioural change if this strategy is ever going to
replace a deque.
Marcelo
[1] It sounds like plf::stack does not release memory in general pops,
see this comment in the code:
// Remove trailing stack groups (not removed in general 'pop' usage
for performance reasons)
2016-07-11 5:46 GMT-03:00 FrankHB1989 <frankhb1989@gmail.com>:
>
>
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=889:45:52=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>>
>> On Thursday, July 7, 2016 at 7:28:35 PM UTC-4, Matthew Bentley wrote:
>>>
>>> On 5/07/2016 2:26 p.m., Ren Industries wrote:
>>> > But...a container /must /include iterators. The very concept of a
>>> > container /requires iteration./
>>> > Why would you ridicule someone for pointing out that which is true?
>>>
>>> Please point me to the technical specification that points this out.
>>
>>
>> N4852(PDF), [container.requirements.general], Table 103.
>
> This is a dead link (404). Did you mean N4582?
>>
>>
>>> As for the ridicule part, well, why would you allow him to ridicule me
>>> in the first place?
>>
>>
>> 1: He doesn't control what other people do.
>>
>> 2: I didn't ridicule you.
>>
>>>
>>> > At least one problem here is important to anyone who understands the
>>> > subject. That is, you claim you have provided something to be the
>>> > underlying "container" of `std::stack`, but it actually contradicts t=
he
>>> > meaning of "container" by definition in current standard, since your
>>> > "container" does not meet the container requirements (e.g. well-forme=
d
>>> > expressions in Table 103) and it is not hidden from public interface =
of
>>> > `std::stack`, so code like
>>> > `std::stack<T>::container_type::iterator_type` would break. (Also not=
e
>>> > [container.adaptors.general]/1 specifies the copy of container in
>>> > initialization, which may be implemented involving iterators.) This i=
s
>>> > a
>>> > bug more obvious than any ABI issue (which is merely a QoI problem
>>> > rather than introducing defect into the standard), until some
>>> > modification of [container.adaptors] is included in the proposed
>>> > specification.
>>>
>>> Okay, that makes more sense, but which version of the standard are you
>>> looking at? Table 103 gives me unordered associative container data in
>>> n4296. Also, are there any ways to introduce this class without having
>>> to include functionality that is not required ie. iterators?
>>
>>
>> Sure. Step 1 in that is to not call it a container.
>>
>> Step 2 is to prove (perhaps by detailing the particulars of your
>> implementation) that support for generalized container functionality wou=
ld
>> require degrading the performance of the object in its natural environme=
nt.
>>
>> My point here is that it's not something you should leave unaddressed;
>> it's very much an "elephant in the room" for this type. People will wond=
er
>> why it's not a full-fledged container. And as I pointed out before, ther=
e
>> are use cases which could benefit from this type's allocation and iterat=
or
>> invalidation pattern with more generalized container functionality.
>>
>> Step 3: propose a change of `std::stack`'s requirements. Right now, it
>> requires that the type be a "sequence container". But that's unnecessary=
..
>> All it really needs is a type which is copyable and supports `back`,
>> `push/emplace_back`, `size`, `empty`, and `pop_back`. Iterator support a=
nd
>> other container features are unnecessary.
>>
>>> As making
>>> the modifications to include this functionality will, in fact (I did
>>> write the damn thing), force changes that will decrease performance
>>> without adding anything useful for a stack.
>>
>>
>> Could you explain what those changes would be?
>>
>> I obviously haven't implemented such a container. But I imagine the most
>> obvious implementation would be as a linked list of data blocks that con=
tain
>> each segment. Each block has the linked list pointer(s), probably a
>> size/capacity pair, and then the actual storage for that block's element=
s.
>>
>> In order to perform forward iteration, all you would need is the ability
>> to go from one block to the next, which the linked list provides
>>
>> The only thing I can imagine that would cause any kind of change is if
>> your linked list of blocks is a singly-linked list. That is, the head bl=
ock
>> is the most recent block. This would naturally require the segmented_sta=
ck
>> class itself to store two pointers in the linked list: one to the true h=
ead
>> (in terms of allocations) and one to the head that contains the actual h=
ead
>> element in the stack. These may be different, and since you can only ite=
rate
>> down the stack, your object would need to be able to jump from the back =
to
>> the front.
>>
>> In which case... just reverse the meaning of the sequence. Rather than
>> pushing and popping to the back, you're pushing and popping from the fro=
nt.
>> Thus, `begin` would return the most recently inserted element, while `en=
d`
>> would be just after the last element. And therefore, the only thing you
>> would need that you don't have is a pointer to the last block.
>>
>> Which would hardly be a burden performance-wise.
>
> --
> 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/25d378e2-f8b=
a-43f8-b32b-91962a53f88d%40isocpp.org.
--=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/CAPGXEnG-0X%3DWMCmJ_gKsTrye6MrvsW%3DaODhJsYQS_F%=
2B8xt6%2Bjw%40mail.gmail.com.
.