------=_Part_2722_14529676.1384226296588
Content-Type: text/plain; charset=ISO-8859-1

As the string_view class is currently written, the following code will
cause an access to a destructed object and probably a crash:

std::string foo();

int main() {
    string_view view(foo(), 0, 3);
    std::cout << view;
}

When the string_view is created, it stores pointers into the temporary
string created by foo(), which is then destroyed, leaving the string_view
with pointers to garbage. I know that if the string_view were immediately
sent to cout without creating an lvalue everything would have been fine.
However, this seems dangerous enough that it might be a good idea to forbid
creating a string_view from an rvalue std::string, by deleting the
constructor and assignment operator from rvalue strings.

Joe Gottman

--

---
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_2722_14529676.1384226296588
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As the string_view class is currently written, the followi=
ng code will cause an access to a destructed object and probably a crash:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span st=
yle=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"><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> main</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: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; string_view view</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">foo</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> view</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div><br>When the string_view is created, it stores poi=
nters into the temporary string created by foo(), which is then destroyed, =
leaving the string_view with pointers to garbage. I know that if the string=
_view were immediately sent to cout without creating an lvalue everything w=
ould have been fine.&nbsp; However, this seems dangerous enough that it mig=
ht be a good idea to forbid creating a string_view from an rvalue std::stri=
ng, by deleting the constructor and assignment operator from rvalue strings=
..<br><br>Joe Gottman<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2722_14529676.1384226296588--

.

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

There are already plenty of things you can do to reference a destructed
object, e.g.

char * view = foo().c_str();

Users using a specialized class like string_view should understand what it
means.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Nov 11, 2013 at 7:18 PM, <jgottman6@gmail.com> wrote:

> As the string_view class is currently written, the following code will
> cause an access to a destructed object and probably a crash:
>
> std::string foo();
>
> int main() {
>     string_view view(foo(), 0, 3);
>     std::cout << view;
> }
>
> When the string_view is created, it stores pointers into the temporary
> string created by foo(), which is then destroyed, leaving the string_view
> with pointers to garbage. I know that if the string_view were immediately
> sent to cout without creating an lvalue everything would have been fine.
> However, this seems dangerous enough that it might be a good idea to forbid
> creating a string_view from an rvalue std::string, by deleting the
> constructor and assignment operator from rvalue strings.
>
> Joe Gottman
>
>  --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>There are already plenty of things you can do to refe=
rence a destructed object, e.g.</div><div>=A0</div><div>char * view =3D foo=
().c_str();</div><div>=A0</div><div>Users using a specialized class like st=
ring_view should understand what it means.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 11, 2013 at 7:18 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jgottman6@gmail.com" target=3D"_blank">jg=
ottman6@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">As the string_view class is currently written, the followi=
ng code will cause an access to a destructed object and probably a crash:<b=
r><br><div style=3D"border:1px solid rgb(187,187,187);background-color:rgb(=
250,250,250)">

<code><div><span>std</span><span style=3D"color:rgb(102,102,0)">::</span><s=
pan style=3D"color:rgb(0,0,136)">string</span><span> foo</span><span style=
=3D"color:rgb(102,102,0)">();</span><span><br><br></span><span style=3D"col=
or:rgb(0,0,136)">int</span><span> main</span><span style=3D"color:rgb(102,1=
02,0)">()</span><span> </span><span style=3D"color:rgb(102,102,0)">{</span>=
<span><br>

=A0 =A0 string_view view</span><span style=3D"color:rgb(102,102,0)">(</span=
><span>foo</span><span style=3D"color:rgb(102,102,0)">(),</span><span> </sp=
an><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(10=
2,102,0)">,</span><span> </span><span style=3D"color:rgb(0,102,102)">3</spa=
n><span style=3D"color:rgb(102,102,0)">);</span><span><br>

=A0 =A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span>cout =
</span><span style=3D"color:rgb(102,102,0)">&lt;&lt;</span><span> view</spa=
n><span style=3D"color:rgb(102,102,0)">;</span><span><br></span><span style=
=3D"color:rgb(102,102,0)">}</span><span><br>

</span></div></code></div><br>When the string_view is created, it stores po=
inters into the temporary string created by foo(), which is then destroyed,=
 leaving the string_view with pointers to garbage. I know that if the strin=
g_view were immediately sent to cout without creating an lvalue everything =
would have been fine.=A0 However, this seems dangerous enough that it might=
 be a good idea to forbid creating a string_view from an rvalue std::string=
, by deleting the constructor and assignment operator from rvalue strings.<=
br>

<br>Joe Gottman<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></fon=
t></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160b3dc79c64804eaf257da--

.

On Mon, Nov 11, 2013 at 10:18 PM,  <jgottman6@gmail.com> wrote:
> However, this seems dangerous enough that it might be a good idea to forbid
> creating a string_view from an rvalue std::string, by deleting the
> constructor and assignment operator from rvalue strings.

I +1.  The generic reference semantics adaptor reference_wrapper
already does 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/.

.

------=_Part_2881_1236407.1384235322088
Content-Type: text/plain; charset=ISO-8859-1

Reference wrapper is not meant to be used in all the same contexts. For me,
one of the major selling point for string_view is that it should most of
the time be used as a function parameter.

string foo();

void bar(string_view s);

void f()
{
    bar(foo()); // this is perfectly valid; are you suggesting not allowing
this?
}

I understand your fears that providing a constructor taking an rvalue can
be dangerous in some use cases, but not providing it just seems annoying in
the most obvious cases.

On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:

> On Mon, Nov 11, 2013 at 10:18 PM,  <jgot...@gmail.com <javascript:>>
> wrote:
> > However, this seems dangerous enough that it might be a good idea to
> forbid
> > creating a string_view from an rvalue std::string, by deleting the
> > constructor and assignment operator from rvalue strings.
>
> I +1.  The generic reference semantics adaptor reference_wrapper
> already does 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/.

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

<div dir=3D"ltr"><div>Reference wrapper is not meant to be used in all the =
same contexts. For me, one of the major selling point for string_view is th=
at it should most of the time be used as a function parameter.</div><div><b=
r></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,=
 187); border-image: none; -ms-word-wrap: break-word; background-color: rgb=
(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">string=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> f=
oo</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0=
);">();</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, =
0);"><br><br></span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 136);">void</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0);"> bar</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(0, 0, 0);">string_view s</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(102, 102, 0);">);</span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 0);"><br><br></span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 136);">void</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 0);"> f</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">()</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; ba=
r</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0)=
;">(</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);=
">foo</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102=
, 0);">());</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0,=
 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(136=
, 0, 0);">// this is perfectly valid; are you suggesting not allowing this?=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><b=
r></span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0=
);">}</span></div></code></div><div><br></div><div>I understand your fears =
that providing a constructor taking an rvalue can be dangerous in some use =
cases, but not providing it just seems annoying in the most obvious cases.<=
br><br>On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;">On Mon, Nov 11, 2013 at 10:18 PM, &nbsp;&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ZAmfZs=
rll74J">jgot...@gmail.com</a>&gt; wrote:
<br>&gt; However, this seems dangerous enough that it might be a good idea =
to forbid
<br>&gt; creating a string_view from an rvalue std::string, by deleting the
<br>&gt; constructor and assignment operator from rvalue strings.
<br>
<br>I +1. &nbsp;The generic reference semantics adaptor reference_wrapper
<br>already does this.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2881_1236407.1384235322088--

.

2013/11/12  <jgottman6@gmail.com>:
> As the string_view class is currently written, the following code will cause
> an access to a destructed object and probably a crash:
>
> std::string foo();
>
> int main() {
>     string_view view(foo(), 0, 3);
>     std::cout << view;
> }
>
> When the string_view is created, it stores pointers into the temporary
> string created by foo(), which is then destroyed, leaving the string_view
> with pointers to garbage. I know that if the string_view were immediately
> sent to cout without creating an lvalue everything would have been fine.
> However, this seems dangerous enough that it might be a good idea to forbid
> creating a string_view from an rvalue std::string, by deleting the
> constructor and assignment operator from rvalue strings.

Yes, I very much agree with that suggestion. Besides reference_wrapper
(as denoted by Zhihao Yuan), we have similar places where we have
added (or are considering to add) "rvalue-protection", one of the most
recent proposals are

http://cplusplus.github.io/LWG/lwg-active.html#2329
http://cplusplus.github.io/LWG/lwg-active.html#2332

- 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/.

.

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

This. A thousand times this.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Nov 11, 2013 at 9:48 PM, Alex B <devalexb@gmail.com> wrote:

> Reference wrapper is not meant to be used in all the same contexts. For
> me, one of the major selling point for string_view is that it should most
> of the time be used as a function parameter.
>
> string foo();
>
> void bar(string_view s);
>
> void f()
> {
>     bar(foo()); // this is perfectly valid; are you suggesting not
> allowing this?
> }
>
> I understand your fears that providing a constructor taking an rvalue can
> be dangerous in some use cases, but not providing it just seems annoying in
> the most obvious cases.
>
> On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:
>
>> On Mon, Nov 11, 2013 at 10:18 PM,  <jgot...@gmail.com> wrote:
>> > However, this seems dangerous enough that it might be a good idea to
>> forbid
>> > creating a string_view from an rvalue std::string, by deleting the
>> > constructor and assignment operator from rvalue strings.
>>
>> I +1.  The generic reference semantics adaptor reference_wrapper
>> already does 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/.
>

--

---
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/.

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

<div dir=3D"ltr">This. A thousand times this.</div><div class=3D"gmail_extr=
a"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div>=
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 11, 2013 at 9:48 PM, Alex B =
<span dir=3D"ltr">&lt;<a href=3D"mailto:devalexb@gmail.com" target=3D"_blan=
k">devalexb@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">

<div dir=3D"ltr"><div>Reference wrapper is not meant to be used in all the =
same contexts. For me, one of the major selling point for string_view is th=
at it should most of the time be used as a function parameter.</div><div>

<br></div><div style=3D"border:1px solid rgb(187,187,187);background-color:=
rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">string</spa=
n><span style> foo</span><span style=3D"color:rgb(102,102,0)">();</span><sp=
an style><br>

<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style> bar</=
span><span style=3D"color:rgb(102,102,0)">(</span><span style>string_view s=
</span><span style=3D"color:rgb(102,102,0)">);</span><span style><br><br></=
span><span style=3D"color:rgb(0,0,136)">void</span><span style> f</span><sp=
an style=3D"color:rgb(102,102,0)">()</span><span style><br>

</span><span style=3D"color:rgb(102,102,0)">{</span><span style><br>=A0 =A0=
 bar</span><span style=3D"color:rgb(102,102,0)">(</span><span style>foo</sp=
an><span style=3D"color:rgb(102,102,0)">());</span><span style> </span><spa=
n style=3D"color:rgb(136,0,0)">// this is perfectly valid; are you suggesti=
ng not allowing this?</span><span style><br>

</span><span style=3D"color:rgb(102,102,0)">}</span></div></code></div><div=
><br></div><div>I understand your fears that providing a constructor taking=
 an rvalue can be dangerous in some use cases, but not providing it just se=
ems annoying in the most obvious cases.<br>

<br>On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:</div=
><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid">

On Mon, Nov 11, 2013 at 10:18 PM, =A0&lt;<a>jgot...@gmail.com</a>&gt; wrote=
:
<br>&gt; However, this seems dangerous enough that it might be a good idea =
to forbid
<br>&gt; creating a string_view from an rvalue std::string, by deleting the
<br>&gt; constructor and assignment operator from rvalue strings.
<br>
<br>I +1. =A0The generic reference semantics adaptor reference_wrapper
<br>already does this.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<u></u>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b41c0ba8f4d4704eaf50970--

.

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

As Alex points out, this disallows many legitimate (and useful) uses of
string_view. This would be very easily solvable if we had ref-qualified
constructors:

string_view(const string&) { ... }
string_view(string&&) & = delete;
string_view(string&& s) && : string_view(s) {}

which disallows the "bad" use cases while allowing the useful ones.
Which was the reason for not allowing ref-qualification of constructors in
C++11? Has there been any proposal to introduce them?



2013/11/12 Billy O'Neal <billy.oneal@gmail.com>

> This. A thousand times this.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Nov 11, 2013 at 9:48 PM, Alex B <devalexb@gmail.com> wrote:
>
>> Reference wrapper is not meant to be used in all the same contexts. For
>> me, one of the major selling point for string_view is that it should most
>> of the time be used as a function parameter.
>>
>> string foo();
>>
>> void bar(string_view s);
>>
>> void f()
>> {
>>     bar(foo()); // this is perfectly valid; are you suggesting not
>> allowing this?
>> }
>>
>> I understand your fears that providing a constructor taking an rvalue can
>> be dangerous in some use cases, but not providing it just seems annoying in
>> the most obvious cases.
>>
>> On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:
>>
>>> On Mon, Nov 11, 2013 at 10:18 PM,  <jgot...@gmail.com> wrote:
>>> > However, this seems dangerous enough that it might be a good idea to
>>> forbid
>>> > creating a string_view from an rvalue std::string, by deleting the
>>> > constructor and assignment operator from rvalue strings.
>>>
>>> I +1.  The generic reference semantics adaptor reference_wrapper
>>> already does 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/.
>>
>
>  --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">As Alex points out, this disallows many legitimate (and us=
eful) uses of string_view. This would be very easily solvable if we had ref=
-qualified constructors:<div><br></div><div>string_view(const string&amp;) =
{ ... }</div>
<div>string_view(string&amp;&amp;) &amp; =3D delete;</div><div>string_view(=
string&amp;&amp; s) &amp;&amp; : string_view(s) {}</div><div><br></div><div=
>which disallows the &quot;bad&quot; use cases while allowing the useful on=
es.</div>
<div>Which was the reason for not allowing ref-qualification of constructor=
s in C++11? Has there been any proposal to introduce them?</div><div><br></=
div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">201=
3/11/12 Billy O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.onea=
l@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This. A thousand times this=
..</div><div class=3D"gmail_extra"><div class=3D"im"><br clear=3D"all"><div>=
<div dir=3D"ltr">
<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div class=3D"h5"><div class=3D"gmail_quote">On Mon, Nov=
 11, 2013 at 9:48 PM, 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=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">


<div dir=3D"ltr"><div>Reference wrapper is not meant to be used in all the =
same contexts. For me, one of the major selling point for string_view is th=
at it should most of the time be used as a function parameter.</div><div>


<br></div><div style=3D"border:1px solid rgb(187,187,187);background-color:=
rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">string</spa=
n><span> foo</span><span style=3D"color:rgb(102,102,0)">();</span><span><br=
>


<br></span><span style=3D"color:rgb(0,0,136)">void</span><span> bar</span><=
span style=3D"color:rgb(102,102,0)">(</span><span>string_view s</span><span=
 style=3D"color:rgb(102,102,0)">);</span><span><br><br></span><span style=
=3D"color:rgb(0,0,136)">void</span><span> f</span><span style=3D"color:rgb(=
102,102,0)">()</span><span><br>


</span><span style=3D"color:rgb(102,102,0)">{</span><span><br>=A0 =A0 bar</=
span><span style=3D"color:rgb(102,102,0)">(</span><span>foo</span><span sty=
le=3D"color:rgb(102,102,0)">());</span><span> </span><span style=3D"color:r=
gb(136,0,0)">// this is perfectly valid; are you suggesting not allowing th=
is?</span><span><br>


</span><span style=3D"color:rgb(102,102,0)">}</span></div></code></div><div=
><br></div><div>I understand your fears that providing a constructor taking=
 an rvalue can be dangerous in some use cases, but not providing it just se=
ems annoying in the most obvious cases.<br>


<br>On Monday, November 11, 2013 11:22:14 PM UTC-5, Zhihao Yuan wrote:</div=
><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid">


On Mon, Nov 11, 2013 at 10:18 PM, =A0&lt;<a>jgot...@gmail.com</a>&gt; wrote=
:
<br>&gt; However, this seems dangerous enough that it might be a good idea =
to forbid
<br>&gt; creating a string_view from an rvalue std::string, by deleting the
<br>&gt; constructor and assignment operator from rvalue strings.
<br>
<br>I +1. =A0The generic reference semantics adaptor reference_wrapper
<br>already does this.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<u></u>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc9574db6fd004eaf7164c--

.

2013/11/12 xavi <gratal@gmail.com>:
> Which was the reason for not allowing ref-qualification of constructors in
> C++11? Has there been any proposal to introduce them?

You need to explain the specific semantics of this qualification:
Constructors don't act on an existing object, so neither
cv-qualification nor ref-qualifiers make sense with the existing
meaning of such qualifications.

- 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/.

.

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

I have to admit I haven't given it a lot of thought, but right now three
ways to invoke a constructor (other than delegating constructors or
constructors of base classes, which should have the same refness as the
constructor from which they are invoked) come to mind:

some_class object(...); //obviously an lvalue, since we are constructing a
named object
foo(some_class(...)); //obviously an rvalue, since we are constructing a
temporary
new some_class(...); //also an lvalue, since any dereference of the pointer
will yield an lvalue reference

am I missing something? I don't think that any of these cases would be
confusing for anyone.



2013/11/12 Daniel Kr=FCgler <daniel.kruegler@gmail.com>

> 2013/11/12 xavi <gratal@gmail.com>:
> > Which was the reason for not allowing ref-qualification of constructors
> in
> > C++11? Has there been any proposal to introduce them?
>
> You need to explain the specific semantics of this qualification:
> Constructors don't act on an existing object, so neither
> cv-qualification nor ref-qualifiers make sense with the existing
> meaning of such qualifications.
>
> - 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/.
>

--=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/.

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

<div dir=3D"ltr">I have to admit I haven&#39;t given it a lot of thought, b=
ut right now three ways to invoke a constructor (other than delegating cons=
tructors or constructors of base classes, which should have the same refnes=
s as the constructor from which they are invoked) come to mind:<div>
<br></div><div>some_class object(...); //obviously an lvalue, since we are =
constructing a named object</div><div>foo(some_class(...)); //obviously an =
rvalue, since we are constructing a temporary</div><div>new some_class(...)=
; //also an lvalue, since any dereference of the pointer will yield an lval=
ue reference</div>
<div><br></div><div>am I missing something? I don&#39;t think that any of t=
hese cases would be confusing for anyone.<br></div><div><br></div></div><di=
v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/12 Danie=
l Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.c=
om" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/11/12 xavi &lt;<a href=3D"mailto:gratal=
@gmail.com">gratal@gmail.com</a>&gt;:<br>
<div class=3D"im">&gt; Which was the reason for not allowing ref-qualificat=
ion of constructors in<br>
&gt; C++11? Has there been any proposal to introduce them?<br>
<br>
</div>You need to explain the specific semantics of this qualification:<br>
Constructors don&#39;t act on an existing object, so neither<br>
cv-qualification nor ref-qualifiers make sense with the existing<br>
meaning of such qualifications.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3ce545c6b5804eaf79eab--

.

On 12 November 2013 11:39, xavi <gratal@gmail.com> wrote:
> I have to admit I haven't given it a lot of thought, but right now three
> ways to invoke a constructor (other than delegating constructors or
> constructors of base classes, which should have the same refness as the
> constructor from which they are invoked) come to mind:
>
> some_class object(...); //obviously an lvalue, since we are constructing a
> named object
> foo(some_class(...)); //obviously an rvalue, since we are constructing a
> temporary
> new some_class(...); //also an lvalue, since any dereference of the pointer
> will yield an lvalue reference
>
> am I missing something? I don't think that any of these cases would be
> confusing for anyone.

How did you imagine implementing this knowledge of construction context,
aka the lvalueness, in constructors? Pass a flag internally? That will likely
be a serious ABI break.

--

---
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/.

.

I don't understand how it is any different from other ref-qualified member =
functions. There are two different constructors (when they are actually imp=
lemented separately) and the compiler selects one of them. Was it not ABI-b=
reaking to implement ref-qualification in the first place?

> On 12 Nov 2013, at 10:42, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:
>=20
>> On 12 November 2013 11:39, xavi <gratal@gmail.com> wrote:
>> I have to admit I haven't given it a lot of thought, but right now three
>> ways to invoke a constructor (other than delegating constructors or
>> constructors of base classes, which should have the same refness as the
>> constructor from which they are invoked) come to mind:
>>=20
>> some_class object(...); //obviously an lvalue, since we are constructing=
 a
>> named object
>> foo(some_class(...)); //obviously an rvalue, since we are constructing a
>> temporary
>> new some_class(...); //also an lvalue, since any dereference of the poin=
ter
>> will yield an lvalue reference
>>=20
>> am I missing something? I don't think that any of these cases would be
>> confusing for anyone.
>=20
> How did you imagine implementing this knowledge of construction context,
> aka the lvalueness, in constructors? Pass a flag internally? That will li=
kely
> be a serious ABI break.
>=20
> --=20
>=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=
 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-propo=
sals/.

--=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/.

.

On 12 November 2013 11:52, Xavi <gratal@gmail.com> wrote:
> I don't understand how it is any different from other ref-qualified membe=
r functions. There are two different constructors (when they are actually i=
mplemented separately) and the compiler selects one of them. Was it not ABI=
-breaking to implement ref-qualification in the first place?

The other ref-qualified member functions already have a parameter they
can use, namely 'this'.

Having said that, I don't suppose the idea of having ref-qualified
constructors is that much different
from having in-charge constructors and not-in-charge constructors (which ar=
e
used for delegating cases, a delegation target that is not a
constructor of a most-derived-class
is a not-in-charge constructor and doesn't construct a virtual base,
for example).
Even so, that certainly seems like an additional parameter hidden
inside the implementation,
so it probably has ABI effects.

--=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/.

.

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

I still don't see the difference. Constructors also have the 'this'
parameter, since they don't allocate the memory for the object, they merely
manipulate it, just like any other member function. I'm not saying it
doesn't have ABI effects, I'm just saying that it should have the same
effects that introducing ref-qualified member functions had.


2013/11/12 Ville Voutilainen <ville.voutilainen@gmail.com>

> On 12 November 2013 11:52, Xavi <gratal@gmail.com> wrote:
> > I don't understand how it is any different from other ref-qualified
> member functions. There are two different constructors (when they are
> actually implemented separately) and the compiler selects one of them. Was
> it not ABI-breaking to implement ref-qualification in the first place?
>
> The other ref-qualified member functions already have a parameter they
> can use, namely 'this'.
>
> Having said that, I don't suppose the idea of having ref-qualified
> constructors is that much different
> from having in-charge constructors and not-in-charge constructors (which
> are
> used for delegating cases, a delegation target that is not a
> constructor of a most-derived-class
> is a not-in-charge constructor and doesn't construct a virtual base,
> for example).
> Even so, that certainly seems like an additional parameter hidden
> inside the implementation,
> so it probably has ABI effects.
>
> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">I still don&#39;t see the difference. Constructors also ha=
ve the &#39;this&#39; parameter, since they don&#39;t allocate the memory f=
or the object, they merely manipulate it, just like any other member functi=
on. I&#39;m not saying it doesn&#39;t have ABI effects, I&#39;m just saying=
 that it should have the same effects that introducing ref-qualified member=
 functions had.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11/12 Vi=
lle Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@g=
mail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span><br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
<div class=3D"im">On 12 November 2013 11:52, Xavi &lt;<a href=3D"mailto:gra=
tal@gmail.com">gratal@gmail.com</a>&gt; wrote:<br>
&gt; I don&#39;t understand how it is any different from other ref-qualifie=
d member functions. There are two different constructors (when they are act=
ually implemented separately) and the compiler selects one of them. Was it =
not ABI-breaking to implement ref-qualification in the first place?<br>

<br>
</div>The other ref-qualified member functions already have a parameter the=
y<br>
can use, namely &#39;this&#39;.<br>
<br>
Having said that, I don&#39;t suppose the idea of having ref-qualified<br>
constructors is that much different<br>
from having in-charge constructors and not-in-charge constructors (which ar=
e<br>
used for delegating cases, a delegation target that is not a<br>
constructor of a most-derived-class<br>
is a not-in-charge constructor and doesn&#39;t construct a virtual base,<br=
>
for example).<br>
Even so, that certainly seems like an additional parameter hidden<br>
inside the implementation,<br>
so it probably has ABI effects.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc9574aea0c904eaf96081--

.

On 12 November 2013 13:44, xavi <gratal@gmail.com> wrote:
> I still don't see the difference. Constructors also have the 'this'
> parameter, since they don't allocate the memory for the object, they merely
> manipulate it, just like any other member function. I'm not saying it
> doesn't have ABI effects, I'm just saying that it should have the same
> effects that introducing ref-qualified member functions had.

Ok, seems plausible.

Would a ref-qualified constructor solve the problem? Having
string_view(string&& s) && : string_view(s) {}
doesn't guarantee the string_view has a shorter lifetime than the
rvalue string it's viewing.

--

---
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/.

.

On 12 November 2013 13:52, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 12 November 2013 13:44, xavi <gratal@gmail.com> wrote:
>> I still don't see the difference. Constructors also have the 'this'
>> parameter, since they don't allocate the memory for the object, they merely
>> manipulate it, just like any other member function. I'm not saying it
>> doesn't have ABI effects, I'm just saying that it should have the same
>> effects that introducing ref-qualified member functions had.
>
> Ok, seems plausible.
>
> Would a ref-qualified constructor solve the problem? Having
> string_view(string&& s) && : string_view(s) {}
> doesn't guarantee the string_view has a shorter lifetime than the
> rvalue string it's viewing.

To elaborate: which constructor would this call:

string_view&& yay_lifetime_extension = string_view(string());

If it invokes the lvalue one, we're safe again since that's deleted.
So ok so far.
The idea of this facility certainly seems interesting.

--

---
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/.

.

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

Yes, that should be an exception and call the lvalue constructor. The whole
statement is somewhat exceptional in that it extends the lifetime of a
temporary, making it not temporary anymore.
There is another hard to handle case:

string_view foo()
{
    return string_view(string());
}

This should call the rvalue constructor, which makes sense, and immediately
end up with a dangling reference. I don't see any reason why it couldn't be
made to call the lvalue constructor, since it is equivalent to:

string_view a(string());
return a;

which would use the lvalue constructor. This could be used to avoid lots of
dangling references.
The whole thing would still blow up with:

string_view foo()
{
    string a;
    return string_view(a);
}

If we want C++ to be as flexible as it is, there will always be ways to end
up with dangling references. I think ref-qualifying constructors could help
diagnose some of them.


2013/11/12 Ville Voutilainen <ville.voutilainen@gmail.com>

> On 12 November 2013 13:52, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 12 November 2013 13:44, xavi <gratal@gmail.com> wrote:
> >> I still don't see the difference. Constructors also have the 'this'
> >> parameter, since they don't allocate the memory for the object, they
> merely
> >> manipulate it, just like any other member function. I'm not saying it
> >> doesn't have ABI effects, I'm just saying that it should have the same
> >> effects that introducing ref-qualified member functions had.
> >
> > Ok, seems plausible.
> >
> > Would a ref-qualified constructor solve the problem? Having
> > string_view(string&& s) && : string_view(s) {}
> > doesn't guarantee the string_view has a shorter lifetime than the
> > rvalue string it's viewing.
>
> To elaborate: which constructor would this call:
>
> string_view&& yay_lifetime_extension = string_view(string());
>
> If it invokes the lvalue one, we're safe again since that's deleted.
> So ok so far.
> The idea of this facility certainly seems interesting.
>
> --
>
> ---
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">Yes, that should be an exception and call the lvalue const=
ructor. The whole statement is somewhat exceptional in that it extends the =
lifetime of a temporary, making it not temporary anymore.<div>There is anot=
her hard to handle case:</div>
<div><br></div><div>string_view foo()</div><div>{</div><div>=A0 =A0 return =
string_view(string());</div><div>}</div><div><br></div><div>This should cal=
l the rvalue constructor, which makes sense, and immediately end up with a =
dangling reference. I don&#39;t see any reason why it couldn&#39;t be made =
to call the lvalue constructor, since it is equivalent to:</div>
<div><br></div><div>string_view a(string());</div><div>return a;</div><div>=
<br></div><div>which would use the lvalue constructor. This could be used t=
o avoid lots of dangling references.</div><div>The whole thing would still =
blow up with:</div>
<div><br></div><div>string_view foo()</div><div>{</div><div>=A0 =A0 string =
a;</div><div>=A0 =A0 return string_view(a);</div><div>}</div><div><br></div=
><div>If we want C++ to be as flexible as it is, there will always be ways =
to end up with dangling references. I think ref-qualifying constructors cou=
ld help diagnose some of them.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/11=
/12 Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutila=
inen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
On 12 November 2013 13:52, Ville Voutilainen<br>
<div class=3D"im">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.=
voutilainen@gmail.com</a>&gt; wrote:<br>
&gt; On 12 November 2013 13:44, xavi &lt;<a href=3D"mailto:gratal@gmail.com=
">gratal@gmail.com</a>&gt; wrote:<br>
&gt;&gt; I still don&#39;t see the difference. Constructors also have the &=
#39;this&#39;<br>
&gt;&gt; parameter, since they don&#39;t allocate the memory for the object=
, they merely<br>
&gt;&gt; manipulate it, just like any other member function. I&#39;m not sa=
ying it<br>
&gt;&gt; doesn&#39;t have ABI effects, I&#39;m just saying that it should h=
ave the same<br>
&gt;&gt; effects that introducing ref-qualified member functions had.<br>
&gt;<br>
&gt; Ok, seems plausible.<br>
&gt;<br>
&gt; Would a ref-qualified constructor solve the problem? Having<br>
&gt; string_view(string&amp;&amp; s) &amp;&amp; : string_view(s) {}<br>
&gt; doesn&#39;t guarantee the string_view has a shorter lifetime than the<=
br>
&gt; rvalue string it&#39;s viewing.<br>
<br>
</div>To elaborate: which constructor would this call:<br>
<br>
string_view&amp;&amp; yay_lifetime_extension =3D string_view(string());<br>
<br>
If it invokes the lvalue one, we&#39;re safe again since that&#39;s deleted=
..<br>
So ok so far.<br>
The idea of this facility certainly seems interesting.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c126d62b2104eaf9c0ac--

.

On 12 November 2013 14:11, xavi <gratal@gmail.com> wrote:
> Yes, that should be an exception and call the lvalue constructor. The whole
> statement is somewhat exceptional in that it extends the lifetime of a
> temporary, making it not temporary anymore.
> There is another hard to handle case:
>
> string_view foo()
> {
>     return string_view(string());
> }
>
> This should call the rvalue constructor, which makes sense, and immediately
> end up with a dangling reference. I don't see any reason why it couldn't be
> made to call the lvalue constructor, since it is equivalent to:
>
> string_view a(string());
> return a;
>
> which would use the lvalue constructor. This could be used to avoid lots of
> dangling references.

I certainly think it could be made to call the lvalue ctor, the
language rules for that
are already in place, it's a local temporary and elision rules apply,
so it shouldn't
be hard to call the lvalue ctor there. I'm talking about the rule that
allows return
to move automatically.

> The whole thing would still blow up with:
>
> string_view foo()
> {
>     string a;
>     return string_view(a);
> }

Same thing, local temporary, elision rules apply, I think we could make that
call the lvalue ctor.

Now the question is whether the problem is common enough to have to explain
this to users, and to specify and implement such a new rule. I don't
want to predict
that yet.

--

---
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/.

.

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

2013/11/12 Ville Voutilainen <ville.voutilainen@gmail.com>

> On 12 November 2013 14:11, xavi <gratal@gmail.com> wrote:
> > Yes, that should be an exception and call the lvalue constructor. The
> whole
> > statement is somewhat exceptional in that it extends the lifetime of a
> > temporary, making it not temporary anymore.
> > There is another hard to handle case:
> >
> > string_view foo()
> > {
> >     return string_view(string());
> > }
> >
> > This should call the rvalue constructor, which makes sense, and
> immediately
> > end up with a dangling reference. I don't see any reason why it couldn't
> be
> > made to call the lvalue constructor, since it is equivalent to:
> >
> > string_view a(string());
> > return a;
> >
> > which would use the lvalue constructor. This could be used to avoid lots
> of
> > dangling references.
>
> I certainly think it could be made to call the lvalue ctor, the
> language rules for that
> are already in place, it's a local temporary and elision rules apply,
> so it shouldn't
> be hard to call the lvalue ctor there. I'm talking about the rule that
> allows return
> to move automatically.
>
> > The whole thing would still blow up with:
> >
> > string_view foo()
> > {
> >     string a;
> >     return string_view(a);
> > }
>
> Same thing, local temporary, elision rules apply, I think we could make
> that
> call the lvalue ctor.
>
> Yes, it would call the lvalue constructor, but it would call it with an
lvalue as a parameter, so there is no way to stop this from compiling. But
people should know not to return references to temporaries, and string_view
is a reference.

Now the question is whether the problem is common enough to have to explain
> this to users, and to specify and implement such a new rule. I don't
> want to predict
> that yet.
>
> I don't think it's harder than, for example, the rules for reference
collapsing, or that a named rvalue reference is actually an lvalue. They
are things that most users need not care about. They should just know that
you shouldn't construct non-temporary string_views from temporary strings.
This is something they will need to know whether we find a way to actually
forbid it or not. All this would introduce is a way to enforce good
practice.

> --
>
> ---
> 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/.
>

--

---
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/.

--001a11c3ddd0fe8ed604eafa0a17
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">2013/11/12 Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.co=
m</a>&gt;</span><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">On 12 November 2013 14:11,=
 xavi &lt;<a href=3D"mailto:gratal@gmail.com">gratal@gmail.com</a>&gt; wrot=
e:<br>

&gt; Yes, that should be an exception and call the lvalue constructor. The =
whole<br>
&gt; statement is somewhat exceptional in that it extends the lifetime of a=
<br>
&gt; temporary, making it not temporary anymore.<br>
&gt; There is another hard to handle case:<br>
&gt;<br>
&gt; string_view foo()<br>
&gt; {<br>
&gt; =A0 =A0 return string_view(string());<br>
&gt; }<br>
&gt;<br>
&gt; This should call the rvalue constructor, which makes sense, and immedi=
ately<br>
&gt; end up with a dangling reference. I don&#39;t see any reason why it co=
uldn&#39;t be<br>
&gt; made to call the lvalue constructor, since it is equivalent to:<br>
&gt;<br>
&gt; string_view a(string());<br>
&gt; return a;<br>
&gt;<br>
&gt; which would use the lvalue constructor. This could be used to avoid lo=
ts of<br>
&gt; dangling references.<br>
<br>
</div>I certainly think it could be made to call the lvalue ctor, the<br>
language rules for that<br>
are already in place, it&#39;s a local temporary and elision rules apply,<b=
r>
so it shouldn&#39;t<br>
be hard to call the lvalue ctor there. I&#39;m talking about the rule that<=
br>
allows return<br>
to move automatically.<br>
<div class=3D"im"><br>
&gt; The whole thing would still blow up with:<br>
&gt;<br>
&gt; string_view foo()<br>
&gt; {<br>
&gt; =A0 =A0 string a;<br>
&gt; =A0 =A0 return string_view(a);<br>
&gt; }<br>
<br>
</div>Same thing, local temporary, elision rules apply, I think we could ma=
ke that<br>
call the lvalue ctor.<br>
<br></blockquote><div>Yes, it would call the lvalue constructor, but it wou=
ld call it with an lvalue as a parameter, so there is no way to stop this f=
rom compiling. But people should know not to return references to temporari=
es, and string_view is a reference.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Now the question is whether the problem is common enough to have to explain=
<br>
this to users, and to specify and implement such a new rule. I don&#39;t<br=
>
want to predict<br>
that yet.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>I=
 don&#39;t think it&#39;s harder than, for example, the rules for reference=
 collapsing, or that a named rvalue reference is actually an lvalue. They a=
re things that most users need not care about. They should just know that y=
ou shouldn&#39;t construct non-temporary string_views from temporary string=
s. This is something they will need to know whether we find a way to actual=
ly forbid it or not. All this would introduce is a way to enforce good prac=
tice.=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3ddd0fe8ed604eafa0a17--

.

On 12 November 2013 14:32, xavi <gratal@gmail.com> wrote:
>> > string_view foo()
>> > {
>> >     string a;
>> >     return string_view(a);
>> > }
>>
>> Same thing, local temporary, elision rules apply, I think we could make
>> that
>> call the lvalue ctor.
>>
> Yes, it would call the lvalue constructor, but it would call it with an
> lvalue as a parameter, so there is no way to stop this from compiling. But
> people should know not to return references to temporaries, and string_view
> is a reference.

Well, there is a way, but we would begin to require implementations to track
both lifetimes, and even that doesn't necessarily do the right thing
and we can't
know whether the user intended the lvalue-ctor-with-rvalue-arg or
something else.

>
>> Now the question is whether the problem is common enough to have to
>> explain
>> this to users, and to specify and implement such a new rule. I don't
>> want to predict
>> that yet.
>>
> I don't think it's harder than, for example, the rules for reference
> collapsing, or that a named rvalue reference is actually an lvalue. They are
> things that most users need not care about. They should just know that you
> shouldn't construct non-temporary string_views from temporary strings. This
> is something they will need to know whether we find a way to actually forbid
> it or not. All this would introduce is a way to enforce good practice.

What certainly gives me pause is invoking the lvalue constructor for something
that is clearly a temporary, even though that pause isn't long.

Perhaps this can be solved by implementation diagnostics. That may not be
a perfect solution, but it's certainly a more light-weight solution that a whole
new facility, as intriguing a facility it may be.

--

---
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/.

.

On 11/12/13 7:12 PM, Ville Voutilainen wrote:
> On 12 November 2013 11:52, Xavi <gratal@gmail.com> wrote:
>> I don't understand how it is any different from other ref-qualified memb=
er functions. There are two different constructors (when they are actually =
implemented separately) and the compiler selects one of them. Was it not AB=
I-breaking to implement ref-qualification in the first place?
> The other ref-qualified member functions already have a parameter they
> can use, namely 'this'.
>
> Having said that, I don't suppose the idea of having ref-qualified
> constructors is that much different
> from having in-charge constructors and not-in-charge constructors (which =
are
> used for delegating cases, a delegation target that is not a
> constructor of a most-derived-class
> is a not-in-charge constructor and doesn't construct a virtual base,
> for example).
> Even so, that certainly seems like an additional parameter hidden
> inside the implementation,
> so it probably has ABI effects.

Are you less opposed to ref-qualified constructors than destructors? The=20
latter also may have an in-charge mode to support dynamic type=20
semantics. Destructors make more sense to me because it's more obvious=20
that the object has a name at the end of its scope, although I suppose a=20
name bound to a temporary refers to its storage which exists from just=20
before the beginning of its lifetime.

Either way, having a single type with both overloads would be fairly=20
bizarre. Seems to imply tracking compile-time information at runtime.

Also, string_view looks more like an application of a passive,=20
non-allocating allocator, or a generic container proxy, than a distinct=20
class.

--=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/.

.

On 12 November 2013 14:46, David Krauss <potswa@gmail.com> wrote:
> On 11/12/13 7:12 PM, Ville Voutilainen wrote:
>>
>> On 12 November 2013 11:52, Xavi <gratal@gmail.com> wrote:
>>>
>>> I don't understand how it is any different from other ref-qualified
>>> member functions. There are two different constructors (when they are
>>> actually implemented separately) and the compiler selects one of them. Was
>>> it not ABI-breaking to implement ref-qualification in the first place?
>>
>> The other ref-qualified member functions already have a parameter they
>> can use, namely 'this'.
>>
>> Having said that, I don't suppose the idea of having ref-qualified
>> constructors is that much different
>> from having in-charge constructors and not-in-charge constructors (which
>> are
>> used for delegating cases, a delegation target that is not a
>> constructor of a most-derived-class
>> is a not-in-charge constructor and doesn't construct a virtual base,
>> for example).
>> Even so, that certainly seems like an additional parameter hidden
>> inside the implementation,
>> so it probably has ABI effects.
>
>
> Are you less opposed to ref-qualified constructors than destructors? The
> latter also may have an in-charge mode to support dynamic type semantics.
> Destructors make more sense to me because it's more obvious that the object
> has a name at the end of its scope, although I suppose a name bound to a
> temporary refers to its storage which exists from just before the beginning
> of its lifetime.

Yes, I am, especially if that results in programmers writing multiple
destructors.
They already have multiple constructors, and delegating constructors solve
some of the related problems. I feel queasy about multiple destructors
and delegation in them, but I suppose delegating destructors would be
palatable, if a bit hard to swallow.

I think I would much prefer leaving the detection of possible problems with
classes such as string_view to implementations, and tell the programmers
to be careful with what they do, all in all.

--

---
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/.

.

On Tue, Nov 12, 2013 at 12:48 AM, Alex B <devalexb@gmail.com> wrote:
> Reference wrapper is not meant to be used in all the same contexts. For me,
> one of the major selling point for string_view is that it should most of the
> time be used as a function parameter.
>
> string foo();
>
> void bar(string_view s);
>
> void f()
> {
>     bar(foo()); // this is perfectly valid; are you suggesting not allowing
> this?
> }

Ah, I was shot down.  reference_wrapper has std::cref,
but string_view does not, and can 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/.

.

------=_Part_3503_16472955.1388088003418
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, November 12, 2013 4:18:16 AM UTC+1, jgot...@gmail.com wrote:
>
> As the string_view class is currently written, the following code will
> cause an access to a destructed object and probably a crash:
>
> std::string foo();
>
> int main() {
>     string_view view(foo(), 0, 3);
>     std::cout << view;
> }
>
> When the string_view is created, it stores pointers into the temporary
> string created by foo(), which is then destroyed, leaving the string_view
> with pointers to garbage. I know that if the string_view were immediately
> sent to cout without creating an lvalue everything would have been fine.
> However, this seems dangerous enough that it might be a good idea to forbid
> creating a string_view from an rvalue std::string, by deleting the
> constructor and assignment operator from rvalue strings.
>

Wouldn't this disallow directly passing the output of foo() into a function
taking a string_view? That'd suck.

>
>

--

---
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_3503_16472955.1388088003418
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, November 12, 2013 4:18:16 AM UTC+1, jg=
ot...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">As the string_view class is currently written, the following code =
will cause an access to a destructed object and probably a crash:<br><br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span=
 style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span s=
tyle=3D"color:#008">string</span><span style=3D"color:#000"> foo</span><spa=
n style=3D"color:#660">();</span><span style=3D"color:#000"><br><br></span>=
<span style=3D"color:#008">int</span><span style=3D"color:#000"> main</span=
><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp=
; string_view view</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">foo</span><span style=3D"color:#660">(),</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#066"=
>3</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br=
>&nbsp; &nbsp; std</span><span style=3D"color:#660">::</span><span style=3D=
"color:#000">cout </span><span style=3D"color:#660">&lt;&lt;</span><span st=
yle=3D"color:#000"> view</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><br>When the string_view is c=
reated, it stores pointers into the temporary string created by foo(), whic=
h is then destroyed, leaving the string_view with pointers to garbage. I kn=
ow that if the string_view were immediately sent to cout without creating a=
n lvalue everything would have been fine.&nbsp; However, this seems dangero=
us enough that it might be a good idea to forbid creating a string_view fro=
m an rvalue std::string, by deleting the constructor and assignment operato=
r from rvalue strings.</div></blockquote><div><br></div><div>Wouldn't this =
disallow directly passing the output of foo() into a function taking a stri=
ng_view? That'd suck.&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr">&nbsp;<br></div></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3503_16472955.1388088003418--

.