a) Generally I like this proposal.  It's functionality which has been
missing a long time.

b) I much prefer the name "ring_buffer" to "ring_span".  If I were
looking for a ring buffer - I don't think I would find the
functionality.  I know it's only name - it's not THAT important, but it
does bug me.

c) re: template<typename T >struct *_popper{ void operator()(T&);};

What is the purpose of the T& arguments?  If they are to provide a
reference for the location where the result should be stored it should
be explained.  If this is the idea, I would say I generally dislike such
an interface.  But then I see it's not meant be used by users.

I would expect to see

template<typename T ????> {
struct ring_span {

reference front() noexcept;
const_reference front()const noexcept;
reference back() noexcept;
const_reference back()const noexcept;

void pop(); //
T pop();
T pop_move();

....
void push_back(T && t);
void emplace_back(FromType &&... ft);

};

so:

ring_span<int> rs(begin(), end());

null_popper(?) -> rs.pop();
default_popper(?) -> int x = rs.pop();
or
x = rs.pop_move();

which, to me, gives the same functionality in a way that's a lot easier
to understand for the user.

(note: I'm unclear whether C++ picks out the reference/const reference
versions given the argument - but that's probably just me.  I'll assume
you've got this right.


d) It's unclear why a Contiguous Iterator is necessary.  Why shouldn't
this structure be compatible with any forward iterator such as
std::list?  Maybe I'm mis-understanding what this facade/view is
supposed to do.

e) The proposal would be easier to understand it if it leveraged more on
familiar concepts.  E.G.

ring_span<T>

requires
Assignable<T>

f) This proposal contains a sample implementation along with a test
program.  This inspires confidence and helps explain things.  Other
proposals also do this.  Generally a good thing.  But I'm wondering if
it wouldn't be better to include the reference implementation and
test(s) in a git hub repository and make reference to it.  This would

1) make it easier for me to clone the reference implementation and test
it.  I could also try replacing my home brew version with this one.
This would give you valuable feedback.

2) maintain a greater separation between the specification and the
reference implementation. As it is now, there is too much temptation to
just go to the implementation to answer some question rather than
insisting the specification contain all needed information.

Feel free to take my observations with a grain of salt as I just read
over the proposal.  But It is something I've wanted for a long time.

Robert Ramey



--
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/nat7e9%24and%241%40ger.gmane.org.

.

PS

I'm wondering if it shouldn't be:

template<typename I ...
struct ring_span {

requires ForwardIterator<I>

};

You can get the value type from I type traits. If you have some sort of
weird iterator like object - it could still work.

Robert Ramey

--
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/56D22266.3090303%40rrsd.com.

.

--047d7b5d4a26999ec8052cc941c6
Content-Type: text/plain; charset=UTF-8

>> I would expect to see
>> ...
>>T pop()

From section 4,

If an item is popped from a std::queue it is destroyed and the memory is
released. In the case of a ring_span however, it does not own the memory so
a different strategy must be pursued.

There is no single solution that covers all these situations, so as part of
the definition of ring_span a number of pop strategy objects are defined.

The reference provides the object to be popped (not the destination
storage), and the popper translates that into a return value as necessary
(by moving, copying, default-constructing, etc).


>>I much prefer the name "ring_buffer" to "ring_span".
Buffers hold data. A span observes data owned by other data structures.
This class is not a buffer.

The sample code demonstrates this:

std::array<int,5> buffer;
auto Q=ring_span<int>(buffer.begin(),buffer.end(),buffer.begin(), 0);



On Sat, Feb 27, 2016 at 4:25 PM, Robert Ramey <ramey@rrsd.com> wrote:

>
> PS
>
> I'm wondering if it shouldn't be:
>
> template<typename I ...
> struct ring_span {
>
> requires ForwardIterator<I>
>
> };
>
> You can get the value type from I type traits. If you have some sort of
> weird iterator like object - it could still work.
>
> Robert Ramey
>
> --
> 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/56D22266.3090303%40rrsd.com
> .
>

--
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/CADbh%2BeS0Nrkw3yno-t5%2Be_PeKBL0kpiFXMkeevUDaiBB-s02NQ%40mail.gmail.com.

--047d7b5d4a26999ec8052cc941c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;&gt;=C2=A0<span style=3D"font-size:12.8px">I woul=
d expect to see</span></div><div><span style=3D"font-size:12.8px">&gt;&gt; =
....</span></div><div>&gt;&gt;<span style=3D"font-size:12.8px">T pop()</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div>From section =
4,<br><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"=
><div>If an item is popped from a std::queue it
is destroyed and the memory is released. In the case of a ring_span however=
, it does not
own the memory so a different strategy must be pursued.=C2=A0</div><div><br=
></div><div>There is no single solution that covers all these situations, s=
o as part of the
definition of ring_span a number of pop strategy objects are defined.=C2=A0=
</div></blockquote><div>The reference provides the object to be popped (not=
 the destination storage), and the popper translates that into a return val=
ue as necessary (by moving, copying, default-constructing, etc).</div><div>=
<br></div><div><br></div><div>&gt;&gt;<span style=3D"font-size:12.8px">I mu=
ch prefer the name &quot;ring_buffer&quot; to &quot;ring_span&quot;.</span>=
</div><div>Buffers hold data. A span observes data owned by other data stru=
ctures. This class is not a buffer.</div><div><br></div><div>The sample cod=
e demonstrates this:</div><blockquote style=3D"margin:0 0 0 40px;border:non=
e;padding:0px"><div>std::array&lt;int,5&gt;=C2=A0buffer;</div><div>auto Q=
=3Dring_span&lt;int&gt;(buffer.begin(),buffer.end(),buffer.begin(),
0);=C2=A0</div></blockquote><div><br></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sat, Feb 27, 2016 at 4:25 PM, Robert Ram=
ey <span dir=3D"ltr">&lt;<a href=3D"mailto:ramey@rrsd.com" target=3D"_blank=
">ramey@rrsd.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><b=
r>
PS<br>
<br>
I&#39;m wondering if it shouldn&#39;t be:<br>
<br>
template&lt;typename I ...<br>
struct ring_span {<br>
<br>
requires ForwardIterator&lt;I&gt;<br>
<br>
};<br>
<br>
You can get the value type from I type traits. If you have some sort of wei=
rd iterator like object - it could still work.<span class=3D""><br>
<br>
Robert Ramey<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/56D22266.3090303%40rrsd.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/56D22266.3090303%40rrsd.com</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeS0Nrkw3yno-t5%2Be_PeKBL0kpiF=
XMkeevUDaiBB-s02NQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeS0Nr=
kw3yno-t5%2Be_PeKBL0kpiFXMkeevUDaiBB-s02NQ%40mail.gmail.com</a>.<br />

--047d7b5d4a26999ec8052cc941c6--

.

On 2/27/2016 4:19 PM, Robert Ramey wrote:
> b) I much prefer the name "ring_buffer" to "ring_span".  If I were
> looking for a ring buffer - I don't think I would find the
> functionality.  I know it's only name - it's not THAT important, but it
> does bug me.

Given that it *is* a span (i.e. a writable view on another container)
and not an adapter like std::queue, I think the name makes sense. It
will probably be easier to find when (if?) other spans are standardized
too, e.g. span and string_span from the GSL.

- Jim

--
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/natndf%2482l%241%40ger.gmane.org.

.

On 02/28/2016 01:03 AM, Brent Friedman wrote:

> Buffers hold data. A span observes data owned by other data structures.

What is the difference between a span and a view?

--
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/56D2D20C.5050609%40mail1.stofanet.dk.

.

Views can't write to the data, only view it.

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Bjorn Reese
Sent: Sunday, February 28, 2016 5:55 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: comments on ring_span proposal P0059R1

On 02/28/2016 01:03 AM, Brent Friedman wrote:

> Buffers hold data. A span observes data owned by other data structures.

What is the difference between a span and a view?

--=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/56D2D20C.5050609%40mail1.stofanet.dk.

--=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/20160228135138.4923473.6382.6082%40gmail.com.

.

On 2/28/16 5:51 AM, Tony V E wrote:
> Views can't write to the data, only view it.
>

Hmm - I've been thinking in terms of the ranges libraries.

In that context, I've been using (in my own head) the
idea of a const view vs mutable view.  I actually
don't remember coming across the word "span".

Having said this, I don't want to make a big deal
out of this.  In this case I don't think it's a huge
deal.  I don't always think this way - I certainly
think some names - e.g. vector, concept are
regrettable but we've managed to survive them.

Robert Ramey

--
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/56D323C7.5070701%40rrsd.com.

.

--089e013d156480b858052cdc595a
Content-Type: text/plain; charset=UTF-8

On 28 February 2016 at 17:43, Robert Ramey <ramey@rrsd.com> wrote:

> On 2/28/16 5:51 AM, Tony V E wrote:
>
>> Views can't write to the data, only view it.
>>
>>
> Hmm - I've been thinking in terms of the ranges libraries.
>
>
My understanding so far was that views don't imply a particular
implementation (there can be interpretation of the data
before preventing it to the user)
while spans are literally a reference to contiguous data presented in
useful way.
Basically, spans are a specific kind of views.

But I don't know if there is an official lexicon for that.



> In that context, I've been using (in my own head) the
> idea of a const view vs mutable view.  I actually
> don't remember coming across the word "span".
>
> Having said this, I don't want to make a big deal
> out of this.  In this case I don't think it's a huge
> deal.  I don't always think this way - I certainly
> think some names - e.g. vector, concept are
> regrettable but we've managed to survive them.
>
> Robert Ramey
>
> --
> 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/56D323C7.5070701%40rrsd.com
> .
>

--
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/CAOU91OOoq6-kp8hozptkQrMQLzuqfLviBCbFt3%2B1LBZwPP4O1g%40mail.gmail.com.

--089e013d156480b858052cdc595a
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 28 February 2016 at 17:43, Robert Ramey <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ramey@rrsd.com" target=3D"_blank">ramey@rrsd.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2/28/16 5:51 =
AM, Tony V E wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Views can&#39;t write to the data, only view it.<br>
<br>
</blockquote>
<br></span>
Hmm - I&#39;ve been thinking in terms of the ranges libraries.<br>
<br></blockquote><div><br></div><div>My understanding so far was that views=
 don&#39;t imply a particular implementation (there can be interpretation o=
f the data</div><div>before preventing it to the user)</div><div>while span=
s are literally a reference to contiguous data presented in useful way.</di=
v><div>Basically, spans are a specific kind of views.</div><div><br></div><=
div>But I don&#39;t know if there is an official lexicon for that.</div><di=
v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In that context, I&#39;ve been using (in my own head) the<br>
idea of a const view vs mutable view.=C2=A0 I actually<br>
don&#39;t remember coming across the word &quot;span&quot;.<br>
<br>
Having said this, I don&#39;t want to make a big deal<br>
out of this.=C2=A0 In this case I don&#39;t think it&#39;s a huge<br>
deal.=C2=A0 I don&#39;t always think this way - I certainly<br>
think some names - e.g. vector, concept are<br>
regrettable but we&#39;ve managed to survive them.<br>
<br>
Robert Ramey<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/56D323C7.5070701%40rrsd.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/56D323C7.5070701%40rrsd.com</a>.<br>
</blockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91OOoq6-kp8hozptkQrMQLzuqfLviBCbF=
t3%2B1LBZwPP4O1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OOoq6-kp8=
hozptkQrMQLzuqfLviBCbFt3%2B1LBZwPP4O1g%40mail.gmail.com</a>.<br />

--089e013d156480b858052cdc595a--

.

------=_Part_151_195989597.1456721795843
Content-Type: multipart/alternative;
 boundary="----=_Part_152_749756077.1456721795844"

------=_Part_152_749756077.1456721795844
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, February 27, 2016 at 2:20:06 PM UTC-8, Robert Ramey wrote:
>
> a) Generally I like this proposal.  It's functionality which has been=20
> missing a long time.=20
>

Thanks!  I'm the co-author. I'll try to answer your comments below.


> b) I much prefer the name "ring_buffer" to "ring_span".  If I were=20
> looking for a ring buffer - I don't think I would find the=20
> functionality.  I know it's only name - it's not THAT important, but it=
=20
> does bug me.=20
>

I think Brent Friedman's response adequately addressed this one.=20
Incidentally, I would VASTLY prefer to see the Committee standardize the=20
name "view<T>" for a view of mutable T, and "view<const T>" for a view of=
=20
non-mutable T; but my impression has been that a vocal minority prefers=20
"span<T>" for a view of mutable T and "view<T>" for a view of non-mutable=
=20
T, so P0059R1 adopts that nomenclature. I would be thrilled if we could get=
=20
"ring_view" instead of "ring_span", "array_view" instead of "span",=20
"string_view" instead of "string_span", etc., but I consider that battle=20
"out of scope" for P0059.
=20

> c) re: template<typename T >struct *_popper{ void operator()(T&);};=20
>
> What is the purpose of the T& arguments?  If they are to provide a=20
> reference for the location where the result should be stored it should=20
> be explained.


Brent addressed this one, too, but let me just say explicitly: The T&=20
parameter is not where to *put* the popped data. The T& is where to pop the=
=20
data *from*.
The point of "Popper" is to allow ring_span<ExpensiveToMoveType,=20
null_popper<ExpensiveToMoveType>>::pop_front() to be as cheap as a no-op,=
=20
whereas ring_span<ExpensiveToMoveType,=20
default_popper<ExpensiveToMoveType>>::pop_front() would be as expensive as=
=20
move-constructing an ExpensiveToMoveType.

d) It's unclear why a Contiguous Iterator is necessary.  Why shouldn't=20
> this structure be compatible with any forward iterator such as=20
> std::list?  Maybe I'm mis-understanding what this facade/view is=20
> supposed to do.=20
>

Basically, I don't think there's any use-case for making a ring-buffer=20
(which is intrinsically fixed-capacity) out of an arbitrary container (such=
=20
as a std::list or even a std::deque). The only backing store that makes=20
sense is a contiguous span of memory; so let's be friendly to the user and=
=20
just force that right up front. Otherwise, we end up in a situation like=20
std::binary_search, where it's possible to use it on a std::list (because=
=20
it works on any ForwardIterator) but the big-O complexity secretly climbs=
=20
from O(lg N) to O(N).
Also, after discussion at the Mountain View ACCU this past week, I'd like=
=20
to add push_front() and pop_back() member functions =E2=80=94 turning ring_=
span=20
from a single-ended queue into a double-ended queue =E2=80=94 which means t=
he=20
backing store would have to be at least BidirectionalIterator.
=20

> e) The proposal would be easier to understand it if it leveraged more on=
=20
> familiar concepts.  E.G.=20
>
> ring_span<T>=20
> requires=20
> Assignable<T>=20
>

Once Concepts are in the standard, perhaps. ;)
=20

> f) This proposal contains a sample implementation along with a test=20
> program.  This inspires confidence and helps explain things.  Other=20
> proposals also do this.  Generally a good thing.  But I'm wondering if=20
> it wouldn't be better to include the reference implementation and=20
> test(s) in a git hub repository and make reference to it.  This would=20
> make it easier for me to clone the reference implementation and test=20
> it.  I could also try replacing my home brew version with this one.=20
> This would give you valuable feedback.=20
>

I have a very sketchy and completely untested repo at=20
https://github.com/Quuxplusone/ring_view. Use at your own risk!
I'm also interested in getting it into the Boost Incubator in some form,=20
but I know that would require writing a lot more documentation and tests,=
=20
so I haven't actively pursued that yet.

I'm particularly interested in getting feedback from people who have tried=
=20
to use ring_span<T> in the real world, to learn whether it is really a=20
suitable replacement for the average codebase's hand-coded ring-buffer.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b467eef0-85bb-44fa-aea7-8a834c94371c%40isocpp.or=
g.

------=_Part_152_749756077.1456721795844
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 27, 2016 at 2:20:06 PM UTC-8, Robert=
 Ramey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">a) Generally I li=
ke this proposal. =C2=A0It&#39;s functionality which has been=20
<br>missing a long time.
<br></blockquote><div><br></div><div>Thanks! =C2=A0I&#39;m the co-author. I=
&#39;ll try to answer your comments below.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">
<br>b) I much prefer the name &quot;ring_buffer&quot; to &quot;ring_span&qu=
ot;. =C2=A0If I were=20
<br>looking for a ring buffer - I don&#39;t think I would find the=20
<br>functionality. =C2=A0I know it&#39;s only name - it&#39;s not THAT impo=
rtant, but it=20
<br>does bug me.
<br></blockquote><div><br></div><div>I think Brent Friedman&#39;s response =
adequately addressed this one. Incidentally, I would VASTLY prefer to see t=
he Committee standardize the name &quot;view&lt;T&gt;&quot; for a view of m=
utable T, and &quot;view&lt;const T&gt;&quot; for a view of non-mutable T; =
but my impression has been that a vocal minority prefers &quot;span&lt;T&gt=
;&quot; for a view of mutable T and &quot;view&lt;T&gt;&quot; for a view of=
 non-mutable T, so P0059R1 adopts that nomenclature. I would be thrilled if=
 we could get &quot;ring_view&quot; instead of &quot;ring_span&quot;, &quot=
;array_view&quot; instead of &quot;span&quot;, &quot;string_view&quot; inst=
ead of &quot;string_span&quot;, etc., but I consider that battle &quot;out =
of scope&quot; for P0059.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">c) re: template&lt;typename T &gt;struct *_popper{ void o=
perator()(T&amp;);};
<br>
<br>What is the purpose of the T&amp; arguments? =C2=A0If they are to provi=
de a=20
<br>reference for the location where the result should be stored it should=
=20
<br>be explained.</blockquote><div><br></div><div>Brent addressed this one,=
 too, but let me just say explicitly: The T&amp; parameter is not where to =
<i>put</i> the popped data. The T&amp; is where to pop the data <i>from</i>=
..</div><div>The point of &quot;Popper&quot; is to allow <font face=3D"couri=
er new, monospace">ring_span&lt;ExpensiveToMoveType, null_popper&lt;Expensi=
veToMoveType&gt;&gt;::pop_front()</font> to be as cheap as a no-op, whereas=
=C2=A0<span style=3D"font-family: &#39;courier new&#39;, monospace;">ring_s=
pan&lt;ExpensiveToMoveType, default_popper&lt;ExpensiveToMoveType&gt;&gt;::=
pop_front()</span>=C2=A0would be as expensive as move-constructing an=C2=A0=
<font face=3D"courier new, monospace">ExpensiveToMoveType</font>.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">d) It&#39;s unclear=
 why a Contiguous Iterator is necessary. =C2=A0Why shouldn&#39;t=20
<br>this structure be compatible with any forward iterator such as=20
<br>std::list? =C2=A0Maybe I&#39;m mis-understanding what this facade/view =
is=20
<br>supposed to do.
<br></blockquote><div><br></div><div>Basically, I don&#39;t think there&#39=
;s any use-case for making a ring-buffer (which is intrinsically fixed-capa=
city) out of an arbitrary container (such as a std::list or even a std::deq=
ue). The only backing store that makes sense is a contiguous span of memory=
; so let&#39;s be friendly to the user and just force that right up front. =
Otherwise, we end up in a situation like std::binary_search, where it&#39;s=
 possible to use it on a std::list (because it works on any ForwardIterator=
) but the big-O complexity secretly climbs from O(lg N) to O(N).</div><div>=
Also, after discussion at the Mountain View ACCU this past week, I&#39;d li=
ke to add push_front() and pop_back() member functions =E2=80=94 turning ri=
ng_span from a single-ended queue into a double-ended queue =E2=80=94 which=
 means the backing store would have to be at least=C2=A0<font face=3D"couri=
er new, monospace">BidirectionalIterator</font>.</div><div>=C2=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">e) The proposal would be easie=
r to understand it if it leveraged more on=20
<br>familiar concepts. =C2=A0E.G.
<br>
<br>ring_span&lt;T&gt;
<br>requires
<br>Assignable&lt;T&gt;
<br></blockquote><div><br></div><div>Once Concepts are in the standard, per=
haps. ;)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>f) This proposal contains a sample implementation along with a test=20
<br>program. =C2=A0This inspires confidence and helps explain things. =C2=
=A0Other=20
<br>proposals also do this. =C2=A0Generally a good thing. =C2=A0But I&#39;m=
 wondering if=20
<br>it wouldn&#39;t be better to include the reference implementation and=
=20
<br>test(s) in a git hub repository and make reference to it. =C2=A0This wo=
uld
<br>make it easier for me to clone the reference implementation and test=20
<br>it. =C2=A0I could also try replacing my home brew version with this one=
..=20
<br>This would give you valuable feedback.
<br></blockquote><div><br></div><div>I have a very sketchy and completely u=
ntested repo at <a href=3D"https://github.com/Quuxplusone/ring_view">https:=
//github.com/Quuxplusone/ring_view</a>. Use at your own risk!</div><div>I&#=
39;m also interested in getting it into the Boost Incubator in some form, b=
ut I know that would require writing a lot more documentation and tests, so=
 I haven&#39;t actively pursued that yet.</div><div><br></div><div>I&#39;m =
particularly interested in getting feedback from people who have tried to u=
se ring_span&lt;T&gt; in the real world, to learn whether it is really a su=
itable replacement for the average codebase&#39;s hand-coded ring-buffer.</=
div><div><br></div><div>=E2=80=93Arthur</div></div>

<p></p>

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

------=_Part_152_749756077.1456721795844--
------=_Part_151_195989597.1456721795843--

.

> if we could get "ring_view" instead of "ring_span", "array_view" instead
> of "span", "string_view" instead of "string_span", etc.,
+1
> but I consider
> that battle "out of scope" for P0059.
OK - I'm sympathetic

>     c) re: template<typename T >struct *_popper{ void operator()(T&);};
>
>     What is the purpose of the T& arguments?  If they are to provide a
>     reference for the location where the result should be stored it shoul=
d
>     be explained.
>
>     d) It's unclear why a Contiguous Iterator is necessary.  Why shouldn'=
t
>     this structure be compatible with any forward iterator such as
>     std::list?  Maybe I'm mis-understanding what this facade/view is
>     supposed to do.
>
>
> Basically, I don't think there's any use-case for making a ring-buffer
> (which is intrinsically fixed-capacity) out of an arbitrary container
> (such as a std::list or even a std::deque).

I don't think it's a great idea to presume the use to which something=20
will be put. Stating the minimum requirements for the iterator means you=20
don't have to deal with special cases.  It's really less work and=20
there's a long history of people finding unanticipated uses for things.

It's actually funny.  I wanted this and I looked it over somewhat=20
carefully. Then I came on the iterator interface.  My reaction was -=20
what the hell is that doing in there.  Who would need or want such a=20
thing.  After all still you have the base container.  Why muck up a=20
simple interface with some cute do-dad?  I still think there's merit in=20
that view.  But I looked at the interface and other info and concluded=20
that it was simple and obvious enough that it wouldn't muck up the=20
implementation (should be almost free) and the complication it adds to=20
the documentation and interface won't be too bad, so I didn't mention=20
it.  There's a lot to be said about a simple component that one can=20
understand and use spending 2 min reading the CPP reference on it.

> The only backing store that
> makes sense is a contiguous span of memory;

I don't think you can know that.  And the cost of walking a list is O(0)=20
so there's no reason not to do it.

>  user and just force that right up front.

I hate it when this happens - especially when there's no good reason for it=
..

 > Otherwise, we end up in a
> situation like std::binary_search, where it's possible to use it on a
> std::list (because it works on any ForwardIterator) but the big-O
> complexity secretly climbs from O(lg N) to O(N).

I don't think this is the same.  I can envision a simple implementation=20
which keeps three iterators begin, end, and current.  I do not believe=20
that there is any other implementation which is significantly faster.
If someone has a complaint that dereferencing a list is too slow - then=20
that's the user's problem not the the library developer's.  You're dead=20
wroing on this one.

> Also, after discussion at the Mountain View ACCU this past week, I'd
> like to add push_front() and pop_back() member functions =E2=80=94 turnin=
g
> ring_span from a single-ended queue into a double-ended queue =E2=80=94 w=
hich
> means the backing store would have to be at least BidirectionalIterator.

No problem.  I like the symmetry - but I can't think of any use case for=20
that.

>
>     e) The proposal would be easier to understand it if it leveraged
>     more on
>     familiar concepts.  E.G.
>
>     ring_span<T>
>     requires
>     Assignable<T>
>
> Once Concepts are in the standard, perhaps. ;)

Oh Nooooooo.  The most important benefit of concepts isn't the type=20
checking by the compiler - It's the clarity of the design of the API=20
which results when you formally define the requirements of each type=20
parameter and document them in a manner similar to the SGI=20
documentation.  It's a huge time saver for both the developer as well as=20
the user.  It diminishes the need to iterate the implementation.  Having=20
this done before you deal with the committee will make the process much,=20
much much easier and less circular.

>
>     f) This proposal contains a sample implementation along with a test
>     program.  This inspires confidence and helps explain things.  Other
>     proposals also do this.  Generally a good thing.  But I'm wondering i=
f
>     it wouldn't be better to include the reference implementation and
>     test(s) in a git hub repository and make reference to it.  This would
>     make it easier for me to clone the reference implementation and test
>     it.  I could also try replacing my home brew version with this one.
>     This would give you valuable feedback.
>
> I have a very sketchy and completely untested repo at
> https://github.com/Quuxplusone/ring_view. Use at your own risk!

This is relatively simple to implement.  Writing some tests is more time=20
consuming.  I think finishing this before discussing this at some=20
committee level will also save you a lot of grief.  You might even get=20
some feed back from real users - which is actually much more useful than=20
feed back from spitballers at some meeting.

> I'm also interested in getting it into the Boost Incubator in some form,
> but I know that would require writing a lot more documentation and
> tests, so I haven't actively pursued that yet.

whoops - got a ahead of myself.  This would be a good think and might=20
produce some feedback.
>
> I'm particularly interested in getting feedback from people who have
> tried to use ring_span<T> in the real world, to learn whether it is
> really a suitable replacement for the average codebase's hand-coded
> ring-buffer.

lol - got ahead of myself again!

finally - less is more.  FWIW The fancier it is the more people will=20
suggest you do it differently.  The simpler and more minimalist is is,=20
the wider usage it will achieve.

Robert Ramey

--=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/56D3DF68.9060203%40rrsd.com.

.