------=_Part_67_29128251.1370268471526
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I'm proposing a type I will refer to as "std::sequence" for this discussion=
..

The sequence is a primitive class I have used for years. It is a template:

EX:

 template<class T>
 class sequence {...};


It can be implemented using two member variables:
- A constant pointer to an element of the type specified by the template=20
parameter
- and a constant size_t which represents the number of elements in the arra=
y

EX:

 T* const d_element;
 const size_t d_size;


Like an array, the sequence represents a contiguous allocation of objects.=
=20
However, the sequence is not the owner of the objects. The lifetime of the=
=20
objects and the backing allocation is handled _externally_.

The member functions of the proposed class would be nearly identical to=20
std::array (sizes, element access, iterators). Additionally, std::sequence=
=20
would provide member functions which return slices of the array it=20
represents.

Containers in the standard library which hold contiguous elements could=20
also provide member functions which return a sequence.


The class is useful for combining a dynamically sized contiguous allocation=
=20
with a size parameter.

This can be useful to combine and reduce parameters:

 void foo(int* p, size_t n);
 void foo(std::sequence<int> s);


For abstraction:

 std::vector<int>& elements() {
  return this->vec;
 }


 std::sequence<int> elements() {
  return std::sequence<int>(this->vec);
 }


Unifying parameters template dependence:

From:
 void foo(vector);
 void foo(iterator);
 void foo(int*,size_t);
 template<> void foo(array) {...}


To:
 void foo(sequence);


Avoiding unnecessary promotions/temporaries:
void foo(int* p,size_t n) {
 // looks like I have to create a new vector to pass here=85
 bar(vec);
}

As well as algorithms and general conveniences.

The type requires no change to the language.

I have made the distinction between mutable and immutable sequences in my=
=20
implementation, but I assume the standard library would rather *not* make=
=20
that distinction. Mutability in this regard refers to the elements. Fixed=
=20
size and constant pointer are by design. These objects are generally very=
=20
short lived, rarely member variables, and if a sequence were created using=
=20
`new` it would probably be a programmer error.

I'd like to hear whether or not you would like to have this type in the=20
standard library and if so, how you'd change it (and why).

Thanks

--=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/?hl=3Den.



------=_Part_67_29128251.1370268471526
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div><br></div><div>I'm proposing a type I will refer to as "std::sequence"=
 for this discussion.</div><div><br></div><div>The sequence is a primitive =
class I have used for years. It is a template:</div><div><br></div><div>EX:=
</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250); bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"prett=
yprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> sequence </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{...};</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><div><br><br></div><div>It can=
 be implemented using two member variables:</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>- A constant pointer to an elem=
ent of the type specified by the template parameter</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- and a constant size=
_t which represents the number of elements in the array</div><div><br></div=
><div>EX:</div><div><br></div><div style=3D"background-color: rgb(250, 250,=
 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;T</span><sp=
an 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">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> d_element</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> size_t d_size</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><div><br><br></div><div>Like a=
n array, the sequence represents a contiguous allocation of objects. Howeve=
r, the sequence is not the owner of the objects. The lifetime of the object=
s and the backing allocation is handled _externally_.</div><div><br></div><=
div>The member functions of the proposed class would be nearly identical to=
 std::array (sizes, element access, iterators). Additionally, std::sequence=
 would provide member functions which return slices of the array it represe=
nts.</div><div><br></div><div>Containers in the standard library which hold=
 contiguous elements could also provide member functions which return a seq=
uence.</div><div><br></div><div><br></div><div>The class is useful for comb=
ining a dynamically sized contiguous allocation with a size parameter.</div=
><div><br></div><div>This can be useful to combine and reduce parameters:</=
div><div><br></div><div style=3D"background-color: rgb(250, 250, 250); bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t n=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">sequence</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><div><br><br></div><div>For abstract=
ion:</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250)=
; border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> elements</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><font color=3D"#000000"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">&nbsp; </span></font><span style=3D"color: #008;=
" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">this</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">vec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>&nbsp;=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">sequence</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> elements</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">sequence</span><span style=3D"color: #080;" class=3D"styled=
-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">this</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vec</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><div><br><br></div><div>Unifying parameters template dependence:</div><di=
v><br></div><div>From:</div><div style=3D"background-color: rgb(250, 250, 2=
50); border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
iterator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">*,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">size_t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f=
oo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">array</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: #=
660;" class=3D"styled-by-prettify">{...}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span></div></code></div><div><br><br></=
div><div>To:</div><div><div style=3D"background-color: rgb(250, 250, 250); =
border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">sequence</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></div></code></div><br></div><div><br></di=
v><div>Avoiding unnecessary promotions/temporaries:</div><div style=3D"back=
ground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); wor=
d-wrap: break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">size_t n</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: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// looks like I have to create a new vector to pass here=85</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;bar</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">vec</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span></div></code></div><div><br></div><div>As=
 well as algorithms and general conveniences.</div><div><br></div><div>The =
type requires no change to the language.</div><div><br></div><div>I have ma=
de the distinction between mutable and immutable sequences in my implementa=
tion, but I assume the standard library would rather *not* make that distin=
ction. Mutability in this regard refers to the elements. Fixed size and con=
stant pointer are by design. These objects are generally very short lived, =
rarely member variables, and if a sequence were created using `new` it woul=
d probably be a programmer error.</div><div><br></div><div>I'd like to hear=
 whether or not you would like to have this type in the standard library an=
d if so, how you'd change it (and why).</div><div><br></div><div>Thanks</di=
v><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_67_29128251.1370268471526--

.

------=_Part_160_6651291.1370270410567
Content-Type: text/plain; charset=ISO-8859-1

This looks similar to the array_ref proposal from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html

--

---
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/?hl=en.



------=_Part_160_6651291.1370270410567
Content-Type: text/html; charset=ISO-8859-1

This looks similar to the array_ref proposal from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html<br>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_160_6651291.1370270410567--

.

------=_Part_410_2407091.1370276551780
Content-Type: text/plain; charset=ISO-8859-1


On Monday, June 3, 2013 10:40:10 AM UTC-4, Jonathan Wakely wrote:
>
> This looks similar to the array_ref proposal from
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html


Thanks for pointing that out, Jonathan. There is much similarity to
LLVM's `llvm::ArrayRef and `llvm::MutableArrayRef`, which the array_ref
proposal drew from. I didn't know about the array_ref proposal.

The primary differences between sequences and array_refs are:

   - array_ref elements are immutable. The mutable variant
   (`llvm::MutableArrayRef`) was omitted from the array_ref proposal.
   - sequence elements may be immutable or mutable (similar
   to `llvm::MutableArrayRef`)
   - array_ref provides mutator member functions so that the pointer and
   length of an instance's represented array may be modified (shrunk in place
   from either end or reset).
   - sequences do not provide member or length mutators (as outlined). This
   was by design; it restricts mobility and misuse, while adding some
   opportunity for optimization with the expense that more temporary sequences
   will be created in some scenarios.
   - The array_ref proposal adds string_ref, which is similar to array_ref
   with a few extra member functions for common string operations.

--

---
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/?hl=en.



------=_Part_410_2407091.1370276551780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Monday, June 3, 2013 10:40:10 AM UTC-4, Jonathan Wakely wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">This looks similar to the array_ref =
proposal from <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers=
/2012/n3334.html" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/=
wg21/docs/papers/2012/<wbr>n3334.html</a></blockquote><div><br></div><div>T=
hanks for pointing that out, Jonathan. There is much similarity to LLVM's&n=
bsp;`llvm::ArrayRef and&nbsp;`llvm::MutableArrayRef`, which the array_ref p=
roposal drew from. I didn't know about the array_ref proposal.</div><div><b=
r></div><div>The primary differences between sequences and array_refs are:<=
/div><div><ul><li><span style=3D"line-height: normal;">array_ref elements a=
re immutable. The mutable variant (`llvm::MutableArrayRef`) was omitted fro=
m the array_ref proposal.<br></span></li><li><span style=3D"line-height: no=
rmal;">sequence elements may be immutable or mutable (similar to&nbsp;`llvm=
::MutableArrayRef`)<br></span></li><li><span style=3D"line-height: normal;"=
>array_ref provides mutator member functions so that the pointer and length=
 of an instance's represented array may be modified (shrunk in place from e=
ither end or reset).</span></li><li><span style=3D"line-height: normal; ">s=
equences do not provide member or length mutators&nbsp;(as outlined). This =
was by design; it restricts mobility and misuse, while adding some opportun=
ity for optimization with the expense that more temporary sequences will be=
 created in some scenarios.</span></li><li><span style=3D"line-height: norm=
al; ">The array_ref proposal adds string_ref, which is similar to array_ref=
 with a few extra member functions for common string operations.</span></li=
></ul></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_410_2407091.1370276551780--

.

On Mon, Jun 3, 2013 at 9:22 AM,  <carrierandoperator@yahoo.co.uk> wrote:
>
> On Monday, June 3, 2013 10:40:10 AM UTC-4, Jonathan Wakely wrote:
>>
>> This looks similar to the array_ref proposal from
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html
>
>
> Thanks for pointing that out, Jonathan. There is much similarity to LLVM's
> `llvm::ArrayRef and `llvm::MutableArrayRef`, which the array_ref proposal
> drew from. I didn't know about the array_ref proposal.
>
> The primary differences between sequences and array_refs are:
>
> array_ref elements are immutable. The mutable variant
> (`llvm::MutableArrayRef`) was omitted from the array_ref proposal.
> sequence elements may be immutable or mutable (similar to
> `llvm::MutableArrayRef`)
> array_ref provides mutator member functions so that the pointer and length
> of an instance's represented array may be modified (shrunk in place from
> either end or reset).

> sequences do not provide member or length mutators (as outlined). This was
> by design; it restricts mobility and misuse, while adding some opportunity
> for optimization with the expense that more temporary sequences will be
> created in some scenarios.

So your proposed class is not assignable? That's likely to be a problem.

> The array_ref proposal adds string_ref, which is similar to array_ref with a
> few extra member functions for common string operations.
>
> --
>
> ---
> 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/?hl=en.
>
>

--

---
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/?hl=en.



.

------=_Part_4202_24435037.1370279512501
Content-Type: text/plain; charset=ISO-8859-1

On Monday, June 3, 2013 12:49:03 PM UTC-4, Jeffrey Yasskin wrote:
>
> So your proposed class is not assignable? That's likely to be a problem.
>

Correct. I've gotten by using my implementation for years without need for
assignment. This isn't a type one would normally use as a member variable
or, say, create a std::vector<sequence<int>> of. They are very short lived
and lightweight to construct and copy. Of course, I can be convinced and I
am here hoping to improve it and hear feedback. Thanks.

--

---
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/?hl=en.



------=_Part_4202_24435037.1370279512501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 12:49:03 PM UTC-4, Jeffrey Yasskin wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">So your proposed class is not assignable=
? That's likely to be a problem.
<br></blockquote><div>&nbsp;</div><div>Correct. I've gotten by using my imp=
lementation for years without need for assignment. This isn't a type one wo=
uld normally use as a member variable or, say, create a std::vector&lt;sequ=
ence&lt;int&gt;&gt; of. They are very short lived and lightweight to constr=
uct and copy. Of course, I can be convinced and I am here hoping to improve=
 it and hear feedback. Thanks.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4202_24435037.1370279512501--

.

------=_Part_193_6309805.1370282000667
Content-Type: text/plain; charset=ISO-8859-1

On Monday, June 3, 2013 10:11:52 AM UTC-7, carrieran...@yahoo.co.uk wrote:
>
> On Monday, June 3, 2013 12:49:03 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> So your proposed class is not assignable? That's likely to be a problem.
>>
>
> Correct. I've gotten by using my implementation for years without need for
> assignment. This isn't a type one would normally use as a member variable
> or, say, create a std::vector<sequence<int>> of. They are very short lived
> and lightweight to construct and copy. Of course, I can be convinced and I
> am here hoping to improve it and hear feedback. Thanks.
>

And LLVM and Google have gotten by with types that are equally lightweight
and shortlived, yet *theirs* are assignable and adjustable in size. Why
should we use yours instead of theirs (ie: array_ref)?

--

---
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/?hl=en.



------=_Part_193_6309805.1370282000667
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 10:11:52 AM UTC-7, carrieran...@yahoo.co.uk wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Monday, June 3, 2013 12:49:0=
3 PM UTC-4, Jeffrey Yasskin wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>So your proposed class is not assignable? That's likely to be a problem.
<br></blockquote><div>&nbsp;</div><div>Correct. I've gotten by using my imp=
lementation for years without need for assignment. This isn't a type one wo=
uld normally use as a member variable or, say, create a std::vector&lt;sequ=
ence&lt;int&gt;&gt; of. They are very short lived and lightweight to constr=
uct and copy. Of course, I can be convinced and I am here hoping to improve=
 it and hear feedback. Thanks.</div></blockquote><div><br>And LLVM and Goog=
le have gotten by with types that are equally lightweight and shortlived, y=
et <i>theirs</i> are assignable and adjustable in size. Why should we use y=
ours instead of theirs (ie: array_ref)?<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_193_6309805.1370282000667--

.

--000e0ce0743c80d1dc04de442986
Content-Type: text/plain; charset=ISO-8859-1

On Jun 3, 2013 10:53 AM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Monday, June 3, 2013 10:11:52 AM UTC-7, carrieran...@yahoo.co.uk wrote:
>>
>> On Monday, June 3, 2013 12:49:03 PM UTC-4, Jeffrey Yasskin wrote:
>>>
>>> So your proposed class is not assignable? That's likely to be a
problem.
>>
>>
>> Correct. I've gotten by using my implementation for years without need
for assignment. This isn't a type one would normally use as a member
variable or, say, create a std::vector<sequence<int>> of. They are very
short lived and lightweight to construct and copy. Of course, I can be
convinced and I am here hoping to improve it and hear feedback. Thanks.
>
>
> And LLVM and Google have gotten by with types that are equally
lightweight and shortlived, yet theirs are assignable and adjustable in
size. Why should we use yours instead of theirs (ie: array_ref)?
>

It's always nice to depend on types that have more guarantees as a result
of offering fewer methods. The downside is that such types can't do as
much, so you often run into situations they don't work in.
carrierandoperator's statement that (s)he hasn't in fact run into such
situations is valuable in a way that Google's and LLVM's experience isn't.

I do still think that we should use const iterator_range<const T*> (or a
template alias to that) to represent a continuous range whose bound can't
change, but that doesn't detract from the value of carrierandoperator's
experience.

Jeffrey

--

---
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/?hl=en.



--000e0ce0743c80d1dc04de442986
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Jun 3, 2013 10:53 AM, &quot;Nicol Bolas&quot; &lt;<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Monday, June 3, 2013 10:11:52 AM UTC-7, <a href=3D"mailto:carrieran=
....@yahoo.co.uk">carrieran...@yahoo.co.uk</a> wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Monday, June 3, 2013 12:49:03 PM UTC-4, Jeffrey Yasskin wrote:<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So your proposed class is not assignable? That&#39;s likely to=
 be a problem. <br>
&gt;&gt;<br>
&gt;&gt; =A0<br>
&gt;&gt; Correct. I&#39;ve gotten by using my implementation for years with=
out need for assignment. This isn&#39;t a type one would normally use as a =
member variable or, say, create a std::vector&lt;sequence&lt;int&gt;&gt; of=
.. They are very short lived and lightweight to construct and copy. Of cours=
e, I can be convinced and I am here hoping to improve it and hear feedback.=
 Thanks.<br>

&gt;<br>
&gt;<br>
&gt; And LLVM and Google have gotten by with types that are equally lightwe=
ight and shortlived, yet theirs are assignable and adjustable in size. Why =
should we use yours instead of theirs (ie: array_ref)?<br>
&gt;</p>
<p dir=3D"ltr">It&#39;s always nice to depend on types that have more guara=
ntees as a result of offering fewer methods. The downside is that such type=
s can&#39;t do as much, so you often run into situations they don&#39;t wor=
k in. carrierandoperator&#39;s statement that (s)he hasn&#39;t in fact run =
into such situations is valuable in a way that Google&#39;s and LLVM&#39;s =
experience isn&#39;t.</p>

<p dir=3D"ltr">I do still think that we should use const iterator_range&lt;=
const T*&gt; (or a template alias to that) to represent a continuous range =
whose bound can&#39;t change, but that doesn&#39;t detract from the value o=
f carrierandoperator&#39;s experience.</p>

<p dir=3D"ltr">Jeffrey</p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--000e0ce0743c80d1dc04de442986--

.

------=_Part_966_20379093.1370291052467
Content-Type: text/plain; charset=ISO-8859-1



> And LLVM and Google have gotten by with types that are equally lightweight
> and shortlived, yet *theirs* are assignable and adjustable in size. Why
> should we use yours instead of theirs (ie: array_ref)?
>

Yet, in the (unfortunately rejected and thrown to abyss) proposal, there is
no mutable version of the class provided. That makes it at least one reason
to (maybe) reconsider it.

Personally, I am against allowing assignment. What do you think most users
would expect from the following code?:

void foo(mutable_array_ref<int> a, array_ref<int> b)
{
   a = b;
   ...
}

Was the intent of the user to copy-assign the elements from b to a? That is
not what will happen. Yet, most users will expect to use an array_ref just
the same way they would use a container/range. And not only users: template
code as well.

So unless one can provide actual use cases for assignment operator, I don't
think it would be a good idea to provide one since it could be misleading.

--

---
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/?hl=en.



------=_Part_966_20379093.1370291052467
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>And LLVM and Google h=
ave gotten by with types that are equally lightweight and shortlived, yet <=
i>theirs</i> are assignable and adjustable in size. Why should we use yours=
 instead of theirs (ie: array_ref)?<br></div></blockquote><div><br></div><d=
iv>Yet, in the (unfortunately rejected and thrown to abyss) proposal, there=
 is no mutable version of the class provided. That makes it at least one re=
ason to (maybe) reconsider it.</div><div><br></div><div>Personally, I am ag=
ainst allowing assignment. What do you think most users would expect from t=
he following code?:</div><div><br></div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">mutable_array_ref</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> array_ref</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;a </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></di=
v></code></div><div><br></div><div>Was the intent of the user to copy-assig=
n the elements from b to a? That is not what will happen. Yet, most users w=
ill expect to use an array_ref just the same way they would use a container=
/range. And not only users: template code as well.</div><div><br></div><div=
>So unless one can provide actual use cases for assignment operator, I don'=
t think it would be a good idea to provide one since it could be misleading=
..</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_966_20379093.1370291052467--

.

------=_Part_4336_17924660.1370291094024
Content-Type: text/plain; charset=ISO-8859-1

On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:
>
> And LLVM and Google have gotten by with types that are equally lightweight
> and shortlived, yet *theirs* are assignable and adjustable in size.
>

I chose to use const members because restrictions, guarantees, and focusing
on the essence of the problem are good things.

Most of us would answer "Yes" to the following questions: Are there times
when a reference can be used rather than a pointer? Are there times when it
is a good idea to favor a reference? Are there times when const could be
used? And are there times when it is a good idea to favor using const?

re Short lived: Making the type assignable affords greater scope to people.
Not everyone will misuse that, but some will. I see it as being quite
similar to SBRM and favoring local types. The sequence should be a
dependency of the array/allocation it references. If you expand the scope
and increase the sequence's lifetime, then the likelihood that somebody
uses a dangling pointer increases (as one example).

re Lightweight: The smallest array_ref could be the same size as a
sequence. Because array_ref's members are not const, it could result in
larger and slower code. Making it assignable and shrinkable introduces
complexity to the type (e.g. more error detection, more methods, more code
paths, more to test).

Shrinking did not exist in my proposal because I never needed that
functionality. I was content with the guarantees the type provided and its
simplicity. The type did not attempt to be an iterator, range, or scanner
as well. I've found slicing quite effective.

The other issue in giving sequence the ability to be shrunk in combination
with permitting access to mutable elements is that mutability to both the
size and the elements is passed. Suppose you pass a character sequence to
be capitalized -- the capitalize implementation can capitalize the string
and accidentally shrink your sequence because mutability of the container
and its elements are mutual. When the members are const, you could always
pass a sequence by value. If they are not const, passing sequences becomes
more complex.



Why should we use yours instead of theirs (ie: array_ref)?


I did a side-by-side comparison before you asked. To answer the question:
Even if you took both proposals as-is, I would favor sequence because the
option to have mutable array elements is more useful than assignment and
shrinking. Again, I can be convinced those are necessities.


--

---
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/?hl=en.



------=_Part_4336_17924660.1370291094024
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div>And LLVM and Google have gotten by with =
types that are equally lightweight and shortlived, yet <i>theirs</i> are as=
signable and adjustable in size.<br></div></blockquote><div><br></div><div>=
I chose to use const members because restrictions, guarantees, and focusing=
 on the essence of the problem are good things.</div><div><br></div><div>Mo=
st of us would answer "Yes" to the following questions: Are there times whe=
n a reference can be used rather than a pointer? Are there times when it is=
 a good idea to favor a reference? Are there times when const could be used=
? And are there times when it is a good idea to favor using const?<br></div=
><div><br></div><div>re Short lived: Making the type assignable affords gre=
ater scope to people. Not everyone will misuse that, but some will. I see i=
t as being quite similar to SBRM and favoring local types. The sequence sho=
uld be a dependency of the array/allocation it references. If you expand th=
e scope and increase the sequence's lifetime, then the likelihood that some=
body uses a dangling pointer increases (as one example).</div><div><br></di=
v><div>re Lightweight: The smallest array_ref could be the same size as a s=
equence. Because array_ref's members are not const, it could result in larg=
er and slower code. Making it assignable and shrinkable introduces complexi=
ty to the type (e.g. more error detection, more methods, more code paths, m=
ore to test).</div><div><br></div><div>Shrinking did not exist in my propos=
al because I never needed that functionality. I was content with the guaran=
tees the type provided and its simplicity. The type did not attempt to be a=
n iterator, range, or scanner as well. I've found slicing quite effective.<=
/div><div><br></div><div><div>The other issue in giving sequence the abilit=
y to be shrunk in combination with permitting access to mutable elements is=
 that mutability to both the size and the elements is passed. Suppose you p=
ass a character sequence to be capitalized -- the capitalize implementation=
 can capitalize the string and accidentally shrink your sequence because mu=
tability of the container and its elements are mutual. When the members are=
 const, you could always pass a sequence by value. If they are not const, p=
assing sequences becomes more complex.</div></div><div><br></div><div><br><=
/div><div><br></div><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; ">Why should we use yo=
urs instead of theirs (ie: array_ref)?</blockquote><div><br></div><div>I di=
d a side-by-side comparison before you asked. To answer the question: Even =
if you took both proposals as-is, I would favor sequence because the option=
 to have mutable array elements is more useful than assignment and shrinkin=
g. Again, I can be convinced those are necessities.</div></div><div><br></d=
iv><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4336_17924660.1370291094024--

.

--001a11c35e1ef4b45104de45c86d
Content-Type: text/plain; charset=ISO-8859-1

On 3 June 2013 15:24, Alex B <devalexb@gmail.com> wrote:

>
> And LLVM and Google have gotten by with types that are equally lightweight
>> and shortlived, yet *theirs* are assignable and adjustable in size. Why
>> should we use yours instead of theirs (ie: array_ref)?
>>
>
> Yet, in the (unfortunately rejected and thrown to abyss) proposal, there
> is no mutable version of the class provided. That makes it at least one
> reason to (maybe) reconsider it.
>
> Personally, I am against allowing assignment.
>


What about this code:

map<int, array_ref<int>> m;

m[1] = get_array();

Breaking assignment pretty much breaks expectations.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c35e1ef4b45104de45c86d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 3 June 2013 15:24, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And LLVM=
 and Google have gotten by with types that are equally lightweight and shor=
tlived, yet <i>theirs</i> are assignable and adjustable in size. Why should=
 we use yours instead of theirs (ie: array_ref)?<br>

</div></blockquote><div><br></div></div><div>Yet, in the (unfortunately rej=
ected and thrown to abyss) proposal, there is no mutable version of the cla=
ss provided. That makes it at least one reason to (maybe) reconsider it.</d=
iv>

<div><br></div><div>Personally, I am against allowing assignment.</div></bl=
ockquote><div><br><br>What about this code:<br><br>map&lt;int, array_ref&lt=
;int&gt;&gt; m;<br><br>m[1] =3D get_array();<br clear=3D"all"></div></div>
<br>
Breaking assignment pretty much breaks expectations.<br>-- <br>=A0Nevin &qu=
ot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c35e1ef4b45104de45c86d--

.

------=_Part_594_22645181.1370291902731
Content-Type: text/plain; charset=ISO-8859-1


On Monday, June 3, 2013 4:26:12 PM UTC-4, Nevin ":-)" Liber wrote:
>
>
> What about this code:
>
> map<int, array_ref<int>> m;
>
> m[1] = get_array();
>
> Breaking assignment pretty much breaks expectations.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404


I mentioned it's not a type I use in collections. It may help to think of
it as an adaptor rather than a self-sufficient collection.

--

---
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/?hl=en.



------=_Part_594_22645181.1370291902731
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Monday, June 3, 2013 4:26:12 PM UTC-4, Nevin ":-)" Liber wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><div><br=
>What about this code:<br><br>map&lt;int, array_ref&lt;int&gt;&gt; m;<br><b=
r>m[1] =3D get_array();<br clear=3D"all"></div></div>
<br>
Breaking assignment pretty much breaks expectations.<br>-- <br>&nbsp;Nevin =
":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"l608S8GTcxAJ">ne...@eviloverlord.com</a><wbr>&gt;&nbsp=
; (847) 691-1404</blockquote><div><br></div><div>I mentioned it's not a typ=
e I use in collections. It may help to think of it as an adaptor rather tha=
n a self-sufficient collection.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_594_22645181.1370291902731--

.

------=_Part_721_8046597.1370292078688
Content-Type: text/plain; charset=ISO-8859-1


>
> I do still think that we should use const iterator_range<const T*> (or a
> template alias to that) to represent a continuous range whose bound can't
> change,
>

That sounds like the long term solution to me (considering it part of a
broader range support) while array_ref/sequence could solve it in a much
shorter term *without *getting in the way of a future iterator_range (if it
ever gets added).

We have had std::pair for a long time and it did not prevent generalizing
(std::tuple).

--

---
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/?hl=en.



------=_Part_721_8046597.1370292078688
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><span style=3D"line-height: 18=
px;">I do still think that we should use const iterator_range&lt;const T*&g=
t; (or a template alias to that) to represent a continuous range whose boun=
d can't change,&nbsp;</span><br></blockquote><div><br></div><div>That sound=
s like the long term solution to me (considering it part of a broader range=
 support) while array_ref/sequence could solve it in a much shorter term <b=
>without </b>getting in the way of a future iterator_range (if it ever gets=
 added).</div><div><br></div><div>We have had std::pair for a long time and=
 it did not prevent generalizing (std::tuple).</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_721_8046597.1370292078688--

.

------=_Part_2654_24847219.1370292426166
Content-Type: text/plain; charset=ISO-8859-1



> m[1] = get_array();
>

That's exactly the kind of use case that might not be interpreted properly.
Some (if not most) users will wrongly assume that the elements will be
copied.

What about:

m[1].rebind(get_array());

--

---
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/?hl=en.



------=_Part_2654_24847219.1370292426166
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"=
><div>m[1] =3D get_array();<br clear=3D"all"></div></div>
</blockquote><div><br></div><div>That's exactly the kind of use case that m=
ight not be interpreted properly. Some (if not most) users will wrongly ass=
ume that the elements will be copied.</div><div><br></div><div>What about:<=
br></div><div><br></div><div>m[1].rebind(get_array());</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2654_24847219.1370292426166--

.

On Mon, Jun 3, 2013 at 1:41 PM, Alex B <devalexb@gmail.com> wrote:
>> I do still think that we should use const iterator_range<const T*> (or a
>> template alias to that) to represent a continuous range whose bound can't
>> change,
>
>
> That sounds like the long term solution to me (considering it part of a
> broader range support) while array_ref/sequence could solve it in a much
> shorter term without getting in the way of a future iterator_range (if it
> ever gets added).

SG9 is active and will have a proposal for iterator_range in Chicago.
If LWG allows that proposal into a TS, that's just as fast as any
array_ref/sequence could get in. On the other hand, if LWG holds up
iterator_range until "broader range support" is ready (which I think
would be crazy but might happen), then they're just as likely to hold
up array_ref for the same amount of time.

> We have had std::pair for a long time and it did not prevent generalizing
> (std::tuple).
>
> --
>
> ---
> 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/?hl=en.
>
>

--

---
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/?hl=en.



.

--20cf306f750ccdddbe04de461af6
Content-Type: text/plain; charset=ISO-8859-1

On 3 June 2013 15:47, Alex B <devalexb@gmail.com> wrote:

>
> m[1] = get_array();
>>
>
> That's exactly the kind of use case that might not be interpreted
> properly. Some (if not most) users will wrongly assume that the elements
> will be copied.
>
> What about:
>
> m[1].rebind(get_array());
>

Is it any more error prone than std::reference_wrapper?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--20cf306f750ccdddbe04de461af6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 3 June 2013 15:47, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div=
>m[1] =3D get_array();<br clear=3D"all"></div></div>
</blockquote><div><br></div><div>That&#39;s exactly the kind of use case th=
at might not be interpreted properly. Some (if not most) users will wrongly=
 assume that the elements will be copied.</div><div><br></div><div>What abo=
ut:<br>


</div><div><br></div><div>m[1].rebind(get_array());<br clear=3D"all"></div>=
</blockquote><div><br>Is it any more error prone than std::reference_wrappe=
r? <br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" =
target=3D"_blank">(847) 691-1404</a>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf306f750ccdddbe04de461af6--

.

------=_Part_3233_4213805.1370298764450
Content-Type: text/plain; charset=ISO-8859-1

On Monday, June 3, 2013 1:26:12 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 3 June 2013 15:24, Alex B <deva...@gmail.com <javascript:>> wrote:
>
>>
>> And LLVM and Google have gotten by with types that are equally
>>> lightweight and shortlived, yet *theirs* are assignable and adjustable
>>> in size. Why should we use yours instead of theirs (ie: array_ref)?
>>>
>>
>> Yet, in the (unfortunately rejected and thrown to abyss) proposal, there
>> is no mutable version of the class provided. That makes it at least one
>> reason to (maybe) reconsider it.
>>
>> Personally, I am against allowing assignment.
>>
>
>
> What about this code:
>
> map<int, array_ref<int>> m;
>
> m[1] = get_array();
>
> Breaking assignment pretty much breaks expectations.


I agree with your general sentiment, just not the example code you give.
The idea of storing a short-term array_ref/etc in a long-term object like a
`map` is... disconcerting.

--

---
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/?hl=en.



------=_Part_3233_4213805.1370298764450
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 1:26:12 PM UTC-7, Nevin ":-)" Liber wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On 3 June 2013 15:24, Alex B <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"l608S8GTcxAJ">deva...@gmail.com</a>&gt;</span> wrote:<br><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><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And LLVM and Google h=
ave gotten by with types that are equally lightweight and shortlived, yet <=
i>theirs</i> are assignable and adjustable in size. Why should we use yours=
 instead of theirs (ie: array_ref)?<br>

</div></blockquote><div><br></div></div><div>Yet, in the (unfortunately rej=
ected and thrown to abyss) proposal, there is no mutable version of the cla=
ss provided. That makes it at least one reason to (maybe) reconsider it.</d=
iv>

<div><br></div><div>Personally, I am against allowing assignment.</div></bl=
ockquote><div><br><br>What about this code:<br><br>map&lt;int, array_ref&lt=
;int&gt;&gt; m;<br><br>m[1] =3D get_array();<br clear=3D"all"></div></div>
<br>
Breaking assignment pretty much breaks expectations.</blockquote><div><br>I=
 agree with your general sentiment, just not the example code you give. The=
 idea of storing a short-term array_ref/etc in a long-term object like a `m=
ap` is... disconcerting.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3233_4213805.1370298764450--

.

--e89a8f923b36f1039404de479eb5
Content-Type: text/plain; charset=ISO-8859-1

On 3 June 2013 17:32, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> I agree with your general sentiment, just not the example code you give.
> The idea of storing a short-term array_ref/etc in a long-term object like a
> `map` is... disconcerting.
>

How is that any different than storing a pointer?

If you need reference semantics, you shouldn't have to go through hoops
just to get them, because those hoops are going to be far worse (calling
deleters/placement new, using optional, etc.).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8f923b36f1039404de479eb5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 3 June 2013 17:32, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><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">

<br><div>I agree with your general sentiment, just not the example code you=
 give. The idea of storing a short-term array_ref/etc in a long-term object=
 like a `map` is... disconcerting.<br></div></blockquote><div><br>How is th=
at any different than storing a pointer?<br>

<br>If you need reference semantics, you shouldn&#39;t have to go through h=
oops just to get them, because those hoops are going to be far worse (calli=
ng deleters/placement new, using optional, etc.).<br clear=3D"all"></div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f923b36f1039404de479eb5--

.

------=_Part_3241_2880306.1370299175608
Content-Type: text/plain; charset=ISO-8859-1

On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:
>
> On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:
>>
>> And LLVM and Google have gotten by with types that are equally
>> lightweight and shortlived, yet *theirs* are assignable and adjustable
>> in size.
>>
>
> I chose to use const members because restrictions, guarantees, and
> focusing on the essence of the problem are good things.
>
> Most of us would answer "Yes" to the following questions: Are there times
> when a reference can be used rather than a pointer? Are there times when it
> is a good idea to favor a reference? Are there times when const could be
> used? And are there times when it is a good idea to favor using const?
>
> re Short lived: Making the type assignable affords greater scope to
> people. Not everyone will misuse that, but some will. I see it as being
> quite similar to SBRM and favoring local types. The sequence should be a
> dependency of the array/allocation it references. If you expand the scope
> and increase the sequence's lifetime, then the likelihood that somebody
> uses a dangling pointer increases (as one example).
>



re Lightweight: The smallest array_ref could be the same size as a
> sequence. Because array_ref's members are not const, it could result in
> larger and slower code.
>

.... how? They'll just be a pair of pointers or a pointer+size either way.


> Making it assignable and shrinkable introduces complexity to the type
> (e.g. more error detection, more methods, more code paths, more to test).
>

More code paths of *what* to test? If your particular function won't be
changing the array_ref, then it should be a `const array_ref`.

Shrinking did not exist in my proposal because I never needed that
> functionality. I was content with the guarantees the type provided and its
> simplicity. The type did not attempt to be an iterator, range, or scanner
> as well. I've found slicing quite effective.
>

I don't really see how that's an argument, especially considering again
that Google and LLVM *do* need this functionality. They didn't write those
functions just because they could. Does your class get as much usage as all
internal Google and LLVM C++ projects? If not, then I would rather defer to
the guys who have the usage experience.

--

---
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/?hl=en.



------=_Part_3241_2880306.1370299175608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Monday, June 3, 2013 1:53:20 =
PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>An=
d LLVM and Google have gotten by with types that are equally lightweight an=
d shortlived, yet <i>theirs</i> are assignable and adjustable in size.<br><=
/div></blockquote><div><br></div><div>I chose to use const members because =
restrictions, guarantees, and focusing on the essence of the problem are go=
od things.</div><div><br></div><div>Most of us would answer "Yes" to the fo=
llowing questions: Are there times when a reference can be used rather than=
 a pointer? Are there times when it is a good idea to favor a reference? Ar=
e there times when const could be used? And are there times when it is a go=
od idea to favor using const?<br></div><div><br></div><div>re Short lived: =
Making the type assignable affords greater scope to people. Not everyone wi=
ll misuse that, but some will. I see it as being quite similar to SBRM and =
favoring local types. The sequence should be a dependency of the array/allo=
cation it references. If you expand the scope and increase the sequence's l=
ifetime, then the likelihood that somebody uses a dangling pointer increase=
s (as one example).</div></blockquote><div><br><br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div>re Lightweight: The smallest array_ref =
could be the same size as a sequence. Because array_ref's members are not c=
onst, it could result in larger and slower code.</div></blockquote><div><br=
>... how? They'll just be a pair of pointers or a pointer+size either way.<=
br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Making it =
assignable and shrinkable introduces complexity to the type (e.g. more erro=
r detection, more methods, more code paths, more to test).</div></blockquot=
e><div><br>More code paths of <i>what</i> to test? If your particular funct=
ion won't be changing the array_ref, then it should be a `const array_ref`.=
<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;"><div>Shrinking d=
id not exist in my proposal because I never needed that functionality. I wa=
s content with the guarantees the type provided and its simplicity. The typ=
e did not attempt to be an iterator, range, or scanner as well. I've found =
slicing quite effective.</div></blockquote><div><br>I don't really see how =
that's an argument, especially considering again that Google and LLVM <i>do=
</i> need this functionality. They didn't write those functions just becaus=
e they could. Does your class get as much usage as all internal Google and =
LLVM C++ projects? If not, then I would rather defer to the guys who have t=
he usage experience.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3241_2880306.1370299175608--

.

------=_Part_177_18976384.1370356079480
Content-Type: text/plain; charset=ISO-8859-1



On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
>
> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:
>>
>> On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:
>>>
>>> And LLVM and Google have gotten by with types that are equally
>>> lightweight and shortlived, yet *theirs* are assignable and adjustable
>>> in size.
>>>
>>
>> I chose to use const members because restrictions, guarantees, and
>> focusing on the essence of the problem are good things.
>>
>> Most of us would answer "Yes" to the following questions: Are there times
>> when a reference can be used rather than a pointer? Are there times when it
>> is a good idea to favor a reference? Are there times when const could be
>> used? And are there times when it is a good idea to favor using const?
>>
>> re Short lived: Making the type assignable affords greater scope to
>> people. Not everyone will misuse that, but some will. I see it as being
>> quite similar to SBRM and favoring local types. The sequence should be a
>> dependency of the array/allocation it references. If you expand the scope
>> and increase the sequence's lifetime, then the likelihood that somebody
>> uses a dangling pointer increases (as one example).
>>
>
>
>
> re Lightweight: The smallest array_ref could be the same size as a
>> sequence. Because array_ref's members are not const, it could result in
>> larger and slower code.
>>
>
> ... how? They'll just be a pair of pointers or a pointer+size either way.
>

So you have checked my math. What exactly is your question?



> Making it assignable and shrinkable introduces complexity to the type
>> (e.g. more error detection, more methods, more code paths, more to test).
>>
>
> More code paths of *what* to test? If your particular function won't be
> changing the array_ref, then it should be a `const array_ref`.
>

These aren't real questions. It seems you're just trying to start an
argument. I've the assumption that if you are hanging out in a C++ standard
proposal group, you have some understanding of software complexity.



> Shrinking did not exist in my proposal because I never needed that
>> functionality. I was content with the guarantees the type provided and its
>> simplicity. The type did not attempt to be an iterator, range, or scanner
>> as well. I've found slicing quite effective.
>>
>
> I don't really see how that's an argument, especially considering again
> that Google and LLVM *do* need this functionality. They didn't write
> those functions just because they could. Does your class get as much usage
> as all internal Google and LLVM C++ projects? If not, then I would rather
> defer to the guys who have the usage experience.
>

Since explaining this to you, endorsement comes out as the heart of your
objection? You need to realize that there is a call for library proposals
and that this is the forum for such proposals: "The door is open for
submissions of features to be added to the standard library, and we would
love to see them not only from existing community libraries like Boost,
Poco, and Qt, but from *you*.". <http://isocpp.org/std/submit-a-proposal> Proposals
don't need your endorsement watchdogging. Let's stay squarely on topic.

--

---
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/?hl=en.



------=_Part_177_18976384.1370356079480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Monday, June 3, 2013 1:24:54 PM UT=
C-7, <a>carrieran...@yahoo.co.uk</a> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div>And LLVM and Google have gotten by wi=
th types that are equally lightweight and shortlived, yet <i>theirs</i> are=
 assignable and adjustable in size.<br></div></blockquote><div><br></div><d=
iv>I chose to use const members because restrictions, guarantees, and focus=
ing on the essence of the problem are good things.</div><div><br></div><div=
>Most of us would answer "Yes" to the following questions: Are there times =
when a reference can be used rather than a pointer? Are there times when it=
 is a good idea to favor a reference? Are there times when const could be u=
sed? And are there times when it is a good idea to favor using const?<br></=
div><div><br></div><div>re Short lived: Making the type assignable affords =
greater scope to people. Not everyone will misuse that, but some will. I se=
e it as being quite similar to SBRM and favoring local types. The sequence =
should be a dependency of the array/allocation it references. If you expand=
 the scope and increase the sequence's lifetime, then the likelihood that s=
omebody uses a dangling pointer increases (as one example).</div></blockquo=
te><div><br><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>re L=
ightweight: The smallest array_ref could be the same size as a sequence. Be=
cause array_ref's members are not const, it could result in larger and slow=
er code.</div></blockquote><div><br>... how? They'll just be a pair of poin=
ters or a pointer+size either way.<br></div></blockquote><div><br></div><di=
v>So you have checked my math. What exactly is your question?</div><div><br=
></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>Making it assignable and shrinkable =
introduces complexity to the type (e.g. more error detection, more methods,=
 more code paths, more to test).</div></blockquote><div><br>More code paths=
 of <i>what</i> to test?&nbsp;If your particular function won't be changing=
 the array_ref, then it should be a `const array_ref`.</div></blockquote><d=
iv><br></div><div>These aren't real questions. It seems you're just trying =
to start an argument. I've the assumption that if you are hanging out in a =
C++ standard proposal group, you have some understanding of software comple=
xity.</div><div>&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Shrinking did n=
ot exist in my proposal because I never needed that functionality. I was co=
ntent with the guarantees the type provided and its simplicity. The type di=
d not attempt to be an iterator, range, or scanner as well. I've found slic=
ing quite effective.</div></blockquote><div><br>I don't really see how that=
's an argument, especially considering again that Google and LLVM <i>do</i>=
 need this functionality. They didn't write those functions just because th=
ey could. Does your class get as much usage as all internal Google and LLVM=
 C++ projects? If not, then I would rather defer to the guys who have the u=
sage experience.<br></div></blockquote><div><br></div><div>Since explaining=
 this to you, endorsement comes out as the heart of your objection? You nee=
d to realize that there is a call for library proposals and that this is th=
e forum for such proposals: <a href=3D"http://isocpp.org/std/submit-a-propo=
sal">"The door is open for submissions of features to be added to the stand=
ard library, and we would love to see them not only from existing community=
 libraries like Boost, Poco, and Qt, but from <i>you</i>.".</a>&nbsp;Propos=
als don't need your endorsement watchdogging. Let's stay squarely on topic.=
</div><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_177_18976384.1370356079480--

.

--f46d04446a93e7896e04de55d8e1
Content-Type: text/plain; charset=ISO-8859-1

On 4 June 2013 17:27, <carrierandoperator@yahoo.co.uk> wrote:

>
> I don't really see how that's an argument, especially considering again
>> that Google and LLVM *do* need this functionality. They didn't write
>> those functions just because they could. Does your class get as much usage
>> as all internal Google and LLVM C++ projects? If not, then I would rather
>> defer to the guys who have the usage experience.
>>
>
> Since explaining this to you, endorsement comes out as the heart of your
> objection? You need to realize that there is a call for library proposals
> and that this is the forum for such proposals: "The door is open for
> submissions of features to be added to the standard library, and we would
> love to see them not only from existing community libraries like Boost,
> Poco, and Qt, but from *you*.". <http://isocpp.org/std/submit-a-proposal> Proposals
> don't need your endorsement watchdogging. Let's stay squarely on topic.
>
>
>
At any rate, a proposal that's based on something that has wide user
experience has a better chance
at making it into the standard. A proposal that's loosely similar to such
existing practice but significantly
different benefits from having a section describing such differences and
their rationale.

This forum, however, is not an official feedback channel. Then again,
Nevin, Jeffrey and Jonathan
(and myself) are committee members, so I would recommend taking their
feedback seriously.

--

---
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/?hl=en.



--f46d04446a93e7896e04de55d8e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 June 2013 17:27,  <span dir=3D"ltr">&lt;<a href=3D"mailto:carr=
ierandoperator@yahoo.co.uk" target=3D"_blank">carrierandoperator@yahoo.co.u=
k</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div>I don&#39;t really see how that&#39;s an argument, especially consider=
ing again that Google and LLVM <i>do</i> need this functionality. They didn=
&#39;t write those functions just because they could. Does your class get a=
s much usage as all internal Google and LLVM C++ projects? If not, then I w=
ould rather defer to the guys who have the usage experience.<br>
</div></blockquote><div><br></div></div><div>Since explaining this to you, =
endorsement comes out as the heart of your objection? You need to realize t=
hat there is a call for library proposals and that this is the forum for su=
ch proposals: <a href=3D"http://isocpp.org/std/submit-a-proposal" target=3D=
"_blank">&quot;The door is open for submissions of features to be added to =
the standard library, and we would love to see them not only from existing =
community libraries like Boost, Poco, and Qt, but from <i>you</i>.&quot;.</=
a>=A0Proposals don&#39;t need your endorsement watchdogging. Let&#39;s stay=
 squarely on topic.</div>
<div class=3D"HOEnZb"><div class=3D"h5"><div><br><br></div></div></div></bl=
ockquote><div><br></div><div>At any rate, a proposal that&#39;s based on so=
mething that has wide user experience has a better chance<br></div><div>at =
making it into the standard. A proposal that&#39;s loosely similar to such =
existing practice but significantly<br>
different benefits from having a section describing such differences and th=
eir rationale.<br><br></div><div>This forum, however, is not an official fe=
edback channel. Then again, Nevin, Jeffrey and Jonathan<br>(and myself) are=
 committee members, so I would recommend taking their feedback seriously. <=
br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d04446a93e7896e04de55d8e1--

.

--047d7bdc18880739e704de578baa
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 4, 2013 at 11:27 AM, <carrierandoperator@yahoo.co.uk> wrote:

>
> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
>>
>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:
>>
>
[snip]


>  re Lightweight: The smallest array_ref could be the same size as a
>>> sequence. Because array_ref's members are not const, it could result in
>>> larger and slower code.
>>>
>>
>> ... how? They'll just be a pair of pointers or a pointer+size either way.
>>
>
> So you have checked my math. What exactly is your question?
>

The question seems to be "how [would array_ref's members not const be
larger and slower]?". Or to put a better way: how would your sequence be
smaller or faster than an array_ref. I wonder myself the same question.

[snip]

Regards,
--
Felipe Magno de Almeida

--

---
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/?hl=en.



--047d7bdc18880739e704de578baa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 4, 2013 at 11:27 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:carri=
erandoperator@yahoo.co.uk" target=3D"_blank">carrierandoperator@yahoo.co.uk=
</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>On Monday, June 3, 201=
3 6:39:35 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">

On Monday, June 3, 2013 1:24:54 PM UTC-7, <a>carrieran...@yahoo.co.uk</a> w=
rote:<br></blockquote></div></blockquote><div><br></div><div>[snip]<br></di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div>re Lightweight: The smallest array_ref could be the same size as a seq=
uence. Because array_ref&#39;s members are not const, it could result in la=
rger and slower code.</div></blockquote><div><br>... how? They&#39;ll just =
be a pair of pointers or a pointer+size either way.<br>

</div></blockquote><div><br></div></div><div>So you have checked my math. W=
hat exactly is your question?</div></blockquote><div><br></div><div>The que=
stion seems to be &quot;how [would array_ref&#39;s members not const be lar=
ger and slower]?&quot;. Or to put a better way: how would your sequence be =
smaller or faster than an array_ref. I wonder myself the same question.<br>

</div><div><br></div><div>[snip]<br><br></div></div>Regards,<br></div><div =
class=3D"gmail_extra">-- <br>Felipe Magno de Almeida
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc18880739e704de578baa--

.

------=_Part_3970_25767685.1370371303582
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, June 4, 2013 7:27:59 AM UTC-7, carrieran...@yahoo.co.uk wrote:
>
> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
>>
>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:
>>
>>> re Lightweight: The smallest array_ref could be the same size as a
>>> sequence. Because array_ref's members are not const, it could result in
>>> larger and slower code.
>>>
>>
>> ... how? They'll just be a pair of pointers or a pointer+size either way.
>>
>
> So you have checked my math. What exactly is your question?
>

Felipe covered this one, but I'll reiterate. You claimed that array_ref's
members not being `const` would make code "larger and slower". How? In what
cases could that possibly happen?

Shrinking did not exist in my proposal because I never needed that
>>> functionality. I was content with the guarantees the type provided and its
>>> simplicity. The type did not attempt to be an iterator, range, or scanner
>>> as well. I've found slicing quite effective.
>>>
>>
>> I don't really see how that's an argument, especially considering again
>> that Google and LLVM *do* need this functionality. They didn't write
>> those functions just because they could. Does your class get as much usage
>> as all internal Google and LLVM C++ projects? If not, then I would rather
>> defer to the guys who have the usage experience.
>>
>
> Since explaining this to you, endorsement comes out as the heart of your
> objection?
>

No, the heart of my objections are these:

1: The committee already saw a proposal that was similar to what you
suggest. A proposal that was rejected (for reasons that I find dubious, but
nevermind that now).

2: Your proposal is not different enough from the rejected one to likely
gain any traction with the committee. Especially over the solution that
many committee members apparently prefer (ie: wait for ranges/traversal/etc
and hope that *they* solve the problem).

3: Your proposal, when compared to the rejected one, is a needless step
backwards. The standard must serve more needs than just your own. While the
fact that you haven't needed to modify these "sequences" is interesting,
the fact that *other* people clearly do have that need outweighs that. And
most notably, the apparently committee-preferred solution (ie:
iterator_range) is quite mutable, if it's based on the boost::iterator_range<http://www.boost.org/doc/libs/1_53_0/libs/range/doc/html/range/reference/utilities/iterator_range.html>.
So that's LLVM, Google, *and* Boost, all of whom think mutability is
important.

You need to realize that there is a call for library proposals and that
> this is the forum for such proposals: "The door is open for submissions
> of features to be added to the standard library, and we would love to see
> them not only from existing community libraries like Boost, Poco, and Qt,
> but from *you*.". <http://isocpp.org/std/submit-a-proposal> Proposals
> don't need your endorsement watchdogging. Let's stay squarely on topic.
>

This forum is for commentary on proposals and inquiry on proposals, so as
to either fix issues in proposals (like not being able to modify the
object) or to otherwise refine them and make them better before proposing
them. Not agreeing with commentary does not make that commentary invalid.

I'm not stopping you from writing up a proposal and submitting it. But I'm
not going to pretend that I think it would be a worthwhile use of the
committee's time debating and voting on it either, compared to either
getting array_ref back or the apparently committee preferred solution.

--

---
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/?hl=en.



------=_Part_3970_25767685.1370371303582
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 7:27:59 AM UTC-7, carrieran...@yahoo.co.uk wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Monday, June 3, 2013 6:39:35=
 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon=
day, June 3, 2013 1:24:54 PM UTC-7, <a>carrieran...@yahoo.co.uk</a> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>re Lightweight: The smalles=
t array_ref could be the same size as a sequence. Because array_ref's membe=
rs are not const, it could result in larger and slower code.</div></blockqu=
ote><div><br>... how? They'll just be a pair of pointers or a pointer+size =
either way.<br></div></blockquote><div><br></div><div>So you have checked m=
y math. What exactly is your question?</div></blockquote><div><br>Felipe co=
vered this one, but I'll reiterate. You claimed that array_ref's members no=
t being `const` would make code "larger and slower". How? In what cases cou=
ld that possibly happen?<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div>Shrinking did not exist in my proposal because I never ne=
eded that functionality. I was content with the guarantees the type provide=
d and its simplicity. The type did not attempt to be an iterator, range, or=
 scanner as well. I've found slicing quite effective.</div></blockquote><di=
v><br>I don't really see how that's an argument, especially considering aga=
in that Google and LLVM <i>do</i> need this functionality. They didn't writ=
e those functions just because they could. Does your class get as much usag=
e as all internal Google and LLVM C++ projects? If not, then I would rather=
 defer to the guys who have the usage experience.<br></div></blockquote><di=
v><br></div><div>Since explaining this to you, endorsement comes out as the=
 heart of your objection?</div></blockquote><div><br>No, the heart of my ob=
jections are these:<br><br>1: The committee already saw a proposal that was=
 similar to what you suggest. A proposal that was rejected (for reasons tha=
t I find dubious, but nevermind that now).<br><br>2: Your proposal is not d=
ifferent enough from the rejected one to likely gain any traction with the =
committee. Especially over the solution that many committee members apparen=
tly prefer (ie: wait for ranges/traversal/etc and hope that <i>they</i> sol=
ve the problem).<br><br>3: Your proposal, when compared to the rejected one=
, is a needless step backwards. The standard must serve more needs than jus=
t your own. While the fact that you haven't needed to modify these "sequenc=
es" is interesting, the fact that <i>other</i> people clearly do have that =
need outweighs that. And most notably, the apparently committee-preferred s=
olution (ie: iterator_range) is quite mutable, if it's based on the <a href=
=3D"http://www.boost.org/doc/libs/1_53_0/libs/range/doc/html/range/referenc=
e/utilities/iterator_range.html">boost::iterator_range</a>. So that's LLVM,=
 Google, <i>and</i> Boost, all of whom think mutability is important.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>You need to reali=
ze that there is a call for library proposals and that this is the forum fo=
r such proposals: <a href=3D"http://isocpp.org/std/submit-a-proposal" targe=
t=3D"_blank">"The door is open for submissions of features to be added to t=
he standard library, and we would love to see them not only from existing c=
ommunity libraries like Boost, Poco, and Qt, but from <i>you</i>.".</a>&nbs=
p;Proposals don't need your endorsement watchdogging. Let's stay squarely o=
n topic.</div></blockquote><div><br>This forum is for commentary on proposa=
ls and inquiry on proposals, so as to either fix issues in proposals (like =
not being able to modify the object) or to otherwise refine them and make t=
hem better before proposing them. Not agreeing with commentary does not mak=
e that commentary invalid.<br><br>I'm not stopping you from writing up a pr=
oposal and submitting it. But I'm not going to pretend that I think it woul=
d be a worthwhile use of the committee's time debating and voting on it eit=
her, compared to either getting array_ref back or the apparently committee =
preferred solution.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3970_25767685.1370371303582--

.

On Tue, Jun 4, 2013 at 11:41 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> While the
> fact that you haven't needed to modify these "sequences" is interesting, the
> fact that other people clearly do have that need outweighs that.

Please don't say "clearly" here. Assignability is the default in C++,
and it's quite possible that our implementations stumbled into it
without actually having a firm use case. It would take actual research
to determine that we have a real need. (I suspect we do, but my
suspicion doesn't prove anything, and I'm not currently planning to
investigate in detail.)

--

---
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/?hl=en.



.

--001a11c2b55cc1245404de58bdf6
Content-Type: text/plain; charset=ISO-8859-1

On 4 June 2013 13:54, Jeffrey Yasskin <jyasskin@google.com> wrote:

>
> Please don't say "clearly" here. Assignability is the default in C++,
> and it's quite possible that our implementations stumbled into it
> without actually having a firm use case. It would take actual research
> to determine that we have a real need. (I suspect we do, but my
> suspicion doesn't prove anything, and I'm not currently planning to
> investigate in detail.)
>

Other than dynarray, is there any class in the standard that is copyable
but not assignable?

And I'm a bit worried about dynarray, as I suspect more than a few people
are going to try mostly working "destruct then placement new" abomination
to get around it.  Of course, I didn't think of that in Bristol, and a
clean hack circumventing the issue is optional<dynarray<T>>, but I
digress...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2b55cc1245404de58bdf6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 4 June 2013 13:54, Jeffrey Yasskin <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jyasskin@google.com" target=3D"_blank">jyasskin@google.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br>
</div>Please don&#39;t say &quot;clearly&quot; here. Assignability is the d=
efault in C++,<br>
and it&#39;s quite possible that our implementations stumbled into it<br>
without actually having a firm use case. It would take actual research<br>
to determine that we have a real need. (I suspect we do, but my<br>
suspicion doesn&#39;t prove anything, and I&#39;m not currently planning to=
<br>
investigate in detail.)<br></blockquote><div><br>Other than dynarray, is th=
ere any class in the standard that is copyable but not assignable?<br><br>A=
nd I&#39;m a bit worried about dynarray, as I suspect more than a few peopl=
e are going to try mostly working &quot;destruct then placement new&quot; a=
bomination to get around it.=A0 Of course, I didn&#39;t think of that in Br=
istol, and a clean hack circumventing the issue is optional&lt;dynarray&lt;=
T&gt;&gt;, but I digress...<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2b55cc1245404de58bdf6--

.

--089e0158c302d6dc2904de597968
Content-Type: text/plain; charset=ISO-8859-1

Or you could just use std::copy to copy elements from one dynarray to
another. That sounds like a clean way to do it for dynarrays and isn't a
hack.

Making dynarray assignable would only allow even more "clean hacks" like
the one you mentionned. For example, it would indirectly allow the dynarray
to be resized (which goes against the idea of dynarray):

template <class T>
void ResizeDynArray(dynarray<T>& d, size_t s)
{
   dynarray<T> temp{s};
   copy_n(d.begin(), min(d.size(), s), temp.begin());
   d = temp;
}


On Tue, Jun 4, 2013 at 3:03 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 June 2013 13:54, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
>>
>> Please don't say "clearly" here. Assignability is the default in C++,
>> and it's quite possible that our implementations stumbled into it
>> without actually having a firm use case. It would take actual research
>> to determine that we have a real need. (I suspect we do, but my
>> suspicion doesn't prove anything, and I'm not currently planning to
>> investigate in detail.)
>>
>
> Other than dynarray, is there any class in the standard that is copyable
> but not assignable?
>
> And I'm a bit worried about dynarray, as I suspect more than a few people
> are going to try mostly working "destruct then placement new" abomination
> to get around it.  Of course, I didn't think of that in Bristol, and a
> clean hack circumventing the issue is optional<dynarray<T>>, but I
> digress...
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/ECVE9Dq1vn0/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e0158c302d6dc2904de597968
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>Or you could just use std::copy to copy element=
s from one dynarray to another. That sounds like a clean way to do it for d=
ynarrays and isn&#39;t a hack.</div><div><br></div>Making dynarray assignab=
le would only allow even more &quot;clean hacks&quot; like the one you ment=
ionned. For example, it would indirectly allow the dynarray to be resized (=
which goes against the idea of dynarray):<div>
<br></div><div style><font face=3D"courier new, monospace">template &lt;cla=
ss T&gt;</font></div><div style><font face=3D"courier new, monospace">void =
ResizeDynArray(dynarray&lt;T&gt;&amp; d, size_t s)</font></div><div style><=
font face=3D"courier new, monospace">{</font></div>
<div style><font face=3D"courier new, monospace">=A0 =A0dynarray&lt;T&gt; t=
emp{s};</font></div><div style><font face=3D"courier new, monospace">=A0 =
=A0copy_n(<font color=3D"#000000"><span style=3D"line-height:15.59375px">d.=
begin(), min(d.size(), s), temp.begin());</span></font></font></div>
<div style><font color=3D"#000000" face=3D"courier new, monospace"><span st=
yle=3D"line-height:15.59375px">=A0 =A0d =3D temp;</span></font></div><div s=
tyle><font face=3D"courier new, monospace">}</font></div></div><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Tue, Jun 4, 2013 at 3:03 PM, Nevin Li=
ber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im">On 4 June 2013 13:54, Jeffrey Yasskin <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jyasskin@google.com" target=3D"_blank">jyasskin@google=
..com</a>&gt;</span> wrote:<br></div><div class=3D"gmail_quote"><div class=
=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">


<div><br>
</div>Please don&#39;t say &quot;clearly&quot; here. Assignability is the d=
efault in C++,<br>
and it&#39;s quite possible that our implementations stumbled into it<br>
without actually having a firm use case. It would take actual research<br>
to determine that we have a real need. (I suspect we do, but my<br>
suspicion doesn&#39;t prove anything, and I&#39;m not currently planning to=
<br>
investigate in detail.)<br></blockquote></div><div><br>Other than dynarray,=
 is there any class in the standard that is copyable but not assignable?<br=
><br>And I&#39;m a bit worried about dynarray, as I suspect more than a few=
 people are going to try mostly working &quot;destruct then placement new&q=
uot; abomination to get around it.=A0 Of course, I didn&#39;t think of that=
 in Bristol, and a clean hack circumventing the issue is optional&lt;dynarr=
ay&lt;T&gt;&gt;, but I digress...<br>


</div></div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18=
476911404" target=3D"_blank">(847) 691-1404</a>

<p></p></div>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ECVE9Dq1vn0/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/EC=
VE9Dq1vn0/unsubscribe?hl=3Den</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0158c302d6dc2904de597968--

.

On Tue, Jun 4, 2013 at 12:03 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 4 June 2013 13:54, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>>
>> Please don't say "clearly" here. Assignability is the default in C++,
>> and it's quite possible that our implementations stumbled into it
>> without actually having a firm use case. It would take actual research
>> to determine that we have a real need. (I suspect we do, but my
>> suspicion doesn't prove anything, and I'm not currently planning to
>> investigate in detail.)
>
>
> Other than dynarray, is there any class in the standard that is copyable but
> not assignable?

I don't think so. The consistency there is enough that Gaby got the
terminology wrong when suggesting that standard containers should
support (some) non-assignable types.

IMO, that's a fine sort of argument, and one I agree with. I was only
commenting on Nicol's attempt to use Google's and LLVM's experience
inappropriately.

Jeffrey

--

---
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/?hl=en.



.

2013/6/4 Jeffrey Yasskin <jyasskin@google.com>:
> On Tue, Jun 4, 2013 at 12:03 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> On 4 June 2013 13:54, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>>
>>>
>>> Please don't say "clearly" here. Assignability is the default in C++,
>>> and it's quite possible that our implementations stumbled into it
>>> without actually having a firm use case. It would take actual research
>>> to determine that we have a real need. (I suspect we do, but my
>>> suspicion doesn't prove anything, and I'm not currently planning to
>>> investigate in detail.)
>>
>>
>> Other than dynarray, is there any class in the standard that is copyable but
>> not assignable?
>
> I don't think so.

I agree with Jeffrey. In C++03 std::valarray was not assignable in the
absolute sense: If both operands had different sizes, the behaviour
was undefined. But we changed this for C++11. I'm not convinced that
dynarray is comparable to valarray enough to argue in favour for
allowing assignments based on this data point, though. It looks like a
potential option for the future, but I really would like to see
practical experience with dynarray first, especially whether existing
implementations will show that allowing relaxing the current
assignment constraint would be harmless or not.

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



.

--51ae6aee_643c9869_8d5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On June 4, 2013 at 11:36:43 AM, Ville Voutilainen (ville.voutilainen@gmail.=
com) wrote:

On 4 June 2013 17:27,=A0<carrierandoperator@yahoo.co.uk>=A0wrote:

I don't really see how that's an argument, especially considering again tha=
t Google and LLVM do need this functionality. They didn't write those funct=
ions just because they could. Does your class get as much usage as all inte=
rnal Google and LLVM C++ projects? If not, then I would rather defer to the=
 guys who have the usage experience.

Since explaining this to you, endorsement comes out as the heart of your ob=
jection? You need to realize that there is a call for library proposals and=
 that this is the forum for such proposals: "The door is open for submissio=
ns of features to be added to the standard library, and we would love to se=
e them not only from existing community libraries like Boost, Poco, and Qt,=
 but from you.".=A0Proposals don't need your endorsement watchdogging. Let'=
s stay squarely on topic.



At any rate, a proposal that's based on something that has wide user experi=
ence has a better chance
at making it into the standard. A proposal that's loosely similar to such e=
xisting practice but significantly
different benefits from having a section describing such differences and th=
eir rationale.

This forum, however, is not an official feedback channel. Then again, Nevin=
, Jeffrey and Jonathan
(and myself) are committee members, so I would recommend taking their feedb=
ack seriously. =20

I do appreciate all constructive criticism I have received regarding sequen=
ces, by the way.

I can add a section which compares sequences and array_refs to my next iter=
ation of the floated proposal.

After reviewing my implementation, I have decided it is most logical to kee=
p it as two types; one for mutable array elements and one for immutable. It=
 will (likely) be a few days until I get that update out.

Cheers

--
j.carlson

--=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/?hl=3Den.



--51ae6aee_643c9869_8d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; "><p id=3D"bloop_customfont"=
 style=3D"font-family:Helvetica,Arial;font-size:13px; margin: 0px; line-hei=
ght: auto;"><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span style=
=3D"color: rgb(160, 160, 168); ">On June 4, 2013 at 11:36:43 AM, Ville Vout=
ilainen (ville.voutilainen@gmail.com) wrote:</span></p></p> <div><div><bloc=
kquote type=3D"cite" style=3D"color: rgb(0, 0, 0); font-family: helvetica; =
font-size: 13px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -=
webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-s=
troke-width: 0px; background-color: rgb(255, 255, 255); border-left-style: =
solid; border-width: 1px; margin-left: 0px; padding-left: 10px; "><span><di=
v dir=3D"ltr"><div class=3D"gmail_extra">On 4 June 2013 17:27,&nbsp;<span d=
ir=3D"ltr">&lt;<a href=3D"mailto:carrierandoperator@yahoo.co.uk" target=3D"=
_blank">carrierandoperator@yahoo.co.uk</a>&gt;</span>&nbsp;wrote:<br><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 20=
4); border-left-style: solid; padding-left: 1ex; "><br><div class=3D"im"><b=
lockquote 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; "><div>I don't really see how that's an argument,=
 especially considering again that Google and LLVM<span class=3D"Apple-conv=
erted-space">&nbsp;</span><i>do</i><span class=3D"Apple-converted-space">&n=
bsp;</span>need this functionality. They didn't write those functions just =
because they could. Does your class get as much usage as all internal Googl=
e and LLVM C++ projects? If not, then I would rather defer to the guys who =
have the usage experience.<br></div></blockquote><div><br></div></div><div>=
Since explaining this to you, endorsement comes out as the heart of your ob=
jection? You need to realize that there is a call for library proposals and=
 that this is the forum for such proposals:<span class=3D"Apple-converted-s=
pace">&nbsp;</span><a href=3D"http://isocpp.org/std/submit-a-proposal" targ=
et=3D"_blank">"The door is open for submissions of features to be added to =
the standard library, and we would love to see them not only from existing =
community libraries like Boost, Poco, and Qt, but from<span class=3D"Apple-=
converted-space">&nbsp;</span><i>you</i>.".</a>&nbsp;Proposals don't need y=
our endorsement watchdogging. Let's stay squarely on topic.</div><div class=
=3D"HOEnZb"><div class=3D"h5"><div><br><br></div></div></div></blockquote><=
div><br></div><div>At any rate, a proposal that's based on something that h=
as wide user experience has a better chance<br></div><div>at making it into=
 the standard. A proposal that's loosely similar to such existing practice =
but significantly<br>different benefits from having a section describing su=
ch differences and their rationale.<br><br></div><div>This forum, however, =
is not an official feedback channel. Then again, Nevin, Jeffrey and Jonatha=
n<br>(and myself) are committee members, so I would recommend taking their =
feedback seriously.<span class=3D"Apple-converted-space">&nbsp;</span></div=
></div></div></div></span></blockquote></div><p><br></p><p>I do appreciate =
all constructive criticism I have received regarding sequences, by the way.=
</p><p><p id=3D"bloop_customfont" style=3D"margin: 0px; ">I can add a secti=
on which compares sequences and array_refs to my next iteration of the floa=
ted proposal.</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><br></p=
><p id=3D"bloop_customfont" style=3D"margin: 0px; ">After reviewing my impl=
ementation, I have decided it is most logical to keep it as two types; one =
for mutable array elements and one for immutable. It will (likely) be a few=
 days until I get that update out.</p><p id=3D"bloop_customfont" style=3D"m=
argin: 0px; "><br></p><p id=3D"bloop_customfont" style=3D"margin: 0px; ">Ch=
eers</p><p></p><div id=3D"bloop_sign_1370384691625122048">--<br>j.carlson</=
div><div id=3D"bloop_sign_1370384691625122048"><br></div></p><div></div></d=
iv></body></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--51ae6aee_643c9869_8d5--

.

--51ae6e0b_3d1b58ba_8d5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida (felipe.m.almeida@gm=
ail.com) wrote:
On Tue, Jun 4, 2013 at 11:27 AM, <carrierandoperator@yahoo.co.uk> wrote:

On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:

[snip]
=A0
re Lightweight: The smallest array_ref could be the same size as a sequence=
.. Because array_ref's members are not const, it could result in larger and =
slower code.

.... how? They'll just be a pair of pointers or a pointer+size either way.

So you have checked my math. What exactly is your question?

The question seems to be "how [would array_ref's members not const be large=
r and slower]?". Or to put a better way: how would your sequence be smaller=
 or faster than an array_ref. I wonder myself the same question.

[snip]

Regards,
-- =20
Felipe Magno de Almeida


Ok, to quickly summarize the "Lightweight" conversation inline:

 Me: (initial float)
 Jeffrey: So your proposed class is not assignable? That's likely to be a p=
roblem.
 Me: =85They are very short lived and lightweight to construct and copy=85
 Nicol: And LLVM and Google have gotten by with types that are equally ligh=
tweight and shortlived, yet theirs are assignable and adjustable in size. W=
hy should we use yours instead of theirs (ie: array_ref)?
 Me: The smallest array_ref could be the same size as a sequence. Because a=
rray_ref's members are not const, it could result in larger and slower code=
..
 Nicol: how? They'll just be a pair of pointers or a pointer+size either wa=
y.

So my initial statement that sequences are lightweight was with no comparis=
on to array_ref. I then concurred that the object size of sequences and arr=
ay_refs should be identical after a comparison was made to array_ref. The r=
eason I hinted they may not *ultimately* be equal in size is that there are=
 open considerations regarding array_ref which could affect layout (but lik=
ely would not affect size).

The difference I noted when comparing sequence vs array_ref with relation t=
o being "Lightweight" is that it can result in a larger and slower binary (=
but the big benefit over array_ref is that mutable elements are supported).=
 This difference I mentioned isn't going to a revolutionary difference, mer=
ely a measurable difference in some scenarios. I'm also assuming you all fi=
gure this won't result in a great difference in speed (that was never my cl=
aim when making the comparison).

The differences I have touched on in this discussion so far are:
 - array_ref's size() may change
 - array_ref's pointer may change
 - For these reasons and because of the required additional mutators and sc=
affolding methods, the proposed array_ref has a higher overall complexity t=
han sequences.

Without spending hours creating tests, comparing generated assembly, and pr=
ofiling using multiple compilers and platforms - these complexity increases=
 could result in:
 - more exported symbols
 - larger class bodies
 - greater build and link times
 - more reads and writes necessary. include cases where execution is out of=
 the optimizer's visibility.
 - more instructions
 - more branching
 - more variables for an optimizer to track
 - reduced locality. sequences generally maintain very close locality.
 - and consequently less likely to be a good optimization or inline candida=
te

I suspect there won't be additional overhead in many scenarios, particularl=
y where locality is minimized.

--
j.carlson

--=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/?hl=3Den.



--51ae6e0b_3d1b58ba_8d5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; "><p id=3D"bloop_customfont"=
 style=3D"font-family:Helvetica,Arial;font-size:13px; margin: 0px; line-hei=
ght: auto;"><p id=3D"bloop_customfont" style=3D"margin: 0px; "><br></p></p>=
<div id=3D"bloop_sign_1370385402473277184"><br></div><p style=3D"color:#A0A=
0A8;">On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida (felipe.m.alme=
ida@gmail.com) wrote:</p> <div><div><blockquote type=3D"cite" style=3D"colo=
r: rgb(0, 0, 0); font-family: helvetica; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color=
: rgb(255, 255, 255); border-left-style: solid; border-width: 1px; margin-l=
eft: 0px; padding-left: 10px; "><span><div><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote">On Tue, Jun 4, 2013 at 11:27 AM,<spa=
n class=3D"Apple-converted-space">&nbsp;</span><span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:carrierandoperator@yahoo.co.uk" target=3D"_blank">carrierandope=
rator@yahoo.co.uk</a>&gt;</span><span class=3D"Apple-converted-space">&nbsp=
;</span>wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204);=
 border-left-style: solid; padding-left: 1ex; "><div class=3D"im"><br>On Mo=
nday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; b=
order-left-color: rgb(204, 204, 204); border-left-style: solid; padding-lef=
t: 1ex; ">On Monday, June 3, 2013 1:24:54 PM UTC-7,<span class=3D"Apple-con=
verted-space">&nbsp;</span><a>carrieran...@yahoo.co.uk</a><span class=3D"Ap=
ple-converted-space">&nbsp;</span>wrote:<br></blockquote></div></blockquote=
><div><br></div><div>[snip]<br></div><div>&nbsp;</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bo=
rder-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left=
: 1ex; "><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex; "><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; "><div>re Lightweight: The smallest array_ref could be the same =
size as a sequence. Because array_ref's members are not const, it could res=
ult in larger and slower code.</div></blockquote><div><br>... how? They'll =
just be a pair of pointers or a pointer+size either way.<br></div></blockqu=
ote><div><br></div></div><div>So you have checked my math. What exactly is =
your question?</div></blockquote><div><br></div><div>The question seems to =
be "how [would array_ref's members not const be larger and slower]?". Or to=
 put a better way: how would your sequence be smaller or faster than an arr=
ay_ref. I wonder myself the same question.<br></div><div><br></div><div>[sn=
ip]<br><br></div></div>Regards,<br></div><div class=3D"gmail_extra">--<span=
 class=3D"Apple-converted-space">&nbsp;</span><br>Felipe Magno de Almeida</=
div></div></div></span></blockquote></div><p><p id=3D"bloop_customfont" sty=
le=3D"font-family: Helvetica, Arial; margin: 0px; "></p><p id=3D"bloop_cust=
omfont" style=3D"margin: 0px; ">Ok, to quickly summarize the "Lightweight" =
conversation inline:</p><p id=3D"bloop_customfont" style=3D"margin: 0px; ">=
<br></p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>Me: (initial float)</p><p =
id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre"> </span>Jeffrey: So your proposed class is no=
t assignable? That's likely to be a problem.</p><p id=3D"bloop_customfont" =
style=3D"margin: 0px; "><span class=3D"Apple-tab-span" style=3D"white-space=
:pre"> </span>Me: =85They are very short lived and lightweight to construct=
 and copy=85</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Nicol: And LLVM an=
d Google have gotten by with types that are equally lightweight and shortli=
ved, yet theirs are assignable and adjustable in size. Why should we use yo=
urs instead of theirs (ie: array_ref)?</p><p id=3D"bloop_customfont" style=
=3D"margin: 0px; "><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
> </span>Me: The smallest array_ref could be the same size as a sequence. B=
ecause array_ref's members are not const, it could result in larger and slo=
wer code.</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>Nicol: how? They'll j=
ust be a pair of pointers or a pointer+size either way.</p><p id=3D"bloop_c=
ustomfont" style=3D"margin: 0px; "><br></p><p id=3D"bloop_customfont" style=
=3D"margin: 0px; ">So my initial statement that sequences are lightweight w=
as with no comparison to array_ref. I then concurred that the object size o=
f sequences and array_refs should be identical after a comparison was made =
to array_ref. The reason I hinted they may not *ultimately* be equal in siz=
e is that there are open considerations regarding array_ref which could aff=
ect layout (but likely would not affect size).</p><p id=3D"bloop_customfont=
" style=3D"margin: 0px; "><br></p><p id=3D"bloop_customfont" style=3D"margi=
n: 0px; ">The difference I noted when comparing sequence vs array_ref with =
relation to being "Lightweight" is that it can result in a larger and slowe=
r binary (but the big benefit over array_ref is that mutable elements are s=
upported). This difference I mentioned isn't going to a revolutionary diffe=
rence, merely a measurable difference in some scenarios. I'm also assuming =
you all figure this won't result in a great difference in speed (that was n=
ever my claim when making the comparison).</p><p id=3D"bloop_customfont" st=
yle=3D"margin: 0px; "><br></p><p id=3D"bloop_customfont" style=3D"margin: 0=
px; ">The differences I have touched on in this discussion so far are:</p><=
p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>- array_ref's size() may change</p>=
<p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>- array_ref's pointer may change</=
p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>- For these reasons and because =
of the required additional mutators and scaffolding methods, the proposed a=
rray_ref has a higher overall complexity than sequences.</p><p id=3D"bloop_=
customfont" style=3D"margin: 0px; "><br></p><p id=3D"bloop_customfont" styl=
e=3D"margin: 0px; ">Without spending hours creating tests, comparing genera=
ted assembly, and profiling using multiple compilers and platforms - these =
complexity increases could result in:</p><p id=3D"bloop_customfont" style=
=3D"margin: 0px; "><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
> </span>- more exported symbols</p><p id=3D"bloop_customfont" style=3D"mar=
gin: 0px; "><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </spa=
n>- larger class bodies</p><p id=3D"bloop_customfont" style=3D"margin: 0px;=
 "><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- great=
er build and link times</p><p id=3D"bloop_customfont" style=3D"margin: 0px;=
 "><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- more =
reads and writes necessary. include cases where execution is out of the opt=
imizer's visibility.</p><p id=3D"bloop_customfont" style=3D"margin: 0px; ">=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- more ins=
tructions</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- more branching</p><=
p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>- more variables for an optimizer t=
o track</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- reduced locality. s=
equences generally maintain very close locality.</p><p id=3D"bloop_customfo=
nt" style=3D"margin: 0px; "><span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>- and consequently less likely to be a good optimization =
or inline candidate</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><=
br></p><p id=3D"bloop_customfont" style=3D"margin: 0px; ">I suspect there w=
on't be additional overhead in many scenarios, particularly where locality =
is minimized.</p><p id=3D"bloop_customfont" style=3D"margin: 0px; "><br></p=
><div>--</div><div id=3D"bloop_sign_1370385402473277184">j.carlson</div><di=
v id=3D"bloop_sign_1370385402473277184"><br></div></p><div></div></div></bo=
dy></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--51ae6e0b_3d1b58ba_8d5--

.

On Tue, Jun 4, 2013 at 3:45 PM, j.carlson
<carrierandoperator@yahoo.co.uk> wrote:
>
>
> On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida
> (felipe.m.almeida@gmail.com) wrote:
>
> On Tue, Jun 4, 2013 at 11:27 AM, <carrierandoperator@yahoo.co.uk> wrote:
>>
>>
>> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
>>>
>>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrot=
e:
>
>
> [snip]
>
>>>>
>>>> re Lightweight: The smallest array_ref could be the same size as a
>>>> sequence. Because array_ref's members are not const, it could result i=
n
>>>> larger and slower code.
>>>
>>>
>>> ... how? They'll just be a pair of pointers or a pointer+size either wa=
y.
>>
>>
>> So you have checked my math. What exactly is your question?
>
>
> The question seems to be "how [would array_ref's members not const be lar=
ger
> and slower]?". Or to put a better way: how would your sequence be smaller=
 or
> faster than an array_ref. I wonder myself the same question.
>
> [snip]
>
> Regards,
> --
> Felipe Magno de Almeida
>
> Ok, to quickly summarize the "Lightweight" conversation inline:
>
>
> Me: (initial float)
>
> Jeffrey: So your proposed class is not assignable? That's likely to be a
> problem.
>
> Me: =85They are very short lived and lightweight to construct and copy=85
>
> Nicol: And LLVM and Google have gotten by with types that are equally
> lightweight and shortlived, yet theirs are assignable and adjustable in
> size. Why should we use yours instead of theirs (ie: array_ref)?
>
> Me: The smallest array_ref could be the same size as a sequence. Because
> array_ref's members are not const, it could result in larger and slower
> code.
>
> Nicol: how? They'll just be a pair of pointers or a pointer+size either w=
ay.
>
>
> So my initial statement that sequences are lightweight was with no
> comparison to array_ref. I then concurred that the object size of sequenc=
es
> and array_refs should be identical after a comparison was made to array_r=
ef.
> The reason I hinted they may not *ultimately* be equal in size is that th=
ere
> are open considerations regarding array_ref which could affect layout (bu=
t
> likely would not affect size).
>
>
> The difference I noted when comparing sequence vs array_ref with relation=
 to
> being "Lightweight" is that it can result in a larger and slower binary (=
but
> the big benefit over array_ref is that mutable elements are supported). T=
his
> difference I mentioned isn't going to a revolutionary difference, merely =
a
> measurable difference in some scenarios. I'm also assuming you all figure
> this won't result in a great difference in speed (that was never my claim
> when making the comparison).
>
>
> The differences I have touched on in this discussion so far are:
>
> - array_ref's size() may change
>
> - array_ref's pointer may change
>
> - For these reasons and because of the required additional mutators and
> scaffolding methods, the proposed array_ref has a higher overall complexi=
ty
> than sequences.
>
>
> Without spending hours creating tests, comparing generated assembly, and
> profiling using multiple compilers and platforms - these complexity
> increases could result in:
>
> - more exported symbols
>
> - larger class bodies
>
> - greater build and link times
>
> - more reads and writes necessary. include cases where execution is out o=
f
> the optimizer's visibility.
>
> - more instructions
>
> - more branching
>
> - more variables for an optimizer to track
>
> - reduced locality. sequences generally maintain very close locality.
>
> - and consequently less likely to be a good optimization or inline candid=
ate
>
>
> I suspect there won't be additional overhead in many scenarios, particula=
rly
> where locality is minimized.

Yeah, you might see a performance difference for non-const
array_ref<>s where the compiler can't assume they don't change. If
users see that, they can create const array_ref<>s instead. Is there a
difference between const array_ref<>s and sequence<>s?

--=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/?hl=3Den.



.

------=_Part_1036_11401103.1370387584888
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 4, 2013 2:41:43 PM UTC-4, Nicol Bolas wrote:
>
> On Tuesday, June 4, 2013 7:27:59 AM UTC-7, carrieran...@yahoo.co.uk wrote:
>>
>> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:
>>>
>>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.ukwrote:
>>>
>>>> re Lightweight: The smallest array_ref could be the same size as a
>>>> sequence. Because array_ref's members are not const, it could result in
>>>> larger and slower code.
>>>>
>>>
>>> ... how? They'll just be a pair of pointers or a pointer+size either way.
>>>
>>
>> So you have checked my math. What exactly is your question?
>>
>
> Felipe covered this one, but I'll reiterate. You claimed that array_ref's
> members not being `const` would make code "larger and slower". How? In what
> cases could that possibly happen?
>
> Shrinking did not exist in my proposal because I never needed that
>>>> functionality. I was content with the guarantees the type provided and its
>>>> simplicity. The type did not attempt to be an iterator, range, or scanner
>>>> as well. I've found slicing quite effective.
>>>>
>>>
>>> I don't really see how that's an argument, especially considering again
>>> that Google and LLVM *do* need this functionality. They didn't write
>>> those functions just because they could. Does your class get as much usage
>>> as all internal Google and LLVM C++ projects? If not, then I would rather
>>> defer to the guys who have the usage experience.
>>>
>>
>> Since explaining this to you, endorsement comes out as the heart of your
>> objection?
>>
>
> No, the heart of my objections are these:
>
> 1: The committee already saw a proposal that was similar to what you
> suggest. A proposal that was rejected (for reasons that I find dubious, but
> nevermind that now).
>
> 2: Your proposal is not different enough from the rejected one to likely
> gain any traction with the committee. Especially over the solution that
> many committee members apparently prefer (ie: wait for ranges/traversal/etc
> and hope that *they* solve the problem).
>
> 3: Your proposal, when compared to the rejected one, is a needless step
> backwards. The standard must serve more needs than just your own. While the
> fact that you haven't needed to modify these "sequences" is interesting,
> the fact that *other* people clearly do have that need outweighs that.
> And most notably, the apparently committee-preferred solution (ie:
> iterator_range) is quite mutable, if it's based on the
> boost::iterator_range<http://www.boost.org/doc/libs/1_53_0/libs/range/doc/html/range/reference/utilities/iterator_range.html>.
> So that's LLVM, Google, *and* Boost, all of whom think mutability is
> important.
>
> You need to realize that there is a call for library proposals and that
>> this is the forum for such proposals: "The door is open for submissions
>> of features to be added to the standard library, and we would love to see
>> them not only from existing community libraries like Boost, Poco, and Qt,
>> but from *you*.". <http://isocpp.org/std/submit-a-proposal> Proposals
>> don't need your endorsement watchdogging. Let's stay squarely on topic.
>>
>
> This forum is for commentary on proposals and inquiry on proposals, so as
> to either fix issues in proposals (like not being able to modify the
> object) or to otherwise refine them and make them better before proposing
> them. Not agreeing with commentary does not make that commentary invalid.
>
> I'm not stopping you from writing up a proposal and submitting it. But I'm
> not going to pretend that I think it would be a worthwhile use of the
> committee's time debating and voting on it either, compared to either
> getting array_ref back or the apparently committee preferred solution.
>

0. I've just responded to Felipe.

1. I've not followed all the proposals. I didn't know of array_ref when I
proposed. Its proposal also preceded the open call (perhaps it's a bit
dusty at this point). I will have to look for the reason concerning its
rejection.

2. Ok. Thanks for the heads up. I plan to float a more concrete iteration
in a few days (more below).

3. You can easily refer to a slice of the sequence or request an iterator
from it -- seems more logical to hoist the implementation out to a type
dedicated to the given problem (e.g. iterator). Don't forget that sequences
offer mutable elements while array_ref does not. IMO, mutable elements
offer greater applicability than array_ref's shrinking and assignment.
Because of this distinction, one could say that sequences more accurately
resemble llvm's ArrayRef and MutableArrayRef than the proposed array_ref. I
tried to explain how that step forward combined with the step "backwards"
makes for what I consider very clean semantics in use, but here's how it
unfolds:

=== Array Refs ===

void foo(array_ref<T> p); // foo can shrink either end of p or reassign p.
of course, that change is local to the function.
void foo(array_ref<T>& p); // foo can shrink either end of p or reassign p,
and the caller will see that change
void foo(const array_ref<T> p); // foo can read the elements and the size
void foo(const array_ref<T>& p); // foo can read the elements and the size



In no case can foo alter the array elements.

=== Sequences ===

void foo(sequence<T> p);
void foo(sequence<T>& p);
void foo(const sequence<T> p);
void foo(const sequence<T>& p);


In all cases, foo() can access the elements, but not mutate them.

void foo(mutable_sequence<T> p);
void foo(mutable_sequence<T>& p);


In both cases, foo() can read and mutate the elements.

void foo(const mutable_sequence<T> p);
void foo(const mutable_sequence<T>& p);


In both cases, foo() can access the elements, but not mutate them.

=== Practical comparison with redundance eliminated ===

=== Array Refs ===

void foo(array_ref<T> p); // foo can shrink either end of p or reassign p.
of course, that change is local to the function.
void foo(array_ref<T>& p); // foo can shrink either end of p or reassign p,
and the caller will see that change.
void foo(const array_ref<T> p); // foo can read the elements and the size.


In no case can foo alter the array elements.

=== Sequences ===

void foo(sequence<T> p); // foo() can access the elements, but not mutate
them.
void foo(mutable_sequence<T> p); // foo() can access the elements and also
mutate them.


For foo(const mutable_sequence<T>) and foo(const mutable_sequence<T>& p)
one would just declare void foo(sequence<T> p) instead.

=== End Practical comparison ===

Anyways, I should just make a more concrete representation of this for you
all before we spend more time on the shrink/assign issue. If there is
interest at that stage, I think the next logical step would be for me to
float a basic implementation you all can try out where features such as
assignment can be enabled via the preprocessor. In essence, that would
change members from:

template<>class sequence {T* const elements; const size_t size;};


to:
template<>class sequence {T* elements; size_t size;};

Thus adding the following to practical signatures:
void foo(sequence<T>& p); // foo() can access the elements, but not mutate
them. p may be shrunk or reassigned.
void foo(mutable_sequence<T>& p); // foo() can access the elements and also
mutate them. p may be shrunk or reassigned.

Adding sequences isn't for my personal benefit; I mentioned I already have
an implementation. Sure, it would help in some cases outside of my codebase
but I don't see how sequences serve me more than it would serve anybody in
this group.

Glad we could bring this back on track.


--

---
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/?hl=en.



------=_Part_1036_11401103.1370387584888
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 4, 2013 2:41:43 PM UTC-4, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On Tuesday, June 4, 2013 7:27:59 AM =
UTC-7, <a>carrieran...@yahoo.co.uk</a> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">On Monday, June 3, 2013 6:39:35 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">On Monday, June 3, 2013 1:24:54 PM UTC-7=
, <a>carrieran...@yahoo.co.uk</a> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>re Lightweight: The smallest array_ref could be the same size=
 as a sequence. Because array_ref's members are not const, it could result =
in larger and slower code.</div></blockquote><div><br>... how? They'll just=
 be a pair of pointers or a pointer+size either way.<br></div></blockquote>=
<div><br></div><div>So you have checked my math. What exactly is your quest=
ion?</div></blockquote><div><br>Felipe covered this one, but I'll reiterate=
.. You claimed that array_ref's members not being `const` would make code "l=
arger and slower". How? In what cases could that possibly happen?<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Shrinking did not exi=
st in my proposal because I never needed that functionality. I was content =
with the guarantees the type provided and its simplicity. The type did not =
attempt to be an iterator, range, or scanner as well. I've found slicing qu=
ite effective.</div></blockquote><div><br>I don't really see how that's an =
argument, especially considering again that Google and LLVM <i>do</i> need =
this functionality. They didn't write those functions just because they cou=
ld. Does your class get as much usage as all internal Google and LLVM C++ p=
rojects? If not, then I would rather defer to the guys who have the usage e=
xperience.<br></div></blockquote><div><br></div><div>Since explaining this =
to you, endorsement comes out as the heart of your objection?</div></blockq=
uote><div><br>No, the heart of my objections are these:<br><br>1: The commi=
ttee already saw a proposal that was similar to what you suggest. A proposa=
l that was rejected (for reasons that I find dubious, but nevermind that no=
w).<br><br>2: Your proposal is not different enough from the rejected one t=
o likely gain any traction with the committee. Especially over the solution=
 that many committee members apparently prefer (ie: wait for ranges/travers=
al/etc and hope that <i>they</i> solve the problem).<br><br>3: Your proposa=
l, when compared to the rejected one, is a needless step backwards. The sta=
ndard must serve more needs than just your own. While the fact that you hav=
en't needed to modify these "sequences" is interesting, the fact that <i>ot=
her</i> people clearly do have that need outweighs that. And most notably, =
the apparently committee-preferred solution (ie: iterator_range) is quite m=
utable, if it's based on the <a href=3D"http://www.boost.org/doc/libs/1_53_=
0/libs/range/doc/html/range/reference/utilities/iterator_range.html" target=
=3D"_blank">boost::iterator_range</a>. So that's LLVM, Google, <i>and</i> B=
oost, all of whom think mutability is important.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>You need to realize that there is a call fo=
r library proposals and that this is the forum for such proposals: <a href=
=3D"http://isocpp.org/std/submit-a-proposal" target=3D"_blank">"The door is=
 open for submissions of features to be added to the standard library, and =
we would love to see them not only from existing community libraries like B=
oost, Poco, and Qt, but from <i>you</i>.".</a>&nbsp;Proposals don't need yo=
ur endorsement watchdogging. Let's stay squarely on topic.</div></blockquot=
e><div><br>This forum is for commentary on proposals and inquiry on proposa=
ls, so as to either fix issues in proposals (like not being able to modify =
the object) or to otherwise refine them and make them better before proposi=
ng them. Not agreeing with commentary does not make that commentary invalid=
..<br><br>I'm not stopping you from writing up a proposal and submitting it.=
 But I'm not going to pretend that I think it would be a worthwhile use of =
the committee's time debating and voting on it either, compared to either g=
etting array_ref back or the apparently committee preferred solution.<br></=
div></blockquote><div><br></div><div>0. I've just responded to Felipe.</div=
><div><br></div><div>1. I've not followed all the proposals. I didn't know =
of array_ref when I proposed. Its proposal also preceded the open call (per=
haps it's a bit dusty at this point). I will have to look for the reason co=
ncerning its rejection.</div><div><br></div><div>2. Ok. Thanks for the head=
s up. I plan to float a more concrete iteration in a few days (more below).=
</div><div><br></div><div>3. You can easily refer to a slice of the sequenc=
e or request an iterator from it -- seems more logical to hoist the impleme=
ntation out to a type dedicated to the given problem (e.g. iterator). Don't=
 forget that sequences offer mutable elements while array_ref does not. IMO=
, mutable elements offer greater applicability than array_ref's shrinking a=
nd assignment. Because of this distinction, one could say that sequences mo=
re accurately resemble llvm's ArrayRef and MutableArrayRef than the propose=
d array_ref. I tried to explain how that step forward combined with the ste=
p "backwards" makes for what I consider very clean semantics in use, but he=
re's how it unfolds:</div><div><br></div><div>=3D=3D=3D Array Refs =3D=3D=
=3D</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250);=
 border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"pr=
ettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">array_ref</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// foo can shri=
nk either end of p or reassign p. of course, that change is local to the fu=
nction.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">array_ref</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;&amp;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// foo can shrink either end of p or reassign p, and the caller will=
 see that change</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> array_ref</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// foo can read the elements and the size</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> array_ref</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><sp=
an 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=
: #800;" class=3D"styled-by-prettify">// foo can read the elements and the =
size</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span></div></code></div><div><br><br></div><div>In no case can foo alte=
r the array elements.</div><div><br></div><div>=3D=3D=3D Sequences =3D=3D=
=3D</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250);=
 border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"pr=
ettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">sequence</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">sequence</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> sequence</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> sequence</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;&amp;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><div><br><br></div><d=
iv>In all cases, foo() can access the elements, but not mutate them.</div><=
div><br></div><div style=3D"background-color: rgb(250, 250, 250); border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"prettyprint"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">mutable_sequence</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">mutable_sequence</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;&amp;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></div></code></div><div><br><br></div><div>In both c=
ases, foo() can read and mutate the elements.</div><div><br></div><div styl=
e=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, =
187); word-wrap: break-word; " class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mutabl=
e_sequence</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> mutable_sequence</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><div><br><br></div><div>In both cases, foo() can access the ele=
ments, but not mutate them.</div><div><br></div><div>=3D=3D=3D Practical co=
mparison with redundance eliminated =3D=3D=3D</div><div><br></div><div>=3D=
=3D=3D Array Refs =3D=3D=3D</div><div><br></div><div style=3D"background-co=
lor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: b=
reak-word; " class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fo=
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">array_ref</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// foo can shrink either end of p or reassign p. of course, that =
change is local to the function.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">arr=
ay_ref</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// foo can shrink either end of p or reassign=
 p, and the caller will see that change.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
rray_ref</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> p</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: #800;" cl=
ass=3D"styled-by-prettify">// foo can read the elements and the size.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><div><br><br></div><div>In no case can foo alter the array el=
ements.</div><div><br></div><div>=3D=3D=3D Sequences =3D=3D=3D</div><div><b=
r></div><div style=3D"background-color: rgb(250, 250, 250); border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word; " class=3D"prettyprint"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">sequence</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// foo() can access the elements,=
 but not mutate them.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">mutable_sequence=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// foo() can access the elements and also mutate them.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
/div></code></div><div><br><br></div><div>For foo(const mutable_sequence&lt=
;T&gt;) and foo(const mutable_sequence&lt;T&gt;&amp; p) one would just decl=
are void foo(sequence&lt;T&gt; p) instead.</div><div><br></div><div>=3D=3D=
=3D End Practical comparison =3D=3D=3D</div><div><br></div><div>Anyways, I =
should just make a more concrete representation of this for you all before =
we spend more time on the shrink/assign issue. If there is interest at that=
 stage, I think the next logical step would be for me to float a basic impl=
ementation you all can try out where features such as assignment can be ena=
bled via the preprocessor. In essence, that would change members from:</div=
><div><br></div><div><div style=3D"background-color: rgb(250, 250, 250); bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"prett=
yprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;&gt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> sequence </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" 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"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> elements</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">const</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> size_t size</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;};</span></div></cod=
e></div><br></div><div><br></div><div>to:</div><div><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;&gt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> seq=
uence </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><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"> elements</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> size_t size</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;};</span></div></code></div><br></div>=
<div>Thus adding the following to practical signatures:</div><div><div clas=
s=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); background=
-color: rgb(250, 250, 250); word-wrap: break-word; "><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">se=
quence</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// foo() can access the elements, but not mut=
ate them. p may be shrunk or reassigned.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">mutable_sequence</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</spa=
n><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: #800;" class=3D"styled-by-prettify">// foo() can access the elements=
 and also mutate them. </span><span style=3D"color: rgb(136, 0, 0); "><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">p may be shrunk or rea=
ssigned.</span></span></div></code></div></div><div><br></div><div>Adding s=
equences isn't for my personal benefit; I mentioned I already have an imple=
mentation. Sure, it would help in some cases outside of my codebase but I d=
on't see how sequences serve me more than it would serve anybody in this gr=
oup.</div><div><br></div><div>Glad we could bring this back on track.</div>=
<div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1036_11401103.1370387584888--

.

On Tue, Jun 4, 2013 at 6:54 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:

> Yeah, you might see a performance difference for non-const
> array_ref<>s where the compiler can't assume they don't change.

Just think const-correctness does not help optimizer.

  http://stackoverflow.com/a/6313818

Aliasing is the thing matters, const-correctness is irrelevant.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 4:20 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 6:54 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
>> Yeah, you might see a performance difference for non-const
>> array_ref<>s where the compiler can't assume they don't change.
>
> Just think const-correctness does not help optimizer.
>
>   http://stackoverflow.com/a/6313818
>
> Aliasing is the thing matters, const-correctness is irrelevant.

In:

array_ref<int> arr1 = ...;
const array_ref<int>& carr1;
do_stuff_with(carr1);
use(arr1.size());

the compiler can't assume arr.size() is the same across the call to
do_stuff_with(). However, in:

const array_ref<int> carr2 = ...;
do_stuff_with(carr2);
use(carr2.size());

the compiler _can_ assume carr.size() is the same. In my previous
message, my terminology assumes that carr1 refers to a non-const
array_ref<>.

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 7:26 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> const array_ref<int> carr2 = ...;
> do_stuff_with(carr2);
> use(carr2.size());
>
> the compiler _can_ assume carr.size() is the same.

In a general case, since the same memory can be referred
by another pointer or reference, optimizers just won't analysis
the data flow.  Instead, they know many thing about the control
flow.  If the above code is optimized, that means you don't
have the code to change the size; it doesn't matter you declare
it as const or not.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

------=_Part_3380_31825803.1370391833245
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:
>
>
>
> Yeah, you might see a performance difference for non-const
> array_ref<>s where the compiler can't assume they don't change. If
> users see that, they can create const array_ref<>s instead. Is there a
> difference between const array_ref<>s and sequence<>s?
>

Mentioning an update past the initial proposal; there are two forms:

template<>class sequence {const T* const element; const size_t size;}; //
for immutable elements
template<>class mutable_sequence {T* const element; const size_t size;}; //
for mutable elements

Thus:
const array_ref<int>
sequence<int>
sequence<int>&
const sequence<int>
const sequence<int>&
const mutable_sequence<int>
const mutable_sequence<int>&

All specify objects which have immutable size, pointer, and elements.

Naturally, there will also be cases where the optimizer can prove a value
array_ref<int> does not alter its size or pointer.

--

---
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/?hl=en.



------=_Part_3380_31825803.1370391833245
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br>
<br>Yeah, you might see a performance difference for non-const
<br>array_ref&lt;&gt;s where the compiler can't assume they don't change. I=
f
<br>users see that, they can create const array_ref&lt;&gt;s instead. Is th=
ere a
<br>difference between const array_ref&lt;&gt;s and sequence&lt;&gt;s?
<br></blockquote><div><br></div><div><div>Mentioning an update past the ini=
tial proposal; there are two forms:</div><div><br></div><div></div></div><d=
iv style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187=
, 187, 187); word-wrap: break-word; " class=3D"prettyprint"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;&gt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> sequence </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> element</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">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> size_t size</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// for immutable elements</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;&gt;</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> mutable_sequence </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">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">const</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> element</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> size_t size</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: #800;" class=3D"style=
d-by-prettify">// for mutable elements</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><div><br></div><d=
iv>Thus:<br></div><div style=3D"background-color: rgb(250, 250, 250); borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"prettypr=
int"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> array_ref</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>sequence</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>sequence</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> sequence</span><span style=3D"color: #=
080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> sequence</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> mutable_sequence</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> mutable_sequence</span><span style=3D"color: #080;" class=3D"styled-=
by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><div><br></div><div>All specify obje=
cts which have immutable size, pointer, and elements.</div><div><br></div><=
div>Naturally, there will also be cases where the optimizer can prove a val=
ue array_ref&lt;int&gt; does not alter its size or pointer.</div><div><br><=
/div><div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3380_31825803.1370391833245--

.

On Tue, Jun 4, 2013 at 5:17 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 7:26 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> const array_ref<int> carr2 = ...;
>> do_stuff_with(carr2);
>> use(carr2.size());
>>
>> the compiler _can_ assume carr.size() is the same.
>
> In a general case, since the same memory can be referred
> by another pointer or reference, optimizers just won't analysis
> the data flow.  Instead, they know many thing about the control
> flow.  If the above code is optimized, that means you don't
> have the code to change the size; it doesn't matter you declare
> it as const or not.

See "The only time const might allow optimizations" in the very
article you linked to.

--

---
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/?hl=en.



.

------=_Part_1158_1267777.1370392942990
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 4, 2013 8:23:53 PM UTC-4, carrieran...@yahoo.co.uk wrote:
>
>
>
> On Tuesday, June 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:
>>
>>
>>
>> Yeah, you might see a performance difference for non-const
>> array_ref<>s where the compiler can't assume they don't change. If
>> users see that, they can create const array_ref<>s instead. Is there a
>> difference between const array_ref<>s and sequence<>s?
>>
>
> Mentioning an update past the initial proposal; there are two forms:
>
> template<>class sequence {const T* const element; const size_t size;}; //
> for immutable elements
> template<>class mutable_sequence {T* const element; const size_t size;}; //
> for mutable elements
>
> Thus:
> const array_ref<int>
> sequence<int>
> sequence<int>&
> const sequence<int>
> const sequence<int>&
> const mutable_sequence<int>
> const mutable_sequence<int>&
>
> All specify objects which have immutable size, pointer, and elements.
>
> Naturally, there will also be cases where the optimizer can prove a value
> array_ref<int> does not alter its size or pointer.
>
>
Well, the elements are not entirely mutable in the sense that they may be
externally modified.


--

---
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/?hl=en.



------=_Part_1158_1267777.1370392942990
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 4, 2013 8:23:53 PM UTC-4, carrieran...@yahoo.co.uk=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tuesday, Jun=
e 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><br>
<br>Yeah, you might see a performance difference for non-const
<br>array_ref&lt;&gt;s where the compiler can't assume they don't change. I=
f
<br>users see that, they can create const array_ref&lt;&gt;s instead. Is th=
ere a
<br>difference between const array_ref&lt;&gt;s and sequence&lt;&gt;s?
<br></blockquote><div><br></div><div><div>Mentioning an update past the ini=
tial proposal; there are two forms:</div><div><br></div><div></div></div><d=
iv style=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,=
187);word-wrap:break-word"><code><div><span style=3D"color:#008">template</=
span><span style=3D"color:#660">&lt;&gt;</span><span style=3D"color:#008">c=
lass</span><span style=3D"color:#000"> sequence </span><span style=3D"color=
:#660">{</span><span style=3D"color:#008">const</span><span style=3D"color:=
#000"> T</span><span style=3D"color:#660">*</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">const</span><span style=3D"color:#000"=
> element</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">const</span><span style=3D"color:#000=
"> size_t size</span><span style=3D"color:#660">;};</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#800">// for immutable elements</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#008">template=
</span><span style=3D"color:#660">&lt;&gt;</span><span style=3D"color:#008"=
>class</span><span style=3D"color:#000"> mutable_sequence </span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000">T</span><span style=3D"=
color:#660">*</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">const</span><span style=3D"color:#000"> element</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">const</span><span style=3D"color:#000"> size_t size</span><span sty=
le=3D"color:#660">;};</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// for mutable elements</span><span style=3D"color:#000"><b=
r></span></div></code></div><div><br></div><div>Thus:<br></div><div style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">const</span><span =
style=3D"color:#000"> array_ref</span><span style=3D"color:#080">&lt;int&gt=
;</span><span style=3D"color:#000"><br>sequence</span><span style=3D"color:=
#080">&lt;int&gt;</span><span style=3D"color:#000"><br>sequence</span><span=
 style=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#660">&amp;</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> sequence</span><span style=3D"color:#080"=
>&lt;int&gt;</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#008">const</span><span style=3D"color:#000"> sequence</span><span style=
=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#660">&amp;</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#008">const</span>=
<span style=3D"color:#000"> mutable_sequence</span><span style=3D"color:#08=
0">&lt;int&gt;</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#008">const</span><span style=3D"color:#000"> mutable_sequence</span><=
span style=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#660">&amp=
;</span><span style=3D"color:#000"><br></span></div></code></div><div><br><=
/div><div>All specify objects which have immutable size, pointer, and eleme=
nts.</div><div><br></div><div>Naturally, there will also be cases where the=
 optimizer can prove a value array_ref&lt;int&gt; does not alter its size o=
r pointer.</div><div><br></div></blockquote><div><br></div><div>Well, the e=
lements are not entirely mutable in the sense that they may be externally m=
odified.&nbsp;</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1158_1267777.1370392942990--

.

------=_Part_929_15563790.1370393536677
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, June 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:
>
> <snip>
>
> Yeah, you might see a performance difference for non-const
> array_ref<>s where the compiler can't assume they don't change. If
> users see that, they can create const array_ref<>s instead. Is there a
> difference between const array_ref<>s and sequence<>s?
>

Mentioning an update past the initial proposal; there are two forms:

template<>class sequence {const T* const element; const size_t size;}; //
for immutable elements
template<>class mutable_sequence {T* const element; const size_t size;}; //
for mutable elements


Thus:
const array_ref<int>
sequence<int>
sequence<int>&
const sequence<int>
const sequence<int>&
const mutable_sequence<int>
const mutable_sequence<int>&


All specify objects which have invariant size and pointer. In all cases,
mutable elements may not be provided by the class although they may be
externally modified.

Naturally, there will also be cases where the optimizer can prove a value
of type array_ref<int> does not alter its size or pointer.

 (excuse the edit noise)

--

---
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/?hl=en.



------=_Part_929_15563790.1370393536677
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 6:54:45 PM UTC-4, Jeffrey Yasskin wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">&lt;snip&gt;<br>
<br>Yeah, you might see a performance difference for non-const
<br>array_ref&lt;&gt;s where the compiler can't assume they don't change. I=
f
<br>users see that, they can create const array_ref&lt;&gt;s instead. Is th=
ere a
<br>difference between const array_ref&lt;&gt;s and sequence&lt;&gt;s?
<br></blockquote><div><br></div><div>Mentioning an update past the initial =
proposal; there are two forms:</div><div><br></div><div style=3D"background=
-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;&gt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sequ=
ence </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> element</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> size_t size</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">// for immuta=
ble elements</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&g=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> mutable_sequ=
ence </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><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"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> element</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> size_t size</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// for mut=
able elements</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span></div></code></div><div><br><br></div><div>Thus:</div><div st=
yle=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word; " class=3D"prettyprint"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> array_ref</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>sequence</span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>sequence</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> sequence</span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
equence</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt=
;int&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> mutable_sequence<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> mutable_sequence</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><div><br><br></div><div>All specify objects which have invarian=
t size and pointer. In all cases, mutable elements may not be provided by t=
he class although they may be externally modified.</div><div><br></div><div=
>Naturally, there will also be cases where the optimizer can prove a value =
of type array_ref&lt;int&gt; does not alter its size or pointer.</div><div>=
<br></div><div>&nbsp;(excuse the edit noise)</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_929_15563790.1370393536677--

.

On Tue, Jun 4, 2013 at 8:25 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> See "The only time const might allow optimizations" in the very
> article you linked to.

This is for a different reason: the compiler regards the value as a
real 'constant', but distinguishes it from a 'real' 'real' one defined
in language (and this is why the `constexpr` keyword is there).

Try this:

struct A {
    A() : x(10) {}
    int x;
};

void f(int* x) {
    std::cin >> *x;
}

int main() {
    A a;
    f((int*)&a);
    std::cout << a.x;
}

Then you will find that the 'optimization' no longer works.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

--047d7b33992dc4951704de5de29d
Content-Type: text/plain; charset=ISO-8859-1

On 4 June 2013 20:06, Zhihao Yuan <lichray@gmail.com> wrote:

> int main() {
>     A a;
>     f((int*)&a);
>     std::cout << a.x;
> }
>
> Then you will find that the 'optimization' no longer works.
>
>
You are invoking undefined behavior, so whether or not the optimization
works in this case is irrelevant.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b33992dc4951704de5de29d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 4 June 2013 20:06, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:l=
ichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>&gt;</span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">int main() {</div>
=A0 =A0 A a;<br>
=A0 =A0 f((int*)&amp;a);<br>
=A0 =A0 std::cout &lt;&lt; a.x;<br>
}<br>
<br>
Then you will find that the &#39;optimization&#39; no longer works.<br>
<div class=3D"im HOEnZb"><br></div></blockquote><div><br></div><div>You are=
 invoking undefined behavior, so whether or not the optimization works in t=
his case is irrelevant.=A0</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=
=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b33992dc4951704de5de29d--

.

On Tue, Jun 4, 2013 at 9:11 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> int main() {
>>     A a;
>>     f((int*)&a);
>>     std::cout << a.x;
>> }
>>
>> Then you will find that the 'optimization' no longer works.
>>
>
> You are invoking undefined behavior, so whether or not the optimization
> works in this case is irrelevant.

Yes, of course :) The behavior of the program does not prove
my argument, but don't forget the program showed on
StackOverflow is also a UB.  I can only conceptually explain this
and hope you can understand...

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 9:11 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 4 June 2013 20:06, Zhihao Yuan <lichray@gmail.com> wrote:
>>
>> int main() {
>>     A a;
>>     f((int*)&a);
>>     std::cout << a.x;
>> }
>>
>> Then you will find that the 'optimization' no longer works.
>>
>
> You are invoking undefined behavior, so whether or not the optimization
> works in this case is irrelevant.

Oh, typo, sorry.  You mean strict aliasing.

Should be

    A a;
    f((int*)&a.x);
    std::cout << a.x;

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 6:23 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 9:11 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> On 4 June 2013 20:06, Zhihao Yuan <lichray@gmail.com> wrote:
>>>
>>> int main() {
>>>     A a;
>>>     f((int*)&a);
>>>     std::cout << a.x;
>>> }
>>>
>>> Then you will find that the 'optimization' no longer works.
>>>
>>
>> You are invoking undefined behavior, so whether or not the optimization
>> works in this case is irrelevant.
>
> Oh, typo, sorry.  You mean strict aliasing.
>
> Should be
>

void f(int* x) {
    std::cin >> *x;
}

struct A {
    A() : x(10) {}
    int x;
};

>     A a;
>     f((int*)&a.x);
>     std::cout << a.x;

If you declare 'a' as const then compilers can print 10 whatever you
type in, because they optimize away the read in a.x, because they are
allowed to.

That's what we mean when we say that const enables optimizations.
Optimizers can assume that objects defined constant do not change,
because changing them would be undefined behavior, and optimizers are
always allowed to always assume that undefined behavior does not
occur.

-- James

--

---
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/?hl=en.



.

On Wed, Jun 5, 2013 at 12:07 AM, James Dennett <jdennett@google.com> wrote:
> If you declare 'a' as const then compilers can print 10 whatever you
> type in, because they optimize away the read in a.x, because they are
> allowed to.

Try it before you saying this.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 10:16 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 5, 2013 at 12:07 AM, James Dennett <jdennett@google.com> wrote:
>> If you declare 'a' as const then compilers can print 10 whatever you
>> type in, because they optimize away the read in a.x, because they are
>> allowed to.
>
> Try it before you saying this.

James is saying what compilers are allowed to do. You've observed that
gcc and clang do not yet actually do it. Your observation doesn't mean
they aren't allowed to do it, and if you care at all about the people
who'll be maintaining your code in the future, you shouldn't code as
if they won't do it in the future.

Jeffrey

--

---
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/?hl=en.



.

On Wed, Jun 5, 2013 at 1:36 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> James is saying what compilers are allowed to do.

"because they optimize away"... there is no "can" here, so
I assume his purpose is to say "he knows it".

> You've observed that
> gcc and clang do not yet actually do it. Your observation doesn't mean
> they aren't allowed to do it, and if you care at all about the people
> who'll be maintaining your code in the future, you shouldn't code as
> if they won't do it in the future.

They are allowed to do, yes, in this specific case, but what I'm
explaining is why they do not do (and probably will never do),
because analyzing the control flow is much easier and can
cover more useful cases, and since the const-correctness does
not help de-aliasing at all, the compilers just do not use the
information (for short, the SSA passed to clang optimizer
just do not have constness).  I'm pretty much sure there is
no future for these kind of analysis.

I'm not against const-correctness, it's absolutely good to write
a program which obeys const-correctness, but please don't
assume it can improve performance -- it does not; the compiler
can optimize much more cases which you can hardly think of,
that's enough.  At last, use `constexpr` whenever you can.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On Tue, Jun 4, 2013 at 11:27 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 5, 2013 at 1:36 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> James is saying what compilers are allowed to do.

Yes.

> "because they optimize away"... there is no "can" here, so
> I assume his purpose is to say "he knows it".

That's not a correct understanding of the sentence, but that's not
very important.

>> You've observed that
>> gcc and clang do not yet actually do it. Your observation doesn't mean
>> they aren't allowed to do it, and if you care at all about the people
>> who'll be maintaining your code in the future, you shouldn't code as
>> if they won't do it in the future.
>
> They are allowed to do, yes, in this specific case, but what I'm
> explaining is why they do not do (and probably will never do),
> because analyzing the control flow is much easier and can
> cover more useful cases, and since the const-correctness does
> not help de-aliasing at all, the compilers just do not use the
> information (for short, the SSA passed to clang optimizer
> just do not have constness).  I'm pretty much sure there is
> no future for these kind of analysis.

I have seen real compilers do similar optimizations that do depend on
const, and I've seen beginners be puzzled by the results (e.g., when
printing the same variable gives two different results at same time,
because the compilers has used the original value in some cases but
not in others).

In my opinion this is drifting off-topic for this thread, and indeed
this forum, so I'll bow out now.

-- James

--

---
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/?hl=en.



.

On Wed, Jun 5, 2013 at 3:04 AM, James Dennett <jdennett@google.com> wrote:
> That's not a correct understanding of the sentence, but that's not
> very important.

I'm sorry.

> I have seen real compilers do similar optimizations that do depend on
> const, and I've seen beginners be puzzled by the results (e.g., when
> printing the same variable gives two different results at same time,
> because the compilers has used the original value in some cases but
> not in others).

I can only say "I bet" those are not const-based optimizations, those
are constant propagation, as shown before in this thread, and those
are where we should tell the beginners to use `constexpr` instead.

Actually, since you are googlers, I think you should talk to
Chandler Carruth; he knows everything :)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

--20cf303b39f104ea3a04de639964
Content-Type: text/plain; charset=ISO-8859-1

On 5 June 2013 10:19, Zhihao Yuan <lichray@gmail.com> wrote:

> Actually, since you are googlers, I think you should talk to
> Chandler Carruth; he knows everything :)
>
>
>
>
I don't think you know who you're talking to, The Dennett also knows
everything. :)

--

---
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/?hl=en.



--20cf303b39f104ea3a04de639964
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 June 2013 10:19, Zhihao Yuan <span dir="ltr">&lt;<a href="mailto:lichray@gmail.com" target="_blank">lichray@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually, since you are googlers, I think you should talk to<br>
Chandler Carruth; he knows everything :)<br>
<div class="im HOEnZb"><br>
<br><br></div></blockquote><div><br></div><div>I don&#39;t think you know who you&#39;re talking to, The Dennett also knows everything. :) <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf303b39f104ea3a04de639964--

.

------=_Part_2100_23717636.1371320994929
Content-Type: text/plain; charset=ISO-8859-1

Just noting that Revision 2 has been posted. It is located at: Proposal for
std::sequence - Rev.2<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r5rYVkTXfhg>


--

---
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_2100_23717636.1371320994929
Content-Type: text/html; charset=ISO-8859-1

<div>Just noting that Revision 2 has been posted. It is located at:&nbsp;<a href="https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/r5rYVkTXfhg">Proposal for std::sequence - Rev.2</a><br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2100_23717636.1371320994929--

.