------=_Part_1457_1336283053.1412314801958
Content-Type: text/plain; charset=UTF-8

With array_view, string_view, and now possibly bitset_view, this view thing
is becoming contagious.

I think at this stage it makes sense to precisely define exactly what a
view is and how it behaves as a concept. Any kind of view type that is
invented now or in the future should adhere to a set of rules so that they
all have a uniform interface.

First, what exactly is a view?

I would define it as an adapter over a fixed size contiguous range of
memory.

How does a view behave with respect to common operations?

Let's compare a view<T>, to a T, and T* and see how they behave. These
rules are derived from string_view and array_view.

T = T: copy the value (deep copy)
T* = T*: reassign the pointer (shallow copy)
view<T> = view<T>: reassign the view (shallow copy)

T == T: compare 2 values (deep compare)
T* == T*: compare whether 2 pointers point to the same thing (shallow
compare)
view<T> == view<T>: compare the values (deep compare)

T.foo(): direct member invocation of T
(T*)->foo(): indirect member invocation of T
view<T>.foo(): direct member invocation of the view type methods

Questions:
1) How do we shallow compare 2 views?
2) How do we deep copy a view?

What are the common operations for any view?

1) We can iterate over a view with begin()/end()
2) We can access an element using operator[] / at() / front() / back() /
data()
3) We can ask for the size() and whether or not the view is empty()
4) We can shrink the view by removing front or back elements, but not make
it larger. Once you chop off the front or back of the view, you can never
recover it.
5) We can reassign the view to another source array
6) We can compare 2 views

The array_view proposal also gets into multi-dimensional views and
striding, but I'm not going to go there yet.

If there are a certain set of operations that apply to any kind of view,
then perhaps it makes sense to define and mandate them for all of the view
classes. This could even be done with inheritance. Have a basic_view<T>
base class which implements the above methods and have array_view (striding
/ sectioning / dimensions), string_view (string class), bitset_view (bit
manipulation) build on top of that.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">With array_view, string_view, and now possibly bitset_view=
, this view thing is becoming contagious.<div><br></div><div>I think at thi=
s stage it makes sense to precisely define exactly what a view is and how i=
t behaves as a concept. Any kind of view type that is invented now or in th=
e future should adhere to a set of rules so that they all have a uniform in=
terface.</div><div><br></div><div>First, what exactly is a view?</div><div>=
<br></div><div>I would define it as an adapter over a fixed size contiguous=
 range of memory.</div><div><br></div><div>How does a view behave with resp=
ect to common operations?</div><div><br></div><div>Let's compare a view&lt;=
T&gt;, to a T, and T* and see how they behave. These rules are derived from=
 string_view and array_view.</div><div><br></div><div>T =3D T: copy the val=
ue (deep copy)</div><div>T* =3D T*: reassign the pointer (shallow copy)</di=
v><div>view&lt;T&gt; =3D view&lt;T&gt;: reassign the view (shallow copy)</d=
iv><div><br></div><div>T =3D=3D T: compare 2 values (deep compare)</div><di=
v>T* =3D=3D T*: compare whether 2 pointers point to the same thing (shallow=
 compare)</div><div>view&lt;T&gt; =3D=3D view&lt;T&gt;: compare the values =
(deep compare)</div><div><br></div><div>T.foo(): direct member invocation o=
f T</div><div>(T*)-&gt;foo(): indirect member invocation of T</div><div>vie=
w&lt;T&gt;.foo(): direct member invocation of the view type methods</div><d=
iv><br></div><div>Questions:</div><div>1) How do we shallow compare 2 views=
?</div><div>2) How do we deep copy a view?</div><div><br></div><div>What ar=
e the common operations for any view?</div><div><br></div><div>1) We can it=
erate over a view with begin()/end()</div><div>2) We can access an element =
using operator[] / at() / front() / back() / data()</div><div>3) We can ask=
 for the size() and whether or not the view is empty()</div><div>4) We can =
shrink the view by removing front or back elements, but not make it larger.=
 Once you chop off the front or back of the view, you can never recover it.=
</div><div>5) We can reassign the view to another source array</div><div>6)=
 We can compare 2 views</div><div><br></div><div>The array_view proposal al=
so gets into multi-dimensional views and striding, but I'm not going to go =
there yet.</div><div><br></div><div>If there are a certain set of operation=
s that apply to any kind of view, then perhaps it makes sense to define and=
 mandate them for all of the view classes. This could even be done with inh=
eritance. Have a basic_view&lt;T&gt; base class which implements the above =
methods and have array_view (striding / sectioning / dimensions), string_vi=
ew (string class), bitset_view (bit manipulation) build on top of that.</di=
v><div><br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1457_1336283053.1412314801958--

.

Il giorno 03/ott/2014, alle ore 07:40, Matthew Fioravante <fmatthew5876@gma=
il.com> ha scritto:

> With array_view, string_view, and now possibly bitset_view, this view thi=
ng is becoming contagious.
>=20
> I think at this stage it makes sense to precisely define exactly what a v=
iew is and how it behaves as a concept. Any kind of view type that is inven=
ted now or in the future should adhere to a set of rules so that they all h=
ave a uniform interface.
>=20
> First, what exactly is a view?
>=20
> I would define it as an adapter over a fixed size contiguous range of mem=
ory.
>=20

I like the idea to set in stone those definitions.=20
First question, why is the memory block necessary contiguous
for all kinds of view?
I think it would be reasonable to expect a bitset_view to work on top
of a strided array_view that sits on top of a contiguous buffer.

You could even have things like a filter_view, that discards elements
that don't satisfy a predicate, on top of a sorted_view, etc...

If one goes this way I see some overlap with the work in progress
on ranges. Maybe the two things could be made to fit together
(a view will be a range, anyway).

The contiguity is necessary to support the data() member, but other
than that it is sufficient that the underlying container/buffer have
random access iterators, I think. If it only has forward iterators
you can remove the operator[] from the interface through SFINAE=20
and only provide iterators yourself.


> How does a view behave with respect to common operations?
>=20
> Let's compare a view<T>, to a T, and T* and see how they behave. These ru=
les are derived from string_view and array_view.
>=20
> T =3D T: copy the value (deep copy)
> T* =3D T*: reassign the pointer (shallow copy)
> view<T> =3D view<T>: reassign the view (shallow copy)
>=20
> T =3D=3D T: compare 2 values (deep compare)
> T* =3D=3D T*: compare whether 2 pointers point to the same thing (shallow=
 compare)
> view<T> =3D=3D view<T>: compare the values (deep compare)
>=20
> T.foo(): direct member invocation of T
> (T*)->foo(): indirect member invocation of T
> view<T>.foo(): direct member invocation of the view type methods
>=20
> Questions:
> 1) How do we shallow compare 2 views?
> 2) How do we deep copy a view?
>=20
> What are the common operations for any view?
>=20
> 1) We can iterate over a view with begin()/end()
> 2) We can access an element using operator[] / at() / front() / back() / =
data()
> 3) We can ask for the size() and whether or not the view is empty()
> 4) We can shrink the view by removing front or back elements, but not mak=
e it larger. Once you chop off the front or back of the view, you can never=
 recover it.
> 5) We can reassign the view to another source array
> 6) We can compare 2 views
>=20
> The array_view proposal also gets into multi-dimensional views and stridi=
ng, but I'm not going to go there yet.
>=20
> If there are a certain set of operations that apply to any kind of view, =
then perhaps it makes sense to define and mandate them for all of the view =
classes. This could even be done with inheritance. Have a basic_view<T> bas=
e class which implements the above methods and have array_view (striding / =
sectioning / dimensions), string_view (string class), bitset_view (bit mani=
pulation) build on top of that.
>=20

Good ideas!

Bye,
Nicola

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_892_325335473.1412340824507
Content-Type: text/plain; charset=UTF-8



On Friday, October 3, 2014 2:56:47 AM UTC-4, Nicola Gigante wrote:
>
>
>
> I like the idea to set in stone those definitions.
> First question, why is the memory block necessary contiguous
> for all kinds of view?
>

I'm restricting myself to contiguous views on purpose. The more generic
concept is a range and there's already a study group for that. vectors and
arrays are critical for performance so this concept is very important to me.


> I think it would be reasonable to expect a bitset_view to work on top
> of a strided array_view that sits on top of a contiguous buffer.
>

I suppose that's possible, in which case bitset_view would most definitely
have to sit on top of array_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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Friday, October 3, 2014 2:56:47 AM UTC-4, Nicol=
a Gigante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<br>I like the idea to set in stone those definitions.=20
<br>First question, why is the memory block necessary contiguous
<br>for all kinds of view?
<br></blockquote><div><br></div><div>I'm restricting myself to contiguous v=
iews on purpose. The more generic concept is a range and there's already a =
study group for that. vectors and arrays are critical for performance so th=
is concept is very important to me.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I think it would be reasonable to expect a bits=
et_view to work on top
<br>of a strided array_view that sits on top of a contiguous buffer.
<br></blockquote><div><br></div><div>I suppose that's possible, in which ca=
se bitset_view would most definitely have to sit on top of array_view.</div=
><div>&nbsp;</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_892_325335473.1412340824507--

.

--089e01538326d2a0830504848c5d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that the most important question to answer is: what would be the
difference between a range and a view?=E2=80=8B

It looks to me that current researches on ranges suggest that the
distinction exists (or at least between ranges and containers).

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">I think that the most important question to answer is: wha=
t would be the difference between a range and a view?=E2=80=8B<div><br></di=
v><div>It looks to me that current researches on ranges suggest that the di=
stinction exists (or at least between ranges and containers).</div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01538326d2a0830504848c5d--

.

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

On Fri, Oct 3, 2014 at 9:17 AM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:

> I think that the most important question to answer is: what would be the
> difference between a range and a view?=E2=80=8B
>

One major likely difference is that range =3D=3D will probably be 'shallow'=
..
Deep-compare will probably be a function.

In general, I think a 'view' is this name we use where we'd like to use
range, but know that we haven't solidified what we mean by range yet, so we
are punting and going with 'view' for now.

Also a view is a less-generic range.  ie string_view has more than just
range features, it also copies over all the functions from string.


It looks to me that current researches on ranges suggest that the
> distinction exists (or at least between ranges and containers).
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b3a904400fdfe050487958c
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 Fri, Oct 3, 2014 at 9:17 AM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"=
ltr">&lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gma=
il.com</a>&gt;</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-lef=
t:1ex"><div dir=3D"ltr">I think that the most important question to answer =
is: what would be the difference between a range and a view?=E2=80=8B</div>=
</blockquote><div><br></div><div><div>One major likely difference is that r=
ange =3D=3D will probably be &#39;shallow&#39;.=C2=A0 Deep-compare will pro=
bably be a function.<br>=C2=A0<br></div><div>In general, I think a &#39;vie=
w&#39; is this name we use where we&#39;d like to use range, but know that =
we haven&#39;t solidified what we mean by range yet, so we are punting and =
going with &#39;view&#39; for now.<br></div><br></div><div>Also a view is a=
 less-generic range.=C2=A0 ie string_view has more than just range features=
, it also copies over all the functions from string.<br><br></div><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It looks=
 to me that current researches on ranges suggest that the distinction exist=
s (or at least between ranges and containers).</div></div><span class=3D"">=
<font color=3D"#888888">

<p></p>

-- <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+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a904400fdfe050487958c--

.

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



On Friday, October 3, 2014 12:54:14 PM UTC-4, Tony V E wrote:
>
>
>
> On Fri, Oct 3, 2014 at 9:17 AM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.c=
om=20
> <javascript:>> wrote:
>
>> I think that the most important question to answer is: what would be the=
=20
>> difference between a range and a view?=E2=80=8B
>>
>
> One major likely difference is that range =3D=3D will probably be 'shallo=
w'. =20
> Deep-compare will probably be a function.
>

I suppose the difference is that a range is a subset of a container, where=
=20
as a view is a container itself, that is a non-owning container. In this=20
sense a view is not actually a range at all but you can create a range over=
=20
a view for generic algorithm processing. You can also create a view from a=
=20
range.

Since view is a container, operator=3D=3D is deep because its operating on =
the=20
container contents. However view is a non-owning container, so operator=3D=
=20
reassigns it to a new owner. We should have some way to do shallow compare=
=20
and deep copy for a view.
=20

> =20
> In general, I think a 'view' is this name we use where we'd like to use=
=20
> range, but know that we haven't solidified what we mean by range yet, so =
we=20
> are punting and going with 'view' for now.
>
> Also a view is a less-generic range.  ie string_view has more than just=
=20
> range features, it also copies over all the functions from string.
>

I think we should not call a view a range at all but a kind of container.
=20

>
>
> It looks to me that current researches on ranges suggest that the=20
>> distinction exists (or at least between ranges and containers).
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>On Friday, October 3, 2014 12:54:14 PM UTC-4, 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 dir=3D"ltr"><b=
r><div><br><div class=3D"gmail_quote">On Fri, Oct 3, 2014 at 9:17 AM, Klaim=
 - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"6Tjwpl8fm2QJ" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">mjk...@gmail.com</a>&gt;</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"><div dir=3D"ltr">I think that the most important qu=
estion to answer is: what would be the difference between a range and a vie=
w?=E2=80=8B</div></blockquote><div><br></div><div><div>One major likely dif=
ference is that range =3D=3D will probably be 'shallow'.&nbsp; Deep-compare=
 will probably be a function.<br></div></div></div></div></div></blockquote=
><div><br>I suppose the difference is that a range is a subset of a contain=
er, where as a view is a container itself, that is a non-owning container. =
In this sense a view is not actually a range at all but you can create a ra=
nge over a view for generic algorithm processing. You can also create a vie=
w from a range.<br><br>Since view is a container, operator=3D=3D is deep be=
cause its operating on the container contents. However view is a non-owning=
 container, so operator=3D reassigns it to a new owner. We should have some=
 way to do shallow compare and deep copy for a view.<br>&nbsp;</div><blockq=
uote 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"><div><div class=3D"g=
mail_quote"><div><div>&nbsp;<br></div><div>In general, I think a 'view' is =
this name we use where we'd like to use range, but know that we haven't sol=
idified what we mean by range yet, so we are punting and going with 'view' =
for now.<br></div><br></div><div>Also a view is a less-generic range.&nbsp;=
 ie string_view has more than just range features, it also copies over all =
the functions from string.<br></div></div></div></div></blockquote><div><br=
>I think we should not call a view a range at all but a kind of container.<=
br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div><br></div><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It looks to me that =
current researches on ranges suggest that the distinction exists (or at lea=
st between ranges and containers).</div></div><span><font color=3D"#888888"=
>

<p></p>

-- <br>
<br>
--- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
6Tjwpl8fm2QJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"6Tjwpl8fm2QJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_575_946484599.1412357110388--

.

--089e0160bf984447ba0504884718
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 3, 2014 at 1:25 PM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

>
>
> On Friday, October 3, 2014 12:54:14 PM UTC-4, Tony V E wrote:
>>
>>
>>
>> On Fri, Oct 3, 2014 at 9:17 AM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.=
com>
>> wrote:
>>
>>> I think that the most important question to answer is: what would be th=
e
>>> difference between a range and a view?=E2=80=8B
>>>
>>
>> One major likely difference is that range =3D=3D will probably be 'shall=
ow'.
>> Deep-compare will probably be a function.
>>
>
> I suppose the difference is that a range is a subset of a container, wher=
e
> as a view is a container itself, that is a non-owning container. In this
> sense a view is not actually a range at all but you can create a range ov=
er
> a view for generic algorithm processing. You can also create a view from =
a
> range.
>
> Since view is a container, operator=3D=3D is deep because its operating o=
n the
> container contents. However view is a non-owning container, so operator=
=3D
> reassigns it to a new owner. We should have some way to do shallow compar=
e
> and deep copy for a view.
>
>
>>
>> In general, I think a 'view' is this name we use where we'd like to use
>> range, but know that we haven't solidified what we mean by range yet, so=
 we
>> are punting and going with 'view' for now.
>>
>> Also a view is a less-generic range.  ie string_view has more than just
>> range features, it also copies over all the functions from string.
>>
>
> I think we should not call a view a range at all but a kind of container.
>
>

Of course we are still arguing whether a container is a range...

The biggest issue, in my mind, is that, IIUC, both Range and Container are
Regular.  View is not. ie View is a mix of deep and shallow, whereas both
Range and Container are consistent in their deep/shallow-ness.

Tony

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0160bf984447ba0504884718
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 Fri, Oct 3, 2014 at 1:25 PM, Matthew Fioravante <span dir=3D"ltr">&l=
t;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@=
gmail.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"><div dir=
=3D"ltr"><br><br>On Friday, October 3, 2014 12:54:14 PM UTC-4, Tony V E wro=
te:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><div><br><div class=3D"gmail_quote">On Fri, Oct 3, 2014 at 9:17 AM, K=
laim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a>mjk...@gmail.com</a>&gt;<=
/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"><div dir=
=3D"ltr">I think that the most important question to answer is: what would =
be the difference between a range and a view?=E2=80=8B</div></blockquote><d=
iv><br></div><div><div>One major likely difference is that range =3D=3D wil=
l probably be &#39;shallow&#39;.=C2=A0 Deep-compare will probably be a func=
tion.<br></div></div></div></div></div></blockquote></span><div><br>I suppo=
se the difference is that a range is a subset of a container, where as a vi=
ew is a container itself, that is a non-owning container. In this sense a v=
iew is not actually a range at all but you can create a range over a view f=
or generic algorithm processing. You can also create a view from a range.<b=
r><br>Since view is a container, operator=3D=3D is deep because its operati=
ng on the container contents. However view is a non-owning container, so op=
erator=3D reassigns it to a new owner. We should have some way to do shallo=
w compare and deep copy for a view.<br>=C2=A0</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><div class=3D"gmail_quote"><div><div>=
=C2=A0<br></div><div>In general, I think a &#39;view&#39; is this name we u=
se where we&#39;d like to use range, but know that we haven&#39;t solidifie=
d what we mean by range yet, so we are punting and going with &#39;view&#39=
; for now.<br></div><br></div><div>Also a view is a less-generic range.=C2=
=A0 ie string_view has more than just range features, it also copies over a=
ll the functions from string.<br></div></div></div></div></blockquote><div>=
<br>I think we should not call a view a range at all but a kind of containe=
r.<br>=C2=A0<br></div></div></blockquote><div><br></div><div>Of course we a=
re still arguing whether a container is a range...<br><br></div><div>The bi=
ggest issue, in my mind, is that, IIUC, both Range and Container are Regula=
r.=C2=A0 View is not. ie View is a mix of deep and shallow, whereas both Ra=
nge and Container are consistent in their deep/shallow-ness.<br><br>Tony<br=
></div></div><br><br></div></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160bf984447ba0504884718--

.

On 2014-10-03 01:40, Matthew Fioravante wrote:
> 2) How do we deep copy a view?

std::copy? Given that one of the ideas of a "view" is to be agnostic as
to the underlying storage (e.g. raw array, std::array, std::vector,
etc.), it may or may not make sense to have anything "more direct".

It may make sense to copy data from one view into another, but to me
that feels like std::copy is the correct tool.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_745_896418672.1412360047112
Content-Type: text/plain; charset=UTF-8



On Friday, October 3, 2014 1:44:04 PM UTC-4, Tony V E wrote:
>
>
> Of course we are still arguing whether a container is a range...
>

Maybe its better not to call a container a range but instead say that
container is implicitly convertible to a range. If a container itself is
range, then it has to conform to whatever the range specification is. This
could be problematic and limiting in the future. An iterator is an entirely
separate entity from its parent container. The container only has to
specify a few methods (begin / end) to generate an iterator. The iterator
type itself satisfies the iterator concept. Why not treat the range of a
container in the same way?

If a container is not a range itself, we can define a range in terms of a
container. A range is defined as an object which represents a subset of a
container. For generic algorithms such as sort, any container is easily
convertible to a range which represents the full subset. Maybe you can't
call std::sort(vec), but std::sort(vec.range()) is not too bad. You can
also easily create ranges over strict subsets of the container and process
that, (e.g. std::sort(vec.range(0, 3));)

The only concern for a range is to iterate over the subset and read / write
the members of the set. A view can be used for iteration but in addition it
has its own semantic meaning. Similar to a view, you can shrink a range but
the range can't do anything extra other than iteration, read, and write.
You can also construct new ranges by taking subsets of the original range.

A view on the other hand is a container. It doesn't own the underlying data
but the crucial difference is that the view has its own meaning as a value
type. Consider the difference between a generic range of characters and a
string_view. The first is just a dumb collection, the second has a special
concept of "string". The first can just iterate, read, and write character
bytes. The latter can be formatted, printed, parsed, etc..

Whats interesting from all of this is that string_view and bitset_view seem
to fit the view concept. array_view on the other hand really is a range.
All of the splicing, sectioning, and multi-dimensional chunking are only
ways of specifying how to do iteration on a contiguous buffer. In the end,
the array_view is just a dumb collection of objects which are laid out
contiguously in memory. It doesn't add any new semantics to the collection
like string_view and bitset_view.



> The biggest issue, in my mind, is that, IIUC, both Range and Container are
> Regular.  View is not. ie View is a mix of deep and shallow, whereas both
> Range and Container are consistent in their deep/shallow-ness.
>
> 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Friday, October 3, 2014 1:44:04 PM UTC-4, 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 dir=3D"ltr"><br=
><div><div class=3D"gmail_quote"><div>Of course we are still arguing whethe=
r a container is a range...<br></div></div></div></div></blockquote><div><b=
r>Maybe its better not to call a container a range but instead say that con=
tainer is implicitly convertible to a range. If a container itself is range=
, then it has to conform to whatever the range specification is. This could=
 be problematic and limiting in the future. An iterator is an entirely sepa=
rate entity from its parent container. The container only has to specify a =
few methods (begin / end) to generate an iterator. The iterator type itself=
 satisfies the iterator concept. Why not treat the range of a container in =
the same way?<br><br>If a container is not a range itself, we can define a =
range in terms of a container. A range is defined as an object which repres=
ents a subset of a container. For generic algorithms such as sort, any cont=
ainer is easily convertible to a range which represents the full subset. Ma=
ybe you can't call std::sort(vec), but std::sort(vec.range()) is not too ba=
d. You can also easily create ranges over strict subsets of the container a=
nd process that, (e.g. std::sort(vec.range(0, 3));)<br><br>The only concern=
 for a range is to iterate over the subset and read / write the members of =
the set. A view can be used for iteration but in addition it has its own se=
mantic meaning. Similar to a view, you can shrink a range but the range can=
't do anything extra other than iteration, read, and write. You can also co=
nstruct new ranges by taking subsets of the original range.<br><br>A view o=
n the other hand is a container. It doesn't own the underlying data but the=
 crucial difference is that the view has its own meaning as a value type. C=
onsider the difference between a generic range of characters and a string_v=
iew. The first is just a dumb collection, the second has a special concept =
of "string". The first can just iterate, read, and write character bytes. T=
he latter can be formatted, printed, parsed, etc..<br><br>Whats interesting=
 from all of this is that string_view and bitset_view seem to fit the view =
concept. array_view on the other hand really is a range. All of the splicin=
g, sectioning, and multi-dimensional chunking are only ways of specifying h=
ow to do iteration on a contiguous buffer. In the end, the array_view is ju=
st a dumb collection of objects which are laid out contiguously in memory. =
It doesn't add any new semantics to the collection like string_view and bit=
set_view.<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>The bigge=
st issue, in my mind, is that, IIUC, both Range and Container are Regular.&=
nbsp; View is not. ie View is a mix of deep and shallow, whereas both Range=
 and Container are consistent in their deep/shallow-ness.<br><br>Tony<br></=
div></div><br><br></div></div>
</blockquote></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_745_896418672.1412360047112--

.

------=_Part_5_580271815.1412360214196
Content-Type: text/plain; charset=UTF-8



On Friday, October 3, 2014 2:13:26 PM UTC-4, Matthew Woehlke wrote:
>
>
> std::copy? Given that one of the ideas of a "view" is to be agnostic as
> to the underlying storage (e.g. raw array, std::array, std::vector,
> etc.), it may or may not make sense to have anything "more direct".
>
> It may make sense to copy data from one view into another, but to me
> that feels like std::copy is the correct tool.
>
>
This could work. When you do a std::copy(), you are conceptually converting
the src and dest views into ranges, and then invoking the copy algorithm.

Still, it might be nice to have a built in copy mechanism.

For 2 pointers, you can dereference them and call op=(). Views don't have
any built-in convenience mechanism.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Friday, October 3, 2014 2:13:26 PM UTC-4, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>std::copy=
? Given that one of the ideas of a "view" is to be agnostic as
<br>to the underlying storage (e.g. raw array, std::array, std::vector,
<br>etc.), it may or may not make sense to have anything "more direct".
<br>
<br>It may make sense to copy data from one view into another, but to me
<br>that feels like std::copy is the correct tool.
<br>
<br></blockquote><div><br>This could work. When you do a std::copy(), you a=
re conceptually converting the src and dest views into ranges, and then inv=
oking the copy algorithm. <br><br>Still, it might be nice to have a built i=
n copy mechanism.<br><br>For 2 pointers, you can dereference them and call =
op=3D(). Views don't have any built-in convenience mechanism.<br></div></di=
v>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_580271815.1412360214196--

.

------=_Part_2488_950410295.1412365184935
Content-Type: text/plain; charset=UTF-8

On Friday, October 3, 2014 7:40:02 AM UTC+2, Matthew Fioravante wrote:
>
> With array_view, string_view, and now possibly bitset_view, this view
> thing is becoming contagious.
>
> I think at this stage it makes sense to precisely define exactly what a
> view is and how it behaves as a concept. Any kind of view type that is
> invented now or in the future should adhere to a set of rules so that they
> all have a uniform interface.
>

Boost.Fusion already has a definition for such a concept (
http://www.boost.org/doc/libs/1_56_0/libs/fusion/doc/html/fusion/view.html ):


Views are sequences that do not actually contain data, but instead impart
> an alternative presentation over the data from one or more underlying
> sequences. Views are proxies. They provide an efficient yet purely
> functional way to work on potentially expensive sequence operations. Views
> are inherently lazy. Their elements are only computed on demand only when
> the elements of the underlying sequence(s) are actually accessed. Views'
> lazy nature make them very cheap to copy and be passed around by value.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Friday, October 3, 2014 7:40:02 AM UTC+2, Matthew Fiora=
vante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
ith array_view, string_view, and now possibly bitset_view, this view thing =
is becoming contagious.<div><br></div><div>I think at this stage it makes s=
ense to precisely define exactly what a view is and how it behaves as a con=
cept. Any kind of view type that is invented now or in the future should ad=
here to a set of rules so that they all have a uniform interface.</div></di=
v></blockquote><div><br></div><div>Boost.Fusion already has a definition fo=
r such a concept ( http://www.boost.org/doc/libs/1_56_0/libs/fusion/doc/htm=
l/fusion/view.html&nbsp;):<span style=3D"font-size: 13px;">&nbsp;</span></d=
iv><div><span style=3D"font-size: 13px;"><br></span></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px=
; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-=
left: 1ex;"><span style=3D"color: rgb(0, 0, 0); font-family: sans-serif; fo=
nt-size: 13px; line-height: 15.3333320617676px;">Views are sequences that d=
o not actually contain data, but instead impart an alternative presentation=
 over the data from one or more underlying sequences. Views are proxies. Th=
ey provide an efficient yet purely functional way to work on potentially ex=
pensive sequence operations. Views are inherently lazy. Their elements are =
only computed on demand only when the elements of the underlying sequence(s=
) are actually accessed. Views' lazy nature make them very cheap to copy an=
d be passed around by value.</span></blockquote></div>

<p></p>

-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2488_950410295.1412365184935--

.