------=_Part_2099_15403860.1403580087398
Content-Type: text/plain; charset=UTF-8

Hi!

Following a talk by Scott Meyers, he mentions an example of the form

vector<bool> f();
auto x = f()[5];
bool y = x;

In GCC, and it's reasonable to implement it this way,
vector<bool>::reference is a word pointer plus an offset to a bit in that
word. Thus x, which is of type vector<bool>::reference, has a pointer to a
block of memory which will be deleted by the time the assignment on line 3
happens. Thus this fragment causes undefined behavior.

Seeing how this is a reasonable implementation for vector<bool>::reference,
would it not make sense to have the following added to vector<bool>?

  reference operator[](size_t) && = delete;

Making it so a call to operator[] on an rvalue reference will fail to
compile? Is this already implemented and I missed it, or does it have an
obvious drawback perhaps?

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

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

<div dir=3D"ltr">Hi!<div><br></div><div>Following a talk by Scott Meyers, h=
e mentions an example of the form</div><div><br></div><div>vector&lt;bool&g=
t; f();</div><div><span style=3D"font-size: 13px;">auto x =3D f()[5];</span=
><br></div><div>bool y =3D x;</div><div><br></div><div>In GCC, and it's rea=
sonable to implement it this way, vector&lt;bool&gt;::reference is a word p=
ointer plus an offset to a bit in that word. Thus x, which is of type vecto=
r&lt;bool&gt;::reference, has a pointer to a block of memory which will be =
deleted by the time the assignment on line 3 happens. Thus this fragment ca=
uses undefined behavior.</div><div><br></div><div>Seeing how this is a reas=
onable implementation for vector&lt;bool&gt;::reference, would it not make =
sense to have the following added to vector&lt;bool&gt;?</div><div><br></di=
v><div>&nbsp; reference operator[](size_t) &amp;&amp; =3D delete;</div><div=
><br></div><div>Making it so a call to operator[] on an rvalue reference wi=
ll fail to compile? Is this already implemented and I missed it, or does it=
 have an obvious drawback perhaps?</div><div><br></div><div>Thanks :)</div>=
</div>

<p></p>

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

------=_Part_2099_15403860.1403580087398--

.

--Apple-Mail=_FC68A0A5-8842-4CDD-81AF-DCD2BE7D83A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-24, at 11:21 AM, federico.lebron@gmail.com wrote:

> Making it so a call to operator[] on an rvalue reference will fail to com=
pile? Is this already implemented and I missed it, or does it have an obvio=
us drawback perhaps?

The problem with the example is that it accidentally captures the proxy typ=
e by using auto instead of bool. Examples using bool, which was the only wa=
y to do it before C++11 added auto, would become ill-formed for no reason.

There's currently a proposal to "fix" the behavior of auto in this case, an=
d then there would be no reason to make the example ill-formed. I also have=
 a plan to propose adding ref-qualifiers to class-specifiers, to forbid pro=
xy objects from being named (and forbid guard objects from being not-named)=
.. It would cover your example among many other cases.

Long story short: it's a core language issue, not a library bug.

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

--Apple-Mail=_FC68A0A5-8842-4CDD-81AF-DCD2BE7D83A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;24, at 11:21 AM, <a href=3D"mailto:federico.lebron@gmail.com=
">federico.lebron@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-=
newline"><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Making it so a c=
all to operator[] on an rvalue reference will fail to compile? Is this alre=
ady implemented and I missed it, or does it have an obvious drawback perhap=
s?</div></blockquote><br></div><div>The problem with the example is that it=
 accidentally captures the proxy type by using <font face=3D"Courier">auto<=
/font> instead of <font face=3D"Courier">bool</font>. Examples using <font =
face=3D"Courier">bool</font>, which was the only way to do it before C++11 =
added <font face=3D"Courier">auto</font>, would become ill-formed for no re=
ason.</div><div><br></div><div>There&rsquo;s currently a proposal to &ldquo=
;fix&rdquo; the behavior of <font face=3D"Courier">auto</font> in this case=
, and then there would be no reason to make the example ill-formed. I also =
have a plan to propose adding ref-qualifiers to class-specifiers, to forbid=
 proxy objects from being named (and forbid guard objects from being not-na=
med). It would cover your example among many other cases.</div><div><br></d=
iv><div>Long story short: it&rsquo;s a core language issue, not a library b=
ug.</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_FC68A0A5-8842-4CDD-81AF-DCD2BE7D83A5--

.

Em seg 23 jun 2014, =E0s 20:21:27, federico.lebron@gmail.com escreveu:
> Hi!
>=20
> Following a talk by Scott Meyers, he mentions an example of the form
>=20
> vector<bool> f();
> auto x =3D f()[5];
> bool y =3D x;
>=20
> In GCC, and it's reasonable to implement it this way,
> vector<bool>::reference is a word pointer plus an offset to a bit in that
> word. Thus x, which is of type vector<bool>::reference, has a pointer to =
a
> block of memory which will be deleted by the time the assignment on line =
3
> happens. Thus this fragment causes undefined behavior.

If you change it to vector<int>, it's still wrong.

> Seeing how this is a reasonable implementation for vector<bool>::referenc=
e,
> would it not make sense to have the following added to vector<bool>?
>=20
>   reference operator[](size_t) && =3D delete;

Make your case for vector<T>. The same applies.

Anyway, you don't need to delete it. Just don't define the rvalue one. Defi=
ne=20
the lvalue only.

That's an API/ABI break, though. I doubt it can be accepted.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.

Em seg 23 jun 2014, =E0s 21:39:01, Thiago Macieira escreveu:
> Em seg 23 jun 2014, =E0s 20:21:27, federico.lebron@gmail.com escreveu:
> > Hi!
> >=20
> > Following a talk by Scott Meyers, he mentions an example of the form
> >=20
> > vector<bool> f();
> > auto x =3D f()[5];
> > bool y =3D x;
> >=20
> > In GCC, and it's reasonable to implement it this way,
> > vector<bool>::reference is a word pointer plus an offset to a bit in th=
at
> > word. Thus x, which is of type vector<bool>::reference, has a pointer t=
o a
> > block of memory which will be deleted by the time the assignment on lin=
e 3
> > happens. Thus this fragment causes undefined behavior.
>=20
> If you change it to vector<int>, it's still wrong.

Oops, never mind, it isn't.

decltype(auto) x =3D f()[5];

would be, but that's not what you wrote.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.