Topic: Draft D0065: Movable initializer lists, rev. 2
Author: David Krauss <potswa@gmail.com>
Date: Fri, 18 Sep 2015 09:34:09 +0800
Raw View
--Apple-Mail=_E1936752-7FA9-426C-BFB8-ECA694D0D1E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Here is the next initializer list proposal. It should be better motivated, =
better specified, and better rationalized. Review would be appreciated.
Abstract:
Elements must be copied, not moved, from std::initializer_list, as it provi=
des read-only, =E2=80=9Cview=E2=80=9D access to a const-qualified sequence.=
This causes a loss of performance and generality which often renders it un=
usable. A new template own_initializer_list is proposed to provide proper o=
wnership of the initializer list sequence. It works like a move-only, fixed=
-length, stack-allocated std::vector under an initializer_list-like class i=
nterface.
Interface synopsis:
template< typename T >
struct own_initializer_list
: initializer_list< T > {
typedef T & reference;
typedef T * iterator;
using initializer_list< T >::begin;
constexpr iterator begin() noexcept;
using initializer_list< T >::end;
constexpr iterator end() noexcept;
constexpr own_initializer_list() noexcept;
own_initializer_list
( own_initializer_list const & ) =3D delete;
constexpr own_initializer_list
( own_initializer_list && ) noexcept; // Post: size() =3D=3D 0.
~ initializer_list();
};
PDF: bit.ly/mov-il <http://bit.ly/mov-il>
--=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=_E1936752-7FA9-426C-BFB8-ECA694D0D1E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">He=
re is the next initializer list proposal. It should be better motivated, be=
tter specified, and better rationalized. Review would be appreciated.</div>=
<div class=3D""><br class=3D""></div>Abstract:<div class=3D""><br class=3D"=
"></div><div class=3D""><p style=3D"margin: 0px 0px 16px; font-family: Time=
s; -webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-stroke-width: init=
ial;" class=3D"">Elements must be copied, not moved, from <span style=3D"fo=
nt-size: 11px; font-family: Courier; background-color: rgb(245, 245, 245);"=
class=3D"">std::initializer_list</span>, as it provides read-only, =E2=80=
=9Cview=E2=80=9D access to a <span style=3D"font-size: 11px; font-family: C=
ourier; background-color: rgb(245, 245, 245);" class=3D"">const</span>-qual=
ified sequence. This causes a loss of performance and generality which ofte=
n renders it unusable. A new template <span style=3D"font-size: 11px; font-=
family: Courier; background-color: rgb(245, 245, 245);" class=3D"">own_init=
ializer_list</span> is proposed to provide proper ownership of the initiali=
zer list sequence. It works like a move-only, fixed-length, stack-allocated=
<span style=3D"font-size: 11px; font-family: Courier; background-color: rg=
b(245, 245, 245);" class=3D"">std::vector</span> under an <span style=3D"fo=
nt-size: 11px; font-family: Courier; background-color: rgb(245, 245, 245);"=
class=3D"">initializer_list</span>-like class interface.</p></div><div cla=
ss=3D"">Interface synopsis:</div><div class=3D""><br class=3D""></div><div =
class=3D""><font face=3D"Courier" class=3D"">template< typename T ><b=
r class=3D"">struct own_initializer_list<br class=3D""> :=
initializer_list< T > {<br class=3D""> typedef T &=
amp; reference;<br class=3D""> typedef T * iterator;<br c=
lass=3D""><br class=3D""> using initializer_list< T &g=
t;::begin;<br class=3D""> constexpr iterator begin() noex=
cept;<br class=3D""> using initializer_list< T >::e=
nd;<br class=3D""> constexpr iterator end() noexcept;<br =
class=3D""><br class=3D""> constexpr own_initializer_list=
() noexcept;<br class=3D""> own_initializer_list<br class=
=3D""> ( own_initializer_list const &a=
mp; ) =3D delete;<br class=3D""> constexpr own_initialize=
r_list<br class=3D""> ( own_initialize=
r_list && ) noexcept; // Post: size() =
=3D=3D 0.<br class=3D""><br class=3D""> ~ initializer_lis=
t();<br class=3D"">};<br class=3D""><br class=3D""></font></div><div class=
=3D"">PDF: <a href=3D"http://bit.ly/mov-il" class=3D"">bit.ly/mov-il</a></d=
iv><div class=3D""><br class=3D""></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" 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=_E1936752-7FA9-426C-BFB8-ECA694D0D1E8--
.
Author: Rodrigo <rcc.dark@gmail.com>
Date: Sat, 19 Sep 2015 18:46:53 -0500
Raw View
--089e014954ac6f5f5c05202244f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi David, sorry for answering until now.
The name "std::own_initializer_list" is probably not worse than the
alternatives ("mutable", "unique", etc), but I think it is too long anyway
(and I say this even though the name I originally proposed was longer...).
The only alternative I can suggest right now is "std::temporary_list". It
could mistakenly relate itself (by name) to the "std::get_temporary_buffer"
function (and friend), but I like it by itself.
While I was reading the part that says that ~std::own_initializer_list is
the responsible of destroying the elements, I had to go back and re-read
the part that talks about std::own_initializer_list<my_type> vs
std::own_initializer_list<my_type>&& as an overload. Some code fragment
like the following:
struct my_container {
my_container(std::initializer_list<my_type>);
my_container(std::own_initializer_list<my_type>);
//...
};
is typical when teaching which are the most important constructors in the
implementation of a data structure. It could be good idea to add it,
otherwise the explanation could be lost inside all the text (at first I
understood that we had to use the && overload, but of course this is wrong)=
..
I think I didn't understand the part about the "loop hoisting variant" of
the static storage optimization. Some time ago I was thinking about an
optimization that initializes and leaves constexpr arguments of the
initializer_list untouched and only overwrites those that change at runtime
from use to use. Probably it is similar to the one you mention, but I could
be wrong.
In something much less important, the very first sentence of the paper has
too many commas! I would delete the one after "only".
Cheers!
Rodrigo
2015-09-17 20:34 GMT-05:00 David Krauss <potswa@gmail.com>:
> Here is the next initializer list proposal. It should be better motivated=
,
> better specified, and better rationalized. Review would be appreciated.
>
> Abstract:
>
> Elements must be copied, not moved, from std::initializer_list, as it
> provides read-only, =E2=80=9Cview=E2=80=9D access to a const-qualified se=
quence. This
> causes a loss of performance and generality which often renders it
> unusable. A new template own_initializer_list is proposed to provide
> proper ownership of the initializer list sequence. It works like a
> move-only, fixed-length, stack-allocated std::vector under an
> initializer_list-like class interface.
> Interface synopsis:
>
> template< typename T >
> struct own_initializer_list
> : initializer_list< T > {
> typedef T & reference;
> typedef T * iterator;
>
> using initializer_list< T >::begin;
> constexpr iterator begin() noexcept;
> using initializer_list< T >::end;
> constexpr iterator end() noexcept;
>
> constexpr own_initializer_list() noexcept;
> own_initializer_list
> ( own_initializer_list const & ) =3D delete;
> constexpr own_initializer_list
> ( own_initializer_list && ) noexcept; // Post: size() =3D=3D 0=
..
>
> ~ initializer_list();
> };
>
> PDF: bit.ly/mov-il
>
>
--=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/.
--089e014954ac6f5f5c05202244f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Hi David, sorry for answering unt=
il now.<br><br></div>The name "std::own_initializer_list" is prob=
ably not worse than the alternatives ("mutable", "unique&quo=
t;, etc), but I think it is too long anyway (and I say this even though the=
name I originally proposed was longer...). The only alternative I can sugg=
est right now is "std::temporary_list". It could mistakenly relat=
e itself (by name) to the "std::get_temporary_buffer" function (a=
nd friend), but I like it by itself.<br><br></div>While I was reading the p=
art that says that ~std::own_initializer_list is the responsible of destroy=
ing the elements, I had to go back and re-read the part that talks about st=
d::own_initializer_list<my_type> vs std::own_initializer_list<my_t=
ype>&& as an overload. Some code fragment like the following:<br=
><br></div>struct my_container {<br></div>=C2=A0=C2=A0 my_container(std::in=
itializer_list<my_type>);<br></div>=C2=A0=C2=A0 my_container(std::own=
_initializer_list<my_type>);<br>=C2=A0=C2=A0 //...<br><div><div>};<br=
><br></div><div>is typical when teaching which are the most important const=
ructors in the implementation of a data structure. It could be good idea to=
add it, otherwise the explanation could be lost inside all the text (at fi=
rst I understood that we had to use the && overload, but of course =
this is wrong).<br><br></div><div>I think I didn't understand the part =
about the "loop hoisting variant" of the static storage optimizat=
ion. Some time ago I was thinking about an optimization that initializes an=
d leaves constexpr arguments of the initializer_list untouched and only ove=
rwrites those that change at runtime from use to use. Probably it is simila=
r to the one you mention, but I could be wrong.<br></div><div><br></div><di=
v>In something much less important, the very first sentence of the paper ha=
s too many commas! I would delete the one after "only".<br></div>=
<div>Cheers!<br><br></div><div>Rodrigo<br></div><div><div><br></div></div><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-0=
9-17 20:34 GMT-05:00 David Krauss <span dir=3D"ltr"><<a href=3D"mailto:p=
otswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span>:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Here is=
the next initializer list proposal. It should be better motivated, better =
specified, and better rationalized. Review would be appreciated.</div><div>=
<br></div>Abstract:<div><br></div><div><p style=3D"margin:0px 0px 16px;font=
-family:Times">Elements must be copied, not moved, from <span style=3D"font=
-size:11px;font-family:Courier;background-color:rgb(245,245,245)">std::init=
ializer_list</span>, as it provides read-only, =E2=80=9Cview=E2=80=9D acces=
s to a <span style=3D"font-size:11px;font-family:Courier;background-color:r=
gb(245,245,245)">const</span>-qualified sequence. This causes a loss of per=
formance and generality which often renders it unusable. A new template <sp=
an style=3D"font-size:11px;font-family:Courier;background-color:rgb(245,245=
,245)">own_initializer_list</span> is proposed to provide proper ownership =
of the initializer list sequence. It works like a move-only, fixed-length, =
stack-allocated <span style=3D"font-size:11px;font-family:Courier;backgroun=
d-color:rgb(245,245,245)">std::vector</span> under an <span style=3D"font-s=
ize:11px;font-family:Courier;background-color:rgb(245,245,245)">initializer=
_list</span>-like class interface.</p></div><div>Interface synopsis:</div><=
div><br></div><div><font face=3D"Courier">template< typename T ><br>s=
truct own_initializer_list<br>=C2=A0 =C2=A0=C2=A0: initializer_list< T &=
gt; {<br>=C2=A0 =C2=A0=C2=A0typedef T & reference;<br>=C2=A0 =C2=A0=C2=
=A0typedef T * iterator;<br><br>=C2=A0 =C2=A0=C2=A0using initializer_list&l=
t; T >::begin;<br>=C2=A0 =C2=A0=C2=A0constexpr iterator begin() noexcept=
;<br>=C2=A0 =C2=A0=C2=A0using initializer_list< T >::end;<br>=C2=A0 =
=C2=A0=C2=A0constexpr iterator end() noexcept;<br><br>=C2=A0 =C2=A0=C2=A0co=
nstexpr own_initializer_list() noexcept;<br>=C2=A0 =C2=A0=C2=A0own_initiali=
zer_list<br>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0( own_initializer_list co=
nst & ) =3D delete;<br>=C2=A0 =C2=A0=C2=A0constexpr own_initializer_lis=
t<br>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0( own_initializer_list &&=
; ) noexcept;=C2=A0 =C2=A0=C2=A0//=C2=A0Post:=C2=A0size() =3D=3D 0.<br><br>=
=C2=A0 =C2=A0=C2=A0~ initializer_list();<br>};<br><br></font></div><div>PDF=
: <a href=3D"http://bit.ly/mov-il" target=3D"_blank">bit.ly/mov-il</a></div=
><div><br></div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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 />
--089e014954ac6f5f5c05202244f6--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 20 Sep 2015 13:02:41 +0800
Raw View
--Apple-Mail=_E954A457-5693-4844-8C91-36033AC67ECE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9320, at 7:46 AM, Rodrigo <rcc.dark@gmail.com> w=
rote:
>=20
> Hi David, sorry for answering until now.
No worries, you=E2=80=99re still the first.
> The name "std::own_initializer_list" is probably not worse than the alter=
natives ("mutable", "unique", etc), but I think it is too long anyway (and =
I say this even though the name I originally proposed was longer...). The o=
nly alternative I can suggest right now is "std::temporary_list". It could =
mistakenly relate itself (by name) to the "std::get_temporary_buffer" funct=
ion (and friend), but I like it by itself.
The paper already mentions sequence_literal as an alternative, if we were s=
tarting with a clean slate. Previously it was listed together with the othe=
rs. I=E2=80=99ve re-added that bullet in the naming section, plus your sugg=
estion.
> While I was reading the part that says that ~std::own_initializer_list is=
the responsible of destroying the elements, I had to go back and re-read t=
he part that talks about std::own_initializer_list<my_type> vs std::own_ini=
tializer_list<my_type>&& as an overload. Some code fragment like the follow=
ing:
>=20
> struct my_container {
> my_container(std::initializer_list<my_type>);
> my_container(std::own_initializer_list<my_type>);
> //...
> };
>=20
> is typical when teaching which are the most important constructors in the=
implementation of a data structure. It could be good idea to add it, other=
wise the explanation could be lost inside all the text (at first I understo=
od that we had to use the && overload, but of course this is wrong).
I=E2=80=99ve added an example of by-value and by-&& overloading.
> I think I didn't understand the part about the "loop hoisting variant" of=
the static storage optimization. Some time ago I was thinking about an opt=
imization that initializes and leaves constexpr arguments of the initialize=
r_list untouched and only overwrites those that change at runtime from use =
to use. Probably it is similar to the one you mention, but I could be wrong=
..
It=E2=80=99s along those lines. As far as I know (by hearsay) only EDG impl=
ements this. The paper doesn=E2=80=99t go into depth except to mention that=
it was considered and it shouldn=E2=80=99t present a problem.
> In something much less important, the very first sentence of the paper ha=
s too many commas! I would delete the one after "only=E2=80=9D.
Done.
> Cheers!
Thanks!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_E954A457-5693-4844-8C91-36033AC67ECE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9320, at 7:46 AM, Rodrigo <<a href=3D"mailto:rcc.dark@gmail.com" =
class=3D"">rcc.dark@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">=
<div class=3D""><div class=3D""><div class=3D""><div class=3D"">Hi David, s=
orry for answering until now.<br class=3D""></div></div></div></div></div><=
/div></div></blockquote><div><br class=3D""></div><div>No worries, you=E2=
=80=99re still the first.</div><br class=3D""><blockquote type=3D"cite" cla=
ss=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div cl=
ass=3D""><div class=3D""><div class=3D"">The name "std::own_initializer_lis=
t" is probably not worse than the alternatives ("mutable", "unique", etc), =
but I think it is too long anyway (and I say this even though the name I or=
iginally proposed was longer...). The only alternative I can suggest right =
now is "std::temporary_list". It could mistakenly relate itself (by name) t=
o the "std::get_temporary_buffer" function (and friend), but I like it by i=
tself.<br class=3D""></div></div></div></div></div></div></blockquote><div>=
<br class=3D""></div><div>The paper already mentions <font face=3D"Courier"=
class=3D"">sequence_literal</font> as an alternative, if we were starting =
with a clean slate. Previously it was listed together with the others. I=E2=
=80=99ve re-added that bullet in the naming section, plus your suggestion.<=
/div><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div class=3D""><div c=
lass=3D"">While I was reading the part that says that ~std::own_initializer=
_list is the responsible of destroying the elements, I had to go back and r=
e-read the part that talks about std::own_initializer_list<my_type> v=
s std::own_initializer_list<my_type>&& as an overload. Some c=
ode fragment like the following:<br class=3D""><br class=3D""></div>struct =
my_container {<br class=3D""></div> my_container(std::initializ=
er_list<my_type>);<br class=3D""></div> my_container(std:=
:own_initializer_list<my_type>);<br class=3D""> //...<br =
class=3D""><div class=3D""><div class=3D"">};<br class=3D""><br class=3D"">=
</div><div class=3D"">is typical when teaching which are the most important=
constructors in the implementation of a data structure. It could be good i=
dea to add it, otherwise the explanation could be lost inside all the text =
(at first I understood that we had to use the && overload, but of c=
ourse this is wrong).<br class=3D""></div></div></div></div></blockquote><d=
iv><br class=3D""></div><div>I=E2=80=99ve added an example of by-value and =
by-<font face=3D"Courier" class=3D"">&&</font> overloading.</div><b=
r class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D""><div class=3D"">I think I didn't unders=
tand the part about the "loop hoisting variant" of the static storage optim=
ization. Some time ago I was thinking about an optimization that initialize=
s and leaves constexpr arguments of the initializer_list untouched and only=
overwrites those that change at runtime from use to use. Probably it is si=
milar to the one you mention, but I could be wrong.<br class=3D""></div><di=
v class=3D""></div></div></div></div></blockquote><div><br class=3D""></div=
><div>It=E2=80=99s along those lines. As far as I know (by hearsay) only ED=
G implements this. The paper doesn=E2=80=99t go into depth except to mentio=
n that it was considered and it shouldn=E2=80=99t present a problem.</div><=
br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D""><div class=3D"">In something much less =
important, the very first sentence of the paper has too many commas! I woul=
d delete the one after "only=E2=80=9D.<br class=3D""></div></div></div></di=
v></blockquote><div><br class=3D""></div><div>Done.</div><br class=3D""><bl=
ockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D=
""><div class=3D""><div class=3D"">Cheers!<br class=3D""></div></div></div>=
</div></blockquote></div><div class=3D""><br class=3D""></div>Thanks!<div c=
lass=3D""><br class=3D""></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" 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=_E954A457-5693-4844-8C91-36033AC67ECE--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Sun, 20 Sep 2015 12:02:54 -0700 (PDT)
Raw View
------=_Part_237_781490530.1442775774412
Content-Type: multipart/alternative;
boundary="----=_Part_238_235391780.1442775774412"
------=_Part_238_235391780.1442775774412
Content-Type: text/plain; charset=UTF-8
I have a question regarding the rationale for keeping
own_initializer_list<T> movable. This still may lead to several dangling
reference problems, for example most common one is to treat
own_initializer_list<T> as normal container and store as class member, for
example:
//Building a static composite
struct Component;
typedef std::unique_ptr<Component> ComponentPtr;
struct Composite
{
Composite(own_initializer_list<ComponentPtr>&& a_list) : a_list(m_list) {}
private:
own_initializer_list<ComponentPtr> m_list;
};
Composite c{std::make_unique<ConcreteComposite1>(),
std::make_unique<ConcreteComposite2>()};
//The member m_list is dangling here
//Selecting the list of initializers
boost::optional<own_initializer_list<ComponentPtr>> list;
if (useImplementation1)
list.emplace({std::make_unique<ConcreteComposite1>()});
else
list.emplace({std::make_unique<ConcreteComposite2>()});
//list is dangling now
Both situations are non-trivial to understand and requires knowledge about
internal implementation (stack array) and are source of errors in the
program. Both of them would be fixed by making the own_initializer_list
non-copyable and non-moveable. The cost of the change would be that you
will be no longer able to write:
auto list = {"ala"s, "ola"s};
//Will requires move constructor to intializer from temporary on left hand
side. However the syntax:
auto&& list = {"ala"s, "ola"s};
//Will still be valid.
The functions will be required to accept
own_initializer_list<ComponentPtr>&&, but I do not think that this is a
problem;
There is a situation, when the non-copyable non-moveable class can still be
transfered. One is:
own_initializer_list<ComponentPtr> makeComponets()
{
return {std::make_unique<ConcreteComposite1>(),
std::make_unique<ConcreteComposite2>()};
}
auto && list = makeComponets();
However, I believe in this case the standard will guarantee that list is no
longer dangling. In situation as above, the standard requires that
own_initializer_list<ComponentPtr> will be constructed on call side, as
creation of stack array is part the construction of
own_initializer_list<ComponentPtr>, the array will be placed on call side.
And the second:
auto* p = new
own_initializer_list<ComponentPtr>{std::make_unique<ConcreteComposite1>(),
std::make_unique<ConcreteComposite2>()};
The paper still does not qualify if this is safe. The array may be placed
both on stack (dangling), or on the heap with own_initializer_list<T>
object. Choosing the second resolution and making own_initializer_list
non-moveable will eliminate all dangling reference problems occuring in
situation when own_initializer_list<T> is stored by value. Storing it by
reference, will provide to dangling reference, as for any other class.
--
---
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_238_235391780.1442775774412
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have a question regarding the rationale for keeping own_=
initializer_list<T> movable. This still may lead to several dangling =
reference problems, for example most common one is to treat own_initializer=
_list<T> as normal container and store as class member, for example:<=
br>//Building a static composite<br>struct Component;<br>typedef std::uniqu=
e_ptr<Component> ComponentPtr;<br><br>struct Composite<br>{<br>=C2=A0=
Composite(own_initializer_list<ComponentPtr>&& a_list) : a_l=
ist(m_list) {}<br>=C2=A0=C2=A0 <br>private:<br>=C2=A0 own_initializer_list&=
lt;ComponentPtr> m_list;<br>};<br><br>Composite c{std::make_unique<Co=
ncreteComposite1>(), std::make_unique<ConcreteComposite2>()};<br>/=
/The member m_list is dangling here<br><br>//Selecting the list of initiali=
zers<br>boost::optional<own_initializer_list<ComponentPtr>> lis=
t;<br>if (useImplementation1)<br>=C2=A0 list.emplace({std::make_unique<C=
oncreteComposite1>()});<br>else<br>=C2=A0 list.emplace({std::make_unique=
<ConcreteComposite2>()});<br>//list is dangling now<br><br>Both situa=
tions are non-trivial to understand and requires knowledge about internal i=
mplementation (stack array) and are source of errors in the program. Both o=
f them would be fixed by making the own_initializer_list non-copyable and n=
on-moveable. The cost of the change would be that you will be no longer abl=
e to write:<br>auto list =3D {"ala"s, "ola"s};<br>//Wil=
l requires move constructor to intializer from temporary on left hand side.=
However the syntax:<br>auto&& list =3D {"ala"s, "ol=
a"s};<br>//Will still be valid.<br>The functions will be required to a=
ccept own_initializer_list<ComponentPtr>&&, but I do not thin=
k that this is a problem;<br><br>There is a situation, when the non-copyabl=
e non-moveable class can still be transfered. One is:<br>own_initializer_li=
st<ComponentPtr> makeComponets()<br>{ <br>=C2=A0 return {std::make_un=
ique<ConcreteComposite1>(), std::make_unique<ConcreteComposite2>=
;()};<br>}<br><br>auto && list =3D makeComponets();<br>However, I b=
elieve in this case the standard will guarantee that list is no longer dang=
ling. In situation as above, the standard requires that own_initializer_lis=
t<ComponentPtr> will be constructed on call side, as creation of stac=
k array is part the construction of own_initializer_list<ComponentPtr>=
;, the array will be placed on call side.<br><br>And the second:<br>auto* p=
=3D new own_initializer_list<ComponentPtr>{std::make_unique<Concr=
eteComposite1>(), std::make_unique<ConcreteComposite2>()};<br>The =
paper still does not qualify if this is safe. The array may be placed both =
on stack (dangling), or on the heap with own_initializer_list<T> obje=
ct. Choosing the second resolution and making own_initializer_list non-move=
able will eliminate all dangling reference problems occuring in situation w=
hen own_initializer_list<T> is stored by value. Storing it by referen=
ce, will provide to dangling reference, as for any other class.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_238_235391780.1442775774412--
------=_Part_237_781490530.1442775774412--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 12:11:57 +0800
Raw View
--Apple-Mail=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 3:02 AM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> I have a question regarding the rationale for keeping own_initializer_lis=
t<T> movable. This still may lead to several dangling reference problems, f=
or example most common one is to treat own_initializer_list<T> as normal co=
ntainer and store as class member,
Declaring a class member of own_initializer_list type is a diagnosable erro=
r. See the last paragraph in =C2=A72:
> This likewise requires forbidding cases where initializer_list generates =
dangling pointers: when it is used as a member, a base class, the value of =
a return statement, an exception object, or the type in a new-expression.
>=20
It would be nice if this applied to ordinary initializer_list too, but that=
ship might have sailed. Anyway, it would be another proposal.
Perhaps it should be more strongly worded so as not to appear as a continge=
ncy: =E2=80=9CIt is forbidden to=E2=80=A6=E2=80=9D
> Both situations are non-trivial to understand and requires knowledge abou=
t internal implementation (stack array) and are source of errors in the pro=
gram. Both of them would be fixed by making the own_initializer_list non-co=
pyable and non-moveable.
That would not be sufficient as a fix, because constructing an initializer =
list object from a braced-init-list does not always involve an intermediate=
temporary that needs to be moved.
> The cost of the change would be that you will be no longer able to write:
> auto list =3D {"ala"s, "ola"s};
> //Will requires move constructor to intializer from temporary on left han=
d side. However the syntax:
No, there is no temporary there. Copy-list-initialization, unlike other cop=
y-initialization, does not convert to the type as a temporary and then copy=
-initialize.
> auto&& list =3D {"ala"s, "ola"s};
> //Will still be valid.
> The functions will be required to accept own_initializer_list<ComponentPt=
r>&&, but I do not think that this is a problem;
>=20
> There is a situation, when the non-copyable non-moveable class can still =
be transfered. One is:
> own_initializer_list<ComponentPtr> makeComponets()
> {=20
> return {std::make_unique<ConcreteComposite1>(), std::make_unique<Concre=
teComposite2>()};
> }
>=20
> auto && list =3D makeComponets();
> However, I believe in this case the standard will guarantee that list is =
no longer dangling.
No, there is no such guarantee and it=E2=80=99s unimplementable for all pra=
ctical intents. Most compilers have already implemented a diagnosis for thi=
s case.
> In situation as above, the standard requires that own_initializer_list<Co=
mponentPtr> will be constructed on call side, as creation of stack array is=
part the construction of own_initializer_list<ComponentPtr>, the array wil=
l be placed on call side.
Can this be reconciled with the Common ABI?
> And the second:
> auto* p =3D new own_initializer_list<ComponentPtr>{std::make_unique<Concr=
eteComposite1>(), std::make_unique<ConcreteComposite2>()};
> The paper still does not qualify if this is safe.
Already covered by the above quote.
> The array may be placed both on stack (dangling), or on the heap with own=
_initializer_list<T> object.
std::initializer_list followed a misguided philosophy of standardization, t=
hat the standard would only state a few minimal behavioral guarantees, to r=
ely on the wisdom of implementers to find the most efficient realization. T=
his led to mass confusion as the C++11 spec was unimplementable. Users tend=
ed to expect that the list would be placed on the heap as by an array-new e=
xpression, if necessary =E2=80=94 and what=E2=80=99s so unreasonable about =
that? So CWG formalized the most common behavior, which is to create a temp=
orary array object and allow lifetime extension. In the process, the one op=
timization to be specifically intended by design, static storage, inadverte=
ntly became nonconforming.
Perhaps the proposal should go into more detail, but I tried to simply ackn=
owledge the status quo by mentioning stack allocation, in the abstract and =
the first sentence of =C2=A72, and mentioning the optimization elsewhere. I=
foresee more questions about this=E2=80=A6 perhaps folks feel that heap al=
location was a possibility that was snatched away.
> Choosing the second resolution and making own_initializer_list non-moveab=
le will eliminate all dangling reference problems occuring in situation whe=
n own_initializer_list<T> is stored by value. Storing it by reference, will=
provide to dangling reference, as for any other class.
My proposal allows you to have a member of own_initializer_list<T>&& refere=
nce type. Such a member reference can become dangling, but a list itself ne=
ver does. This is mentioned in the sentence after the above quote.
My other EWG proposal, =E2=80=9CLifetime extension for accessors and views=
=E2=80=9D (bit.ly/genlife <http://bit.ly/genlife>) seeks to solve or at lea=
st diagnose such dangling reference issues.
--=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=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 3:02 AM, Tomasz <<a href=3D"mailto:tomaszkam@gmail.com" =
class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div dir=3D"ltr" class=3D"">I have a questi=
on regarding the rationale for keeping own_initializer_list<T> movabl=
e. This still may lead to several dangling reference problems, for example =
most common one is to treat own_initializer_list<T> as normal contain=
er and store as class member,</div></div></blockquote><div><br class=3D""><=
/div><div>Declaring a class member of <font face=3D"Courier" class=3D"">own=
_initializer_list</font> type is a diagnosable error. See the last paragrap=
h in =C2=A72:</div><div><br class=3D""></div><div><blockquote type=3D"cite"=
class=3D""><p style=3D"margin: 0px 0px 6px; -webkit-text-stroke-color: rgb=
(0, 0, 0); -webkit-text-stroke-width: initial;" class=3D"">This likewise re=
quires forbidding cases where <span style=3D"font-size: 11px; font-family: =
Courier; background-color: rgb(245, 245, 245);" class=3D"">initializer_list=
</span> generates dangling pointers: when it is used as a member, a base cl=
ass, the value of a <span style=3D"font-size: 11px; font-family: Courier; b=
ackground-color: rgb(245, 245, 245);" class=3D"">return</span> statement, a=
n exception object, or the type in a <i class=3D"">new-expression</i>.</p><=
/blockquote></div></div><div><br class=3D""></div><div>It would be nice if =
this applied to ordinary <font face=3D"Courier" class=3D"">initializer_list=
</font> too, but that ship might have sailed. Anyway, it would be another p=
roposal.</div><div><br class=3D""></div><div>Perhaps it should be more stro=
ngly worded so as not to appear as a contingency: =E2=80=9CIt is forbidden =
to=E2=80=A6=E2=80=9D</div><div><br class=3D""><blockquote type=3D"cite" cla=
ss=3D""><div class=3D""><div dir=3D"ltr" class=3D"">Both situations are non=
-trivial to understand and requires knowledge about internal implementation=
(stack array) and are source of errors in the program. Both of them would =
be fixed by making the own_initializer_list non-copyable and non-moveable. =
</div></div></blockquote><div><br class=3D""></div><div>That would not be s=
ufficient as a fix, because constructing an initializer list object from a =
braced-init-list does not always involve an intermediate temporary that nee=
ds to be moved.</div><br class=3D""><blockquote type=3D"cite" class=3D""><d=
iv class=3D""><div dir=3D"ltr" class=3D"">The cost of the change would be t=
hat you will be no longer able to write:<br class=3D"">auto list =3D {"ala"=
s, "ola"s};<br class=3D"">//Will requires move constructor to intializer fr=
om temporary on left hand side. However the syntax:<br class=3D""></div></d=
iv></blockquote><div><br class=3D""></div><div>No, there is no temporary th=
ere. Copy-list-initialization, unlike other copy-initialization, does not c=
onvert to the type as a temporary and then copy-initialize.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr"=
class=3D"">auto&& list =3D {"ala"s, "ola"s};<br class=3D"">//Will =
still be valid.<br class=3D"">The functions will be required to accept own_=
initializer_list<ComponentPtr>&&, but I do not think that thi=
s is a problem;<br class=3D""><br class=3D"">There is a situation, when the=
non-copyable non-moveable class can still be transfered. One is:<br class=
=3D"">own_initializer_list<ComponentPtr> makeComponets()<br class=3D"=
">{ <br class=3D""> return {std::make_unique<ConcreteComposite1>=
;(), std::make_unique<ConcreteComposite2>()};<br class=3D"">}<br clas=
s=3D""><br class=3D"">auto && list =3D makeComponets();<br class=3D=
"">However, I believe in this case the standard will guarantee that list is=
no longer dangling.</div></div></blockquote><div><br class=3D""></div><div=
>No, there is no such guarantee and it=E2=80=99s unimplementable for all pr=
actical intents. Most compilers have already implemented a diagnosis for th=
is case.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D""><div dir=3D"ltr" class=3D""> In situation as above, the standard req=
uires that own_initializer_list<ComponentPtr> will be constructed on =
call side, as creation of stack array is part the construction of own_initi=
alizer_list<ComponentPtr>, the array will be placed on call side.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Can this=
be reconciled with the Common ABI?</div><br class=3D""><blockquote type=3D=
"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">And the secon=
d:<br class=3D"">auto* p =3D new own_initializer_list<ComponentPtr>{s=
td::make_unique<ConcreteComposite1>(), std::make_unique<ConcreteCo=
mposite2>()};<br class=3D"">The paper still does not qualify if this is =
safe.</div></div></blockquote><div><br class=3D""></div><div>Already covere=
d by the above quote.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""> The array may be placed =
both on stack (dangling), or on the heap with own_initializer_list<T>=
object. </div></div></blockquote><div><br class=3D""></div><div><font face=
=3D"Courier" class=3D"">std::initializer_list</font> followed a misgui=
ded philosophy of standardization, that the standard would only state a few=
minimal behavioral guarantees, to rely on the wisdom of implementers to fi=
nd the most efficient realization. This led to mass confusion as the C++11 =
spec was unimplementable. Users tended to expect that the list would be pla=
ced on the heap as by an array-new expression, if necessary =E2=80=94 and w=
hat=E2=80=99s so unreasonable about that? So CWG formalized the most common=
behavior, which is to create a temporary array object and allow lifetime e=
xtension. In the process, the one optimization to be specifically intended =
by design, static storage, inadvertently became nonconforming.</div><div><b=
r class=3D""></div><div>Perhaps the proposal should go into more detail, bu=
t I tried to simply acknowledge the status quo by mentioning stack allocati=
on, in the abstract and the first sentence of =C2=A72, and mentioning the o=
ptimization elsewhere. I foresee more questions about this=E2=80=A6 perhaps=
folks feel that heap allocation was a possibility that was snatched away.<=
/div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><d=
iv dir=3D"ltr" class=3D"">Choosing the second resolution and making own_ini=
tializer_list non-moveable will eliminate all dangling reference problems o=
ccuring in situation when own_initializer_list<T> is stored by value.=
Storing it by reference, will provide to dangling reference, as for any ot=
her class.<br class=3D""></div></div></blockquote><br class=3D""></div><div=
>My proposal allows you to have a member of <font face=3D"Courier" class=3D=
"">own_initializer_list<T>&&</font> reference type. Such a me=
mber reference can become dangling, but a list itself never does. This is m=
entioned in the sentence after the above quote.</div><br class=3D""><div cl=
ass=3D"">My other EWG proposal, =E2=80=9CLifetime extension for accessors a=
nd views=E2=80=9D (<a href=3D"http://bit.ly/genlife" class=3D"">bit.ly/genl=
ife</a>) seeks to solve or at least diagnose such dangling reference issues=
..</div><div class=3D""><br class=3D""></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" 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=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24--
.
Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 07:41:13 +0200
Raw View
--001a11c1a0e65bd65805203b5442
Content-Type: text/plain; charset=UTF-8
2015-09-21 6:11 GMT+02:00 David Krauss <potswa@gmail.com>:
>
> Both situations are non-trivial to understand and requires knowledge about
> internal implementation (stack array) and are source of errors in the
> program. Both of them would be fixed by making the own_initializer_list
> non-copyable and non-moveable.
>
>
> That would not be sufficient as a fix, because constructing an initializer
> list object from a braced-init-list does not always involve an intermediate
> temporary that needs to be moved.
>
Ok, I agree. Your are pointing that in my example I could use construct as
follows:
struct Composite
{
Composite(own_initializer_list<ComponentPtr>&& a_list) : a_list(m_list) {}
Composite() : a_list{std::make_unique<ConcreteComposite1>(),
std::make_unique<ConcreteComposite2>()}
private:
own_initializer_list<ComponentPtr> m_list;
};
Then Composite c; will lead to dangling reference.
However, I still think that removing the move-constructor would be
beneficial. The existence of the move-constructor and the name
(own_initializer_list) suggest that the list object actually manages
storage and moves it from one object to another. As the
own_initializer_list is effectively wrapped reference to stack allocated
array, it cannot do that, so the current design is misleading.
What is motivation for own_initializer_list being move-able? It's existence
suggest user that the class behaves more like unique_ptr<T[]> than
reference to stack array.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c1a0e65bd65805203b5442
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-09-21 6:11 GMT+02:00 David Krauss <span dir=3D"ltr"><<a href=3D"mai=
lto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:=
break-word"><div><span class=3D""><br><blockquote type=3D"cite"><div><div d=
ir=3D"ltr">Both situations are non-trivial to understand and requires knowl=
edge about internal implementation (stack array) and are source of errors i=
n the program. Both of them would be fixed by making the own_initializer_li=
st non-copyable and non-moveable. </div></div></blockquote><div><br></div><=
/span><div>That would not be sufficient as a fix, because constructing an i=
nitializer list object from a braced-init-list does not always involve an i=
ntermediate temporary that needs to be moved.</div></div></div></blockquote=
><div><br><br>Ok, I agree. Your are pointing that in my example I could use=
construct as follows:<br>struct Composite<br>{<br>=C2=A0 Composite(own_ini=
tializer_list<ComponentPtr>&& a_list) : a_list(m_list) {}<br>=
=C2=A0 Composite() : a_list{std::make_unique<ConcreteComposite1>(), s=
td::make_unique<ConcreteComposite2>()}=C2=A0 <br><br>private:<br>=C2=
=A0 own_initializer_list<ComponentPtr> m_list;<br>};<br>Then Composit=
e c; will lead to dangling reference.<br><br>However, I still think that re=
moving the move-constructor would be beneficial. The existence of the move-=
constructor and the name (own_initializer_list) suggest that the list objec=
t actually manages storage and moves it from one object to another. As the =
own_initializer_list is effectively wrapped reference to stack allocated ar=
ray, it cannot do that, so the current design is misleading.<br><br></div><=
div>What is motivation for own_initializer_list being move-able? It's e=
xistence suggest user that the class behaves more like unique_ptr<T[]>=
; than reference to stack array.<br></div></div></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" 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 />
--001a11c1a0e65bd65805203b5442--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 14:25:51 +0800
Raw View
--Apple-Mail=_36507162-5AD5-431B-BFDF-1350E26C4CC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 1:41 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>=20
> However, I still think that removing the move-constructor would be benefi=
cial. The existence of the move-constructor and the name (own_initializer_l=
ist) suggest that the list object actually manages storage and moves it fro=
m one object to another. As the own_initializer_list is effectively wrapped=
reference to stack allocated array, it cannot do that, so the current desi=
gn is misleading.
Does a std::vector (or, as you mention, unique_ptr<T[]>) =E2=80=9Cmove stor=
age from one object to another=E2=80=9D? Aside from user-replaced ::operato=
r new or watching the stack pointer, and aside from the restricted capabili=
ties of the list, what=E2=80=99s the observable difference between own_init=
ializer_list and unique_ptr<T[]>?
> What is motivation for own_initializer_list being move-able? It's existen=
ce suggest user that the class behaves more like unique_ptr<T[]> than refer=
ence to stack array.
Please see =C2=A74.4 Ownership, from the second paragraph onward.
Note that a moved-from list does not destroy any sequence, even one it was =
directly initialized with.
--=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=_36507162-5AD5-431B-BFDF-1350E26C4CC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 1:41 PM, Tomasz Kami=C5=84ski <<a href=3D"mailto:tomaszk=
am@gmail.com" class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">=
<div class=3D"gmail_extra">However, I still think that removing the move-co=
nstructor would be beneficial. The existence of the move-constructor and th=
e name (own_initializer_list) suggest that the list object actually manages=
storage and moves it from one object to another. As the own_initializer_li=
st is effectively wrapped reference to stack allocated array, it cannot do =
that, so the current design is misleading.</div></div></div></blockquote><d=
iv><br class=3D""></div><div>Does a <font face=3D"Courier" class=3D"">std::=
vector</font> (or, as you mention, <span style=3D"font-family: Co=
urier;" class=3D"">unique_ptr<T[]></span>) =E2=80=9Cmove storage from=
one object to another=E2=80=9D? Aside from user-replaced <font face=3D"Cou=
rier" class=3D"">::operator new</font> or watching the stack pointer, and a=
side from the restricted capabilities of the list, what=E2=80=99s the obser=
vable difference between <font face=3D"Courier" class=3D"">own_initializer_=
list</font> and <font face=3D"Courier" class=3D"">unique_ptr<T[]></fo=
nt>?</div><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><d=
iv class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div class=3D"">What is motivation for own_initializer=
_list being move-able? It's existence suggest user that the class behaves m=
ore like unique_ptr<T[]> than reference to stack array.</div></div></=
div></div></div></blockquote><br class=3D""></div><div>Please see =C2=A74.4=
<i class=3D"">Ownership</i>, from the second paragraph onward.</div><div><=
br class=3D""></div><div>Note that a moved-from list does not destroy any s=
equence, even one it was directly initialized with.</div><div><br class=3D"=
"></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" 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=_36507162-5AD5-431B-BFDF-1350E26C4CC4--
.
Author: =?UTF-8?Q?Tomasz_Kami=C5=84ski?= <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 08:43:37 +0200
Raw View
--047d7b41889b7d8a1405203c3377
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-09-21 8:25 GMT+02:00 David Krauss <potswa@gmail.com>:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 1:41 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>
> However, I still think that removing the move-constructor would be
> beneficial. The existence of the move-constructor and the name
> (own_initializer_list) suggest that the list object actually manages
> storage and moves it from one object to another. As the
> own_initializer_list is effectively wrapped reference to stack allocated
> array, it cannot do that, so the current design is misleading.
>
>
> Does a std::vector (or, as you mention, unique_ptr<T[]>) =E2=80=9Cmove st=
orage
> from one object to another=E2=80=9D? Aside from user-replaced ::operator =
new or
> watching the stack pointer, and aside from the restricted capabilities of
> the list, what=E2=80=99s the observable difference between own_initialize=
r_list
> and unique_ptr<T[]>?
>
>
The following:
std::size_t computeSomething(std::vector<std::string>);
std::function<std::size_t()> lazyEvaluator()
{
Type list =3D {"ala", "ola"};
return std::bind(computeSomething, std::move(list));
}
Works correctly if Type is std::vector<std::string>, but if for Type is
own_initializer_list<std::string> it will cause either:
1. dangling reference
2. unreadable warrning about own_initializer_list member in the some
strange tuple (I belive that is what your proposal dy).
Making own_initializer_list non-movable, will produce error about list
being non-moveable. As own_initializer_list is bassically reference, then
this is true.
--=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/.
--047d7b41889b7d8a1405203c3377
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-09-21 8:25 GMT+02:00 David Krauss <span dir=3D"ltr"><<a href=3D"mai=
lto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:=
break-word"><br><br><div><span class=3D""><blockquote type=3D"cite"><div>On=
2015=E2=80=9309=E2=80=9321, at 1:41 PM, Tomasz Kami=C5=84ski <<a href=
=3D"mailto:tomaszkam@gmail.com" target=3D"_blank">tomaszkam@gmail.com</a>&g=
t; wrote:</div><br><div><div dir=3D"ltr"><div class=3D"gmail_extra">However=
, I still think that removing the move-constructor would be beneficial. The=
existence of the move-constructor and the name (own_initializer_list) sugg=
est that the list object actually manages storage and moves it from one obj=
ect to another. As the own_initializer_list is effectively wrapped referenc=
e to stack allocated array, it cannot do that, so the current design is mis=
leading.</div></div></div></blockquote><div><br></div></span><div>Does a <f=
ont face=3D"Courier">std::vector</font>=C2=A0(or, as you mention,=C2=A0<spa=
n style=3D"font-family:Courier">unique_ptr<T[]></span>) =E2=80=9Cmove=
storage from one object to another=E2=80=9D? Aside from user-replaced <fon=
t face=3D"Courier">::operator new</font> or watching the stack pointer, and=
aside from the restricted capabilities of the list, what=E2=80=99s the obs=
ervable difference between <font face=3D"Courier">own_initializer_list</fon=
t> and <font face=3D"Courier">unique_ptr<T[]></font>?</div><span clas=
s=3D""></span><br></div></div></blockquote><div><br></div><div>The followin=
g:<br></div><div>std::size_t computeSomething(std::vector<std::string>=
;);<br></div><div><br></div><div>std::function<std::size_t()> lazyEva=
luator()<br>{<br></div><div>=C2=A0 =C2=A0Type list =3D {"ala", &q=
uot;ola"};<br></div><div>=C2=A0=C2=A0 return std::bind(computeSomethin=
g, std::move(list));</div><div>} <br></div>Works correctly if Type is std::=
vector<std::string>, but if for Type is own_initializer_list<std::=
string> it will cause either:<br>1. dangling reference<br></div><div cla=
ss=3D"gmail_quote">2. unreadable warrning about own_initializer_list member=
in the some strange tuple (I belive that is what your proposal dy).<br></d=
iv><div class=3D"gmail_quote">Making own_initializer_list non-movable, will=
produce error about list being non-moveable. As own_initializer_list is ba=
ssically reference, then this is true.<br></div></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" 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 />
--047d7b41889b7d8a1405203c3377--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 21 Sep 2015 00:31:22 -0700 (PDT)
Raw View
------=_Part_81_1332031077.1442820683077
Content-Type: multipart/alternative;
boundary="----=_Part_82_1365006545.1442820683077"
------=_Part_82_1365006545.1442820683077
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 06:13:24 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 3:02 AM, Tomasz <toma...@gmail.com <jav=
ascript:>> wrote:
>
> I have a question regarding the rationale for keeping=20
> own_initializer_list<T> movable. This still may lead to several dangling=
=20
> reference problems, for example most common one is to treat=20
> own_initializer_list<T> as normal container and store as class member,
>
>
> Declaring a class member of own_initializer_list type is a diagnosable=20
> error. See the last paragraph in =C2=A72:
>
> This likewise requires forbidding cases where initializer_list generates=
=20
> dangling pointers: when it is used as a member, a base class, the value o=
f=20
> a return statement, an exception object, or the type in a *new-expression=
*
> .
>
>
So, you are preventing the bug-prone constructs by a special language rule=
=20
(yet another special rule to be learned by the programmers). In contrast,=
=20
it appears to me that simply deleting the move constructor of=20
*own_initializer_list* would achieve the same result without adding any=20
special rule. Also, only the presence of move constructor may incorrectly=
=20
suggest to the users that there is a transfer of ownership involved.
So, the question is: is the move constructor necessary in your design?
(BTW, Let me just mention that I really like your proposal; only with it,=
=20
will initializer_list be complete.)
Regards,
&rzej
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_82_1365006545.1442820683077
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 06:13:24 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"ci=
te"><div>On 2015=E2=80=9309=E2=80=9321, at 3:02 AM, Tomasz <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"DORg4JueBQAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">toma...@gmail.com=
</a>> wrote:</div><br><div><div dir=3D"ltr">I have a question regarding =
the rationale for keeping own_initializer_list<T> movable. This still=
may lead to several dangling reference problems, for example most common o=
ne is to treat own_initializer_list<T> as normal container and store =
as class member,</div></div></blockquote><div><br></div><div>Declaring a cl=
ass member of <font face=3D"Courier">own_initializer_list</font> type is a =
diagnosable error. See the last paragraph in =C2=A72:</div><div><br></div><=
div><blockquote type=3D"cite"><p style=3D"margin:0px 0px 6px">This likewise=
requires forbidding cases where <span style=3D"font-size:11px;font-family:=
Courier;background-color:rgb(245,245,245)">initializer_list</span> generate=
s dangling pointers: when it is used as a member, a base class, the value o=
f a <span style=3D"font-size:11px;font-family:Courier;background-color:rgb(=
245,245,245)">return</span> statement, an exception object, or the type in =
a <i>new-expression</i>.</p></blockquote></div></div></div></blockquote><di=
v><br>So, you are preventing the bug-prone constructs by a special language=
rule (yet another special rule to be learned by the programmers). In contr=
ast, it appears to me that simply deleting the move constructor of <b>own_i=
nitializer_list</b> would achieve the same result without adding any specia=
l rule. Also, only the presence of move constructor may incorrectly suggest=
to the users that there is a transfer of ownership involved.<br><br>So, th=
e question is: is the move constructor necessary in your design?<br><br>(BT=
W, Let me just mention that I really like your proposal; only with it, will=
initializer_list be complete.)<br><br>Regards,<br>&rzej<br></div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_82_1365006545.1442820683077--
------=_Part_81_1332031077.1442820683077--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 16:04:43 +0800
Raw View
--Apple-Mail=_611208B1-2622-4AC9-B85C-543B80D49C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 2:43 PM, Tomasz Kami=C5=84ski <tomaszka=
m@gmail.com> wrote:
>=20
> Works correctly if Type is std::vector<std::string>, but if for Type is o=
wn_initializer_list<std::string> it will cause either:
> 1. dangling reference
> 2. unreadable warrning about own_initializer_list member in the some stra=
nge tuple (I belive that is what your proposal dy).
Yes, this. (I mentioned =E2=80=9Crestricted capabilities.=E2=80=9D)
> Making own_initializer_list non-movable, will produce error about list be=
ing non-moveable.
That is, an error inside the constructor of the bind object ("some strange =
tuple=E2=80=9D). What=E2=80=99s the distinction?
What=E2=80=99s more readable? This, which is printed by the prototype imple=
mentation:
error: non-static data member 'xyz' cannot own an initializer list
Or this, from Clang, when bind is given an immovable argument:
error: no matching constructor for initialization of 'xyz'
Or from GCC:
error: use of deleted function =E2=80=98own_initializer_list::own_initializ=
er_list(own_initializer_list&&)=E2=80=99
> As own_initializer_list is bassically reference, then this is true.
own_initializer_list is no more reference-like than initializer_list. Refer=
ences are move-constructible.
--=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=_611208B1-2622-4AC9-B85C-543B80D49C9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 2:43 PM, Tomasz Kami=C5=84ski <<a href=3D"mailto:tomaszk=
am@gmail.com" class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">=
<div class=3D"gmail_extra">Works correctly if Type is std::vector<std::s=
tring>, but if for Type is own_initializer_list<std::string> it wi=
ll cause either:<br class=3D""><div class=3D"gmail_quote">1. dangling refer=
ence<br class=3D""></div><div class=3D"gmail_quote">2. unreadable warrning =
about own_initializer_list member in the some strange tuple (I belive that =
is what your proposal dy).<br class=3D""></div></div></div></div></blockquo=
te><div><br class=3D""></div><div>Yes, this. (I mentioned =E2=80=9Crestrict=
ed capabilities.=E2=80=9D)</div><br class=3D""><blockquote type=3D"cite" cl=
ass=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">Making own_initializer_list non-movable, wi=
ll produce error about list being non-moveable.</div></div></div></div></bl=
ockquote><div><br class=3D""></div><div>That is, an error inside the constr=
uctor of the bind object ("some strange tuple=E2=80=9D). What=E2=80=99s the=
distinction?</div><div><br class=3D""></div><div>What=E2=80=99s more reada=
ble? This, which is printed by the prototype implementation:</div><div><br =
class=3D""></div><div><font face=3D"Courier" class=3D"">error: non-static d=
ata member 'xyz' cannot own an initializer list</font></div><div><br c=
lass=3D""></div><div>Or this, from Clang, when <font face=3D"Courier" class=
=3D"">bind</font> is given an immovable argument:</div><div><br class=3D"">=
</div><div><font face=3D"Courier" class=3D"">error: no matching constructor=
for initialization of 'xyz'</font></div><div><br class=3D""></div>Or =
from GCC:</div><div><br class=3D""></div><div><font face=3D"Courier" class=
=3D"">error: use of deleted function =E2=80=98own_initializer_list::ow=
n_initializer_list(own_initializer_list&&)=E2=80=99</font></div><di=
v><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"> As own_initializer_list is bassically reference, then this is true.<br c=
lass=3D""></div></div></div></div></blockquote><br class=3D""></div><div><f=
ont face=3D"Courier" class=3D"">own_initializer_list</font> is no more refe=
rence-like than <font face=3D"Courier" class=3D"">initializer_list</font>. =
References <i class=3D"">are</i> move-constructible.</div><div><br cla=
ss=3D""></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" 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=_611208B1-2622-4AC9-B85C-543B80D49C9E--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 16:18:52 +0800
Raw View
--Apple-Mail=_A14EDC17-3676-4756-B221-0C3A99D5CF6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 3:31 PM, Andrzej Krzemie=C5=84ski <akrz=
emi1@gmail.com> wrote:
>=20
> So, you are preventing the bug-prone constructs by a special language rul=
e (yet another special rule to be learned by the programmers).
The rule is already there, for the initializer_list we have. I=E2=80=99m ju=
st making it official and with more eager diagnosis.
There are a lot of questions on StackOverflow asking why initializer_list c=
an=E2=80=99t be used as a container. The standard currently requires risky =
usage to be well-formed. Some cases do elicit dangling reference warnings, =
but otherwise implementations tend not to bother with diagnosis. After all,=
you could be ensuring that the class is always destroyed in time, or that =
the dangling reference is never used. Or, perhaps more significantly, the i=
mplementers just never got around to it.
=E2=80=9CDon=E2=80=99t treat [own_]initializer_list as a container=E2=80=9D=
is not IMHO a matter of memorization. In the rare instances it comes up, w=
e just want to maximize the chances of immediate, specific diagnosis, to mi=
nimize the research and brainwork demanded of the programmer.
> In contrast, it appears to me that simply deleting the move constructor o=
f own_initializer_list would achieve the same result without adding any spe=
cial rule. Also, only the presence of move constructor may incorrectly sugg=
est to the users that there is a transfer of ownership involved.
There is a genuine transfer of ownership involved.
> So, the question is: is the move constructor necessary in your design?
Please see =C2=A74.4 of the proposal.
Is that section unclear?
--=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=_A14EDC17-3676-4756-B221-0C3A99D5CF6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 3:31 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailto:akr=
zemi1@gmail.com" class=3D"">akrzemi1@gmail.com</a>> wrote:</div><div cla=
ss=3D""><br class=3D"">So, you are preventing the bug-prone constructs by a=
special language rule (yet another special rule to be learned by the progr=
ammers).</div></blockquote><div><br class=3D""></div><div>The rule is alrea=
dy there, for the <font face=3D"Courier" class=3D"">initializer_list</font>=
we have. I=E2=80=99m just making it official and with more eager diagnosis=
..</div><div><br class=3D""></div><div>There are a lot of questions on Stack=
Overflow asking why <font face=3D"Courier" class=3D"">initializer_list</fon=
t> can=E2=80=99t be used as a container. The standard currently requires ri=
sky usage to be well-formed. Some cases do elicit dangling reference warnin=
gs, but otherwise implementations tend not to bother with diagnosis. After =
all, you <i class=3D"">could</i> be ensuring that the class is always =
destroyed in time, or that the dangling reference is never used. Or, perhap=
s more significantly, the implementers just never got around to it.</div><d=
iv><br class=3D""></div><div>=E2=80=9CDon=E2=80=99t treat <font face=3D"Cou=
rier" class=3D"">[own_]initializer_list</font> as a container=E2=80=9D is n=
ot IMHO a matter of memorization. In the rare instances it comes up, we jus=
t want to maximize the chances of immediate, specific diagnosis, to minimiz=
e the research and brainwork demanded of the programmer.</div><br class=3D"=
"><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"">In c=
ontrast, it appears to me that simply deleting the move constructor of <b c=
lass=3D"">own_initializer_list</b> would achieve the same result without ad=
ding any special rule. Also, only the presence of move constructor may inco=
rrectly suggest to the users that there is a transfer of ownership involved=
..<br class=3D""></div></div></blockquote><div><br class=3D""></div><div>The=
re is a genuine transfer of ownership involved.</div><br class=3D""><blockq=
uote type=3D"cite" class=3D""><div class=3D""><div class=3D"">So, the quest=
ion is: is the move constructor necessary in your design?<br class=3D""></d=
iv></div></blockquote></div><br class=3D""><div class=3D"">Please see =C2=
=A74.4 of the proposal.</div><div class=3D""><br class=3D""></div><div clas=
s=3D"">Is that section unclear?</div><div class=3D""><br class=3D""></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" 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=_A14EDC17-3676-4756-B221-0C3A99D5CF6F--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 01:54:22 -0700 (PDT)
Raw View
------=_Part_190_161237102.1442825662485
Content-Type: multipart/alternative;
boundary="----=_Part_191_2146791699.1442825662485"
------=_Part_191_2146791699.1442825662485
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 10:18:59 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 3:31 PM, Andrzej Krzemie=C5=84ski <akrz=
....@gmail.com=20
> <javascript:>> wrote:
>
> So, you are preventing the bug-prone constructs by a special language rul=
e=20
> (yet another special rule to be learned by the programmers).
>
>
> The rule is already there, for the initializer_list we have. I=E2=80=99m =
just=20
> making it official and with more eager diagnosis.
>
=20
>
> There are a lot of questions on StackOverflow asking why initializer_list=
=20
> can=E2=80=99t be used as a container. The standard currently requires ris=
ky usage=20
> to be well-formed. Some cases do elicit dangling reference warnings, but=
=20
> otherwise implementations tend not to bother with diagnosis. After all, y=
ou=20
> *could* be ensuring that the class is always destroyed in time, or that=
=20
> the dangling reference is never used. Or, perhaps more significantly, the=
=20
> implementers just never got around to it.
>
> =20
And we can avoid repeating the same design that lead to the above desing=20
for the newly introduced classes. If I check the class interface and you=20
will found that it is move constructible, I would expect that I will be=20
able to pass it to function by value (ok) and return it from the function,=
=20
also by value (eliminated in your design for valid reasons). The design=20
that provide move constructor, but then prohibits usuall use of such will=
=20
lead to more confusion.
Also having non-moveable class does not prevent you from tieing the=20
descturion of the elements of the list to destruction of=20
own_initializer_list, as proposed in your paper.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_191_2146791699.1442825662485
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 10=
:18:59 UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div><bloc=
kquote type=3D"cite"><div>On 2015=E2=80=9309=E2=80=9321, at 3:31 PM, Andrze=
j Krzemie=C5=84ski <<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"CjsasAKsBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">akrz...@gmail.com</a>> wrote:</div><div><br>So, you ar=
e preventing the bug-prone constructs by a special language rule (yet anoth=
er special rule to be learned by the programmers).</div></blockquote><div><=
br></div><div>The rule is already there, for the <font face=3D"Courier">ini=
tializer_list</font> we have. I=E2=80=99m just making it official and with =
more eager diagnosis.</div></div></div></blockquote><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<div><div><br></div><div>There are a lot of questions on StackOverflow aski=
ng why <font face=3D"Courier">initializer_list</font> can=E2=80=99t be used=
as a container. The standard currently requires risky usage to be well-for=
med. Some cases do elicit dangling reference warnings, but otherwise implem=
entations tend not to bother with diagnosis. After all, you <i>could</i>=C2=
=A0be ensuring that the class is always destroyed in time, or that the dang=
ling reference is never used. Or, perhaps more significantly, the implement=
ers just never got around to it.</div><br></div></div></blockquote><div>=C2=
=A0<br>And we can avoid repeating the same design that lead to the above de=
sing for the newly introduced classes. If I check the class interface and y=
ou will found that it is move constructible, I would expect that I will be =
able to pass it to function by value (ok) and return it from the function, =
also by value (eliminated in your design for valid reasons). The design tha=
t provide move constructor, but then prohibits usuall use of such will lead=
to more confusion.<br><br>Also having non-moveable class does not prevent =
you from tieing the descturion of the elements of the list to destruction o=
f own_initializer_list, as proposed in your paper.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_191_2146791699.1442825662485--
------=_Part_190_161237102.1442825662485--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 21 Sep 2015 01:56:55 -0700 (PDT)
Raw View
------=_Part_4279_124114770.1442825815434
Content-Type: multipart/alternative;
boundary="----=_Part_4280_717692894.1442825815434"
------=_Part_4280_717692894.1442825815434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 10:18:59 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 3:31 PM, Andrzej Krzemie=C5=84ski <akrz=
....@gmail.com=20
> <javascript:>> wrote:
>
> So, you are preventing the bug-prone constructs by a special language rul=
e=20
> (yet another special rule to be learned by the programmers).
>
>
> The rule is already there, for the initializer_list we have. I=E2=80=99m =
just=20
> making it official and with more eager diagnosis.
>
> There are a lot of questions on StackOverflow asking why initializer_list=
=20
> can=E2=80=99t be used as a container. The standard currently requires ris=
ky usage=20
> to be well-formed. Some cases do elicit dangling reference warnings, but=
=20
> otherwise implementations tend not to bother with diagnosis. After all, y=
ou=20
> *could* be ensuring that the class is always destroyed in time, or that=
=20
> the dangling reference is never used. Or, perhaps more significantly, the=
=20
> implementers just never got around to it.
>
> =E2=80=9CDon=E2=80=99t treat [own_]initializer_list as a container=E2=80=
=9D is not IMHO a matter=20
> of memorization. In the rare instances it comes up, we just want to=20
> maximize the chances of immediate, specific diagnosis, to minimize the=20
> research and brainwork demanded of the programmer.
>
Indeed, increasing the chances of immediate clear diagnostics is a goal=20
worth pursuing. I just claim (although I might be missing something) there=
=20
is more than one way of achieving this goal, and that the other one might=
=20
be superior.=20
> In contrast, it appears to me that simply deleting the move constructor o=
f=20
> *own_initializer_list* would achieve the same result without adding any=
=20
> special rule. Also, only the presence of move constructor may incorrectly=
=20
> suggest to the users that there is a transfer of ownership involved.
>
>
> There is a genuine transfer of ownership involved.
>
> So, the question is: is the move constructor necessary in your design?
>
>
> Please see =C2=A74.4 of the proposal.
>
> Is that section unclear?
>
I may be reading this incorrectly, but my understanding of the proposal is=
=20
that it allows moving individual elements (into the special storage, or=20
later by the users wherever they want to move them), but at no point does=
=20
the user have any business moving the *own_initializer_list* object around.=
=20
Did I get the proposal wrong?
Regards,
&rzej
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_4280_717692894.1442825815434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 10:18:59 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"ci=
te"><div>On 2015=E2=80=9309=E2=80=9321, at 3:31 PM, Andrzej Krzemie=C5=84sk=
i <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Cj=
sasAKsBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>akrz...@gmail.com</a>> wrote:</div><div><br>So, you are preventing the =
bug-prone constructs by a special language rule (yet another special rule t=
o be learned by the programmers).</div></blockquote><div><br></div><div>The=
rule is already there, for the <font face=3D"Courier">initializer_list</fo=
nt> we have. I=E2=80=99m just making it official and with more eager diagno=
sis.</div><div><br></div><div>There are a lot of questions on StackOverflow=
asking why <font face=3D"Courier">initializer_list</font> can=E2=80=99t be=
used as a container. The standard currently requires risky usage to be wel=
l-formed. Some cases do elicit dangling reference warnings, but otherwise i=
mplementations tend not to bother with diagnosis. After all, you <i>could</=
i>=C2=A0be ensuring that the class is always destroyed in time, or that the=
dangling reference is never used. Or, perhaps more significantly, the impl=
ementers just never got around to it.</div><div><br></div><div>=E2=80=9CDon=
=E2=80=99t treat <font face=3D"Courier">[own_]initializer_list</font> as a =
container=E2=80=9D is not IMHO a matter of memorization. In the rare instan=
ces it comes up, we just want to maximize the chances of immediate, specifi=
c diagnosis, to minimize the research and brainwork demanded of the program=
mer.</div></div></div></blockquote><div><br>Indeed, increasing the chances =
of immediate clear diagnostics is a goal worth pursuing. I just claim (alth=
ough I might be missing something) there is more than one way of achieving =
this goal, and that the other one might be superior. <br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><d=
iv><br><blockquote type=3D"cite"><div><div>In contrast, it appears to me th=
at simply deleting the move constructor of <b>own_initializer_list</b> woul=
d achieve the same result without adding any special rule. Also, only the p=
resence of move constructor may incorrectly suggest to the users that there=
is a transfer of ownership involved.<br></div></div></blockquote><div><br>=
</div><div>There is a genuine transfer of ownership involved.</div><br><blo=
ckquote type=3D"cite"><div><div>So, the question is: is the move constructo=
r necessary in your design?<br></div></div></blockquote></div><br><div>Plea=
se see =C2=A74.4 of the proposal.</div><div><br></div><div>Is that section =
unclear?</div></div></blockquote><div><br>I may be reading this incorrectly=
, but my understanding of the proposal is that it allows moving individual =
elements (into the special storage, or later by the users wherever they wan=
t to move them), but at no point does the user have any business moving the=
<b>own_initializer_list</b> object around. Did I get the proposal wrong?<b=
r><br>Regards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_4280_717692894.1442825815434--
------=_Part_4279_124114770.1442825815434--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 17:26:49 +0800
Raw View
--Apple-Mail=_B59B63BC-07F2-464C-A36E-E121F8591FB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 4:54 PM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> And we can avoid repeating the same design that lead to the above desing =
for the newly introduced classes. If I check the class interface and you wi=
ll found that it is move constructible, I would expect that I will be able =
to pass it to function by value (ok) and return it from the function, also =
by value (eliminated in your design for valid reasons). The design that pro=
vide move constructor, but then prohibits usuall use of such will lead to m=
ore confusion.
On the other hand, if I require a diagnosis for own_initializer_list, then =
the implementation can simultaneously apply it to the classic initializer_l=
ist as well (give or take status level as an error or warning). No addition=
al elements of confusion are added, and all the existing confusion is addre=
ssed.
> Also having non-moveable class does not prevent you from tieing the desct=
urion of the elements of the list to destruction of own_initializer_list, a=
s proposed in your paper.
It renders the distinction meaningless. The paper =C2=A74.4 lists reasons f=
or earlier destruction =E2=80=94 did you read it?
--=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=_B59B63BC-07F2-464C-A36E-E121F8591FB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 4:54 PM, Tomasz <<a href=3D"mailto:tomaszkam@gmail.com" =
class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div dir=3D"ltr" class=3D"">And we can avoi=
d repeating the same design that lead to the above desing for the newly int=
roduced classes. If I check the class interface and you will found that it =
is move constructible, I would expect that I will be able to pass it to fun=
ction by value (ok) and return it from the function, also by value (elimina=
ted in your design for valid reasons). The design that provide move constru=
ctor, but then prohibits usuall use of such will lead to more confusion.<br=
class=3D""></div></div></blockquote><div><br class=3D""></div><div>On the =
other hand, if I require a diagnosis for <font face=3D"Courier" class=3D"">=
own_initializer_list</font>, then the implementation can simultaneously app=
ly it to the classic <font face=3D"Courier" class=3D"">initializer_list</fo=
nt> as well (give or take status level as an error or warning). No addition=
al elements of confusion are added, and all the existing confusion is addre=
ssed.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Also having non-moveable =
class does not prevent you from tieing the descturion of the elements of th=
e list to destruction of own_initializer_list, as proposed in your paper.<b=
r class=3D""></div></div></div></blockquote><br class=3D""></div><div>It re=
nders the distinction meaningless. The paper =C2=A74.4 lists reasons for ea=
rlier destruction =E2=80=94 did you read it?</div><br class=3D""></body></h=
tml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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=_B59B63BC-07F2-464C-A36E-E121F8591FB6--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 21 Sep 2015 17:41:40 +0800
Raw View
--Apple-Mail=_D92C7CFA-51A6-4335-9A83-82015D15E5AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9321, at 4:56 PM, Andrzej Krzemie=C5=84ski <akrz=
emi1@gmail.com> wrote:
>=20
> I may be reading this incorrectly, but my understanding of the proposal i=
s that it allows moving individual elements (into the special storage, or l=
ater by the users wherever they want to move them), but at no point does th=
e user have any business moving the own_initializer_list object around. Did=
I get the proposal wrong?
Moving the own_initializer_list object is the typical usage. Containers are=
required to leave it in the moved-from state, which can only be accomplish=
ed by the move constructor. From the paper=E2=80=99s examples:
auto ls =3D { std::string( "hello" ) }; // ls has type std::own_initializer=
_list< std::string >.
std::vector< std::string > vsm =3D std::move( ls ); // OK: move from sequen=
ce.
assert ( ls.size() =3D=3D 0 ); // Moved-from sequence no longer exists.
I appreciate any feedback toward clarifications, so the paper can effective=
ly express itself.
Also, if you have an account on StackOverflow (and if not, why not get one?=
) you can reach me without generating email list traffic, at the ISO review=
chatroom: chat.stackoverflow.com/rooms/88055 <http://chat.stackoverflow.co=
m/rooms/88055>. It=E2=80=99s an open forum if others want to use it for the=
ir own proposals, too.
--=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=_D92C7CFA-51A6-4335-9A83-82015D15E5AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9321, at 4:56 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailto:akr=
zemi1@gmail.com" class=3D"">akrzemi1@gmail.com</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D"">I may be reading this incor=
rectly, but my understanding of the proposal is that it allows moving indiv=
idual elements (into the special storage, or later by the users wherever th=
ey want to move them), but at no point does the user have any business movi=
ng the <b class=3D"">own_initializer_list</b> object around. Did =
I get the proposal wrong?</div></blockquote><div><br class=3D""></div><div>=
Moving the <font face=3D"Courier" class=3D"">own_initializer_list</font> ob=
ject is the typical usage. Containers are required to leave it in the moved=
-from state, which can only be accomplished by the move constructor. From t=
he paper=E2=80=99s examples:</div><div><br class=3D""></div><font face=3D"C=
ourier" class=3D"">auto ls =3D { std::string( "hello" ) }; // ls =
has type std::own_initializer_list< std::string >.<br class=3D""=
></font><span style=3D"font-family: Courier;" class=3D"">std::vector< st=
d::string > vsm =3D std::move( ls ); // </span><span style=3D"=
font-family: Courier;" class=3D"">OK: move from sequence.</span><font face=
=3D"Courier" class=3D""><br class=3D""></font><div><font face=3D"Courier" c=
lass=3D"">assert ( ls.size() =3D=3D 0 ); // Moved-from sequence n=
o longer exists.<br class=3D""></font></div><div><br class=3D""></div><div>=
I appreciate any feedback toward clarifications, so the paper can effective=
ly express itself.</div><div><br class=3D""></div><div>Also, if you have an=
account on StackOverflow (and if not, why not get one?) you can reach me w=
ithout generating email list traffic, at the ISO review chatroom: <a h=
ref=3D"http://chat.stackoverflow.com/rooms/88055" class=3D"">chat.stackover=
flow.com/rooms/88055</a>. It=E2=80=99s an open forum if others want to use =
it for their own proposals, too.</div><div><br class=3D""></div></div></bod=
y></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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=_D92C7CFA-51A6-4335-9A83-82015D15E5AF--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 21 Sep 2015 03:36:49 -0700 (PDT)
Raw View
------=_Part_1121_2132290139.1442831809570
Content-Type: multipart/alternative;
boundary="----=_Part_1122_1764586922.1442831809570"
------=_Part_1122_1764586922.1442831809570
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:41:44 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 4:56 PM, Andrzej Krzemie=C5=84ski <akrz=
....@gmail.com=20
> <javascript:>> wrote:
>
> I may be reading this incorrectly, but my understanding of the proposal i=
s=20
> that it allows moving individual elements (into the special storage, or=
=20
> later by the users wherever they want to move them), but at no point does=
=20
> the user have any business moving the *own_initializer_list* object=20
> around. Did I get the proposal wrong?
>
>
> Moving the own_initializer_list object is the typical usage. Containers=
=20
> are required to leave it in the moved-from state, which can only be=20
> accomplished by the move constructor. From the paper=E2=80=99s examples:
>
> auto ls =3D { std::string( "hello" ) }; // ls has=20
> type std::own_initializer_list< std::string >.
> std::vector< std::string > vsm =3D std::move( ls ); // OK: move from=20
> sequence.
> assert ( ls.size() =3D=3D 0 ); // Moved-from sequence no longer exists.
>
> I appreciate any feedback toward clarifications, so the paper can=20
> effectively express itself.
>
> Also, if you have an account on StackOverflow (and if not, why not get=20
> one?) you can reach me without generating email list traffic, at the ISO=
=20
> review chatroom: chat.stackoverflow.com/rooms/88055. It=E2=80=99s an open=
forum=20
> if others want to use it for their own proposals, too.
>
Oh, cool. I will do that.=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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1122_1764586922.1442831809570
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:41:44 UTC+2 u=C5=
=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"ci=
te"><div>On 2015=E2=80=9309=E2=80=9321, at 4:56 PM, Andrzej Krzemie=C5=84sk=
i <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"V0=
DT2IawBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>akrz...@gmail.com</a>> wrote:</div><br><div>I may be reading this incor=
rectly, but my understanding of the proposal is that it allows moving indiv=
idual elements (into the special storage, or later by the users wherever th=
ey want to move them), but at no point does the user have any business movi=
ng the=C2=A0<b>own_initializer_list</b>=C2=A0<wbr>object around. Did I get =
the proposal wrong?</div></blockquote><div><br></div><div>Moving the <font =
face=3D"Courier">own_initializer_list</font> object is the typical usage. C=
ontainers are required to leave it in the moved-from state, which can only =
be accomplished by the move constructor. From the paper=E2=80=99s examples:=
</div><div><br></div><font face=3D"Courier">auto ls =3D { std::string( &quo=
t;hello" ) };=C2=A0// ls=C2=A0has type=C2=A0std::own_initializer_<wbr>=
list< std::string >.<br></font><span style=3D"font-family:Courier">st=
d::vector< std::string > vsm =3D std::move( ls );=C2=A0//=C2=A0</span=
><span style=3D"font-family:Courier">OK: move from sequence.</span><font fa=
ce=3D"Courier"><br></font><div><font face=3D"Courier">assert ( ls.size() =
=3D=3D 0 );=C2=A0//=C2=A0Moved-from sequence no longer exists.<br></font></=
div><div><br></div><div>I appreciate any feedback toward clarifications, so=
the paper can effectively express itself.</div><div><br></div><div>Also, i=
f you have an account on StackOverflow (and if not, why not get one?) you c=
an reach me without generating email list traffic, at the ISO review chatro=
om:=C2=A0<a href=3D"http://chat.stackoverflow.com/rooms/88055" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fchat.stackoverflow.com%2Frooms%2F88055\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNFi1ye_6jgnspgi13VEh5EV2Smjkg';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fchat.stac=
koverflow.com%2Frooms%2F88055\46sa\75D\46sntz\0751\46usg\75AFQjCNFi1ye_6jgn=
spgi13VEh5EV2Smjkg';return true;">chat.stackoverflow.<wbr>com/rooms/880=
55</a>. It=E2=80=99s an open forum if others want to use it for their own p=
roposals, too.</div></div></div></blockquote><div><br>Oh, cool. I will do t=
hat. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_1122_1764586922.1442831809570--
------=_Part_1121_2132290139.1442831809570--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 10:30:19 -0700 (PDT)
Raw View
------=_Part_5122_1035719761.1442856619592
Content-Type: multipart/alternative;
boundary="----=_Part_5123_941481159.1442856619592"
------=_Part_5123_941481159.1442856619592
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:41:44 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
> Also, if you have an account on StackOverflow (and if not, why not get=20
> one?) you can reach me without generating email list traffic, at the ISO=
=20
> review chatroom: chat.stackoverflow.com/rooms/88055. It=E2=80=99s an open=
forum=20
> if others want to use it for their own proposals, too.
>
> I am unable to post on the room and I do not have enough rank on the stac=
k=20
overflow, so I still post here.
From the second reading of the paper, in the summary of=20
own_initializer_list class:
template< typename T >
struct own_initializer_list : initializer_list< T >=20
{
typedef T & reference;
typedef T * iterator;
using initializer_list< T >::begin;
constexpr iterator begin() noexcept;
using initializer_list< T >::end;
constexpr iterator end() noexcept;
constexpr own_initializer_list() noexcept;
own_initializer_list( own_initializer_list const & ) =3D delete;
constexpr own_initializer_list( own_initializer_list && )=20
noexcept; // Post: size() =3D=3D 0.
~initializer_list();
};
Firstly, there is type in the destructor, it should say=20
~own_initializer_list. Secondly the iterator typedef hides the declarations=
=20
of the iterator for the initializer_list class, which are still used for=20
the as the return for const begin overload inherited from initializer_list.=
=20
I think it would be a lot cleaner if const_iterator typedef would be=20
provided and the const overload would be written explicitly in overview:
constexpr const_iterator begin() const noexcept; //equivalent to:=20
initializer_list< T >::begin();
Futhermore in the paper, I didn't found any information if the conversion=
=20
from own_initializer_list<own_initializer_list<T>> to=20
initializer_list<initializer_list<T>> is quaranteed, It would be important=
=20
in for following code:
template<typename T>
struct 2dmatrix
{
2dmatrix(initializer_list<initializer_list<T>>);
//This constructor is provide better performance when compared to=20
initializer_list<vector<T>> as the later will introduce vector temporaries,=
=20
that will be later copied.
//This is true also for own_initializer_list if container of node base=20
containers would be used as storage (std::vector<std::set<T>>).
private:
std::vector<std::vector<T>> storage.
Is own_initializer_list<T> is considered to be member of=20
own_initializer_list<own_initializer_list<T>> (disallowed) or this is=20
considered as special case? Using=20
own_initializer_list<own_initializer_list<T>> as parameter may provide=20
better performance than own_initializer_list<container<T>>, if the=20
container is node-based container (allocating sentinel node).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5123_941481159.1442856619592
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:41:44 UTC+2 u=C5=BCy=
tkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><div><div></div><div></div><div>A=
lso, if you have an account on StackOverflow (and if not, why not get one?)=
you can reach me without generating email list traffic, at the ISO review =
chatroom:=C2=A0<a href=3D"http://chat.stackoverflow.com/rooms/88055" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fchat.stackoverflow.com%2Frooms%2F88055\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFi1ye_6jgnspgi13VEh5EV2Smjkg';return true;"=
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcha=
t.stackoverflow.com%2Frooms%2F88055\46sa\75D\46sntz\0751\46usg\75AFQjCNFi1y=
e_6jgnspgi13VEh5EV2Smjkg';return true;">chat.stackoverflow.<wbr>com/roo=
ms/88055</a>. It=E2=80=99s an open forum if others want to use it for their=
own proposals, too.</div><div><br></div></div></div></blockquote><div>I am=
unable to post on the room and I do not have enough rank on the stack over=
flow, so I still post here.<br><br>From the second reading of the paper, in=
the summary of own_initializer_list class:<br>template< typename T >=
<br>struct own_initializer_list : initializer_list< T > <br>{<br>=C2=
=A0=C2=A0 typedef T & reference;<br>=C2=A0=C2=A0 typedef T * iterator;<=
br><br>=C2=A0=C2=A0 using initializer_list< T >::begin;<br>=C2=A0=C2=
=A0 constexpr iterator begin() noexcept;<br>=C2=A0=C2=A0 using initializer_=
list< T >::end;<br>=C2=A0=C2=A0 constexpr iterator end() noexcept;<br=
><br>=C2=A0=C2=A0 constexpr own_initializer_list() noexcept;<br>=C2=A0=C2=
=A0 own_initializer_list( own_initializer_list const & ) =3D delete;<br=
>=C2=A0=C2=A0 constexpr own_initializer_list( own_initializer_list &&am=
p; ) noexcept;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Post: size() =
=3D=3D 0.<br>=C2=A0=C2=A0 ~initializer_list();<br>};<br>Firstly, there is t=
ype in the destructor, it should say ~own_initializer_list. Secondly the it=
erator typedef hides the declarations of the iterator for the initializer_l=
ist class, which are still used for the as the return for const begin overl=
oad inherited from initializer_list. I think it would be a lot cleaner if c=
onst_iterator typedef would be provided and the const overload would be wri=
tten explicitly in overview:<br>constexpr const_iterator begin() const noex=
cept; //equivalent to: initializer_list< T >::begin();<br><br>Futherm=
ore in the paper, I didn't found any information if the conversion from=
own_initializer_list<own_initializer_list<T>> to initializer_l=
ist<initializer_list<T>> is quaranteed, It would be important i=
n for following code:<br>template<typename T><br>struct 2dmatrix<br>{=
<br>=C2=A0 2dmatrix(initializer_list<initializer_list<T>>);<br>=
=C2=A0 //This constructor is provide better performance when compared to in=
itializer_list<vector<T>> as the later will introduce vector te=
mporaries, that will be later copied.<br>=C2=A0 //This is true also for own=
_initializer_list if container of node base containers would be used as sto=
rage (std::vector<std::set<T>>).<br><br>private:<br>=C2=A0 std:=
:vector<std::vector<T>> storage.<br>Is own_initializer_list<=
T> is considered to be member of own_initializer_list<own_initializer=
_list<T>> (disallowed) or this is considered as special case? Usin=
g own_initializer_list<own_initializer_list<T>> as parameter ma=
y provide better performance than own_initializer_list<container<T>=
;>, if the container is node-based container (allocating sentinel node).=
<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_5123_941481159.1442856619592--
------=_Part_5122_1035719761.1442856619592--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 12:03:18 -0700 (PDT)
Raw View
------=_Part_755_199973864.1442862198883
Content-Type: multipart/alternative;
boundary="----=_Part_756_1167183467.1442862198884"
------=_Part_756_1167183467.1442862198884
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:26:56 UTC+2 u=C5=BCytkow=
nik David=20
Krauss napisa=C5=82:
>
>
> On 2015=E2=80=9309=E2=80=9321, at 4:54 PM, Tomasz <toma...@gmail.com <jav=
ascript:>> wrote:
>
> And we can avoid repeating the same design that lead to the above desing=
=20
> for the newly introduced classes. If I check the class interface and you=
=20
> will found that it is move constructible, I would expect that I will be=
=20
> able to pass it to function by value (ok) and return it from the function=
,=20
> also by value (eliminated in your design for valid reasons). The design=
=20
> that provide move constructor, but then prohibits usuall use of such will=
=20
> lead to more confusion.
>
>
> On the other hand, if I require a diagnosis for own_initializer_list,=20
> then the implementation can simultaneously apply it to the classic=20
> initializer_list as well (give or take status level as an error or=20
> warning). No additional elements of confusion are added, and all the=20
> existing confusion is addressed.
>
> To be clear, now I understand that your paper differentiates between=20
management and ownership of:
1. Lifetime of elements in their sequence. This is bound and actually=20
managed by the own_initializer_list object. Means that the ownership is=20
passed in move constructor and destruction of the object owning the list=20
destroys the list.
2. Lifetime of the stack allocated storage for the array. It may outlive=20
the own_initializer_list object, but the rules that prohibit various use=20
cases of this class is designed to quarantee that the own_initializer_list=
=20
object will never outlive the storage (in constrast to initializer_list).
This is a novum from the standard library perspective. Even for related=20
optional, the lifetime of storage is bound to the lifetime of object,=20
stored element may be destroyed earlier. The nearest equivalent in hand=20
written code would be:
template<typename T>
struct inplace_object_handler
{
explicit inplace_object_handler(void* a_ptr)
: ptr(reinterpret_cast<T*>(a_ptr))
{ new(ptr) T() };
~inplace_object_handler() { ptr->~T(); }
T* operator->() const { return ptr; }
private:
T* ptr;
};
alignas(double) char buffor[sizeof(double)];
{
inplace_object_handler<double> obj(buffer);
};
However, I would make such class non-copyable and move-able to prevent=20
transfer of ownership (even if I can safely move it to nested scopes). I=20
know that this does not prevent all situations when such class could be=20
constructed, but eliminates most of them. So my first expectation was that=
=20
own_initializer_list will also follow this design. This does not eliminate=
=20
possibility of construct leading to dangling reference, so special rules=20
that makes them ill-formed would still be necessary, but exposition of this=
=20
errors will be reduced.
Furthermore, your paper also discuss possibility of introducing the=20
sequence_literal const& as alternative for the initializer_list and=20
deprecating old feature. In that case we cannot argument the confusing=20
behavior by pointing to current design initializer_list - if we provide=20
true replacement, then there will be no need to use initializer_list in new=
=20
syntax.
Have you considered eliminating ability to declare own_initializer_list=20
object by the programmer. And force use of auto&& list =3D { "ala"s, "ola"s=
}=20
even of first declaration? Or dropping the initializer_list deduction for=
=20
auto entirely? According to=20
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html, the=20
total elimination of special auto deduction also received strong support=20
(but with opposition when compared to current resolution).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_756_1167183467.1442862198884
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:26:56 UTC+2 u=C5=BCytkow=
nik David Krauss napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div style=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div=
>On 2015=E2=80=9309=E2=80=9321, at 4:54 PM, Tomasz <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"nRDK4bevBQAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">toma...@gmail.com</a>&g=
t; wrote:</div><br><div><div dir=3D"ltr">And we can avoid repeating the sam=
e design that lead to the above desing for the newly introduced classes. If=
I check the class interface and you will found that it is move constructib=
le, I would expect that I will be able to pass it to function by value (ok)=
and return it from the function, also by value (eliminated in your design =
for valid reasons). The design that provide move constructor, but then proh=
ibits usuall use of such will lead to more confusion.<br></div></div></bloc=
kquote><div><br></div><div>On the other hand, if I require a diagnosis for =
<font face=3D"Courier">own_initializer_list</font>, then the implementation=
can simultaneously apply it to the classic <font face=3D"Courier">initiali=
zer_list</font> as well (give or take status level as an error or warning).=
No additional elements of confusion are added, and all the existing confus=
ion is addressed.</div><br></div></div></blockquote><div>To be clear, now I=
understand that your paper differentiates between management and ownership=
of:<br>1. Lifetime of elements in their sequence. This is bound and actual=
ly managed by the own_initializer_list object. Means that the ownership is =
passed in move constructor and destruction of the object owning the list de=
stroys the list.<br>2. Lifetime of the stack allocated storage for the arra=
y. It may outlive the own_initializer_list object, but the rules that prohi=
bit various use cases of this class is designed to quarantee that the own_i=
nitializer_list object will never outlive the storage (in constrast to init=
ializer_list).<br><br>This is a novum from the standard library perspective=
.. Even for related optional, the lifetime of storage is bound to the lifeti=
me of object, stored element may be destroyed earlier. The nearest equivale=
nt in hand written code would be:<br>template<typename T><br>struct i=
nplace_object_handler<br>{<br>=C2=A0=C2=A0 explicit inplace_object_handler(=
void* a_ptr)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : ptr(reinterpret_cast<T*=
>(a_ptr))<br>=C2=A0=C2=A0 { new(ptr) T() };<br><br>=C2=A0=C2=A0 ~inplace=
_object_handler() { ptr->~T(); }<br><br>=C2=A0=C2=A0 T* operator->() =
const { return ptr; }<br><br>private:<br>=C2=A0=C2=A0 T* ptr;<br>};<br><br>=
alignas(double) char buffor[sizeof(double)];<br>{<br>=C2=A0 inplace_object_=
handler<double> obj(buffer);<br>};<br>However, I would make such clas=
s non-copyable and move-able to prevent transfer of ownership (even if I ca=
n safely move it to nested scopes). I know that this does not prevent all s=
ituations when such class could be constructed, but eliminates most of them=
.. So my first expectation was that own_initializer_list will also follow th=
is design. This does not eliminate possibility of construct leading to dang=
ling reference, so special rules that makes them ill-formed would still be =
necessary, but exposition of this errors will be reduced.<br><br>Furthermor=
e, your paper also discuss possibility of introducing the sequence_literal =
const& as alternative for the initializer_list and deprecating old feat=
ure. In that case we cannot argument the confusing behavior by pointing to =
current design initializer_list - if we provide true replacement, then ther=
e will be no need to use initializer_list in new syntax.<br><br>Have you co=
nsidered eliminating ability to declare own_initializer_list object by the =
programmer. And force use of auto&& list =3D { "ala"s, &q=
uot;ola"s } even of first declaration? Or dropping the initializer_lis=
t deduction for auto entirely? According to http://www.open-std.org/JTC1/SC=
22/WG21/docs/papers/2014/n3912.html, the total elimination of special auto =
deduction also received strong support (but with opposition when compared t=
o current resolution).<br><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_756_1167183467.1442862198884--
------=_Part_755_199973864.1442862198883--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 22 Sep 2015 06:55:56 +0800
Raw View
--Apple-Mail=_0FC3F665-6AAB-43BB-81EE-A182F573551A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9322, at 1:30 AM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> Firstly, there is type in the destructor, it should say ~own_initializer_=
list.
Yikes, thanks for the correction.
> Secondly the iterator typedef hides the declarations of the iterator for =
the initializer_list class, which are still used for the as the return for =
const begin overload inherited from initializer_list. I think it would be a=
lot cleaner if const_iterator typedef would be provided and the const over=
load would be written explicitly in overview:
> constexpr const_iterator begin() const noexcept; //equivalent to: initial=
izer_list< T >::begin();
Yes, that would be clearer. Should be fixed now.
(The code is pulled from the prototype, which happens to actually be named =
initializer_list<T&&> since N4166.)
> Futhermore in the paper, I didn't found any information if the conversion=
from own_initializer_list<own_initializer_list<T>> to initializer_list<ini=
tializer_list<T>> is quaranteed, It would be important in for
Yes, it=E2=80=99s publicly inherited. I=E2=80=99ll take it that this was cl=
arified on further reading=E2=80=A6
> On 2015=E2=80=9309=E2=80=9322, at 3:03 AM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> This is a novum from the standard library perspective. Even for related o=
ptional, the lifetime of storage is bound to the lifetime of object, stored=
element may be destroyed earlier. The nearest equivalent in hand written c=
ode would be:
>=20
> alignas(double) char buffor[sizeof(double)];
Yes; following your earlier comments I added a section =C2=A74.4.1 Implemen=
tation model. Perhaps I should have mentioned the revision. Here it is:
> Implementation model
>=20
> The sequence is allocated on the stack, and hence deallocated at the end =
of some scope. However, if ownership is transferred, it is destroyed before=
it is deallocated. Users are encouraged to take own_initializer_list at fa=
ce value. Accept that it offers the best of both worlds (the heap and the s=
tack). Let the compiler worry about making it work.
>=20
> Several models are viable to describe or implement the details, for examp=
le, an optional array object, or an aligned_storage buffer used with placem=
ent new. The prototype works by creating a bona fide T[N] array, but removi=
ng its destructor from the AST.
>=20
=E2=80=94=E2=80=94
> However, I would make such class non-copyable and move-able to prevent tr=
ansfer of ownership (even if I can safely move it to nested scopes).
Why?
> I know that this does not prevent all situations when such class could be=
constructed, but eliminates most of them. So my first expectation was that=
own_initializer_list will also follow this design. This does not eliminate=
possibility of construct leading to dangling reference, so special rules t=
hat makes them ill-formed would still be necessary, but exposition of this =
errors will be reduced.
>=20
> Furthermore, your paper also discuss possibility of introducing the seque=
nce_literal const& as alternative for the initializer_list and deprecating =
old feature. In that case we cannot argument the confusing behavior by poin=
ting to current design initializer_list - if we provide true replacement, t=
hen there will be no need to use initializer_list in new syntax.
The committee review of N4166 made clear that initializer_list is considere=
d a =E2=80=9Cvocabulary type.=E2=80=9D They found the earlier paper lacking=
in motivation =E2=80=94 many feel that it works just fine as is.
> Have you considered eliminating ability to declare own_initializer_list o=
bject by the programmer. And force use of auto&& list =3D { "ala"s, "ola"s =
} even of first declaration? Or dropping the initializer_list deduction for=
auto entirely? According to http://www.open-std.org/JTC1/SC22/WG21/docs/pa=
pers/2014/n3912.html, the total elimination of special auto deduction also =
received strong support (but with opposition when compared to current resol=
ution).
A vote of =E2=80=9CSF-3 F-6 N-1 A-1 SA-2=E2=80=9D is still considered to be=
divided. Also, those numbers don=E2=80=99t tell the whole story. The propo=
nents of the status quo are influential.
Even given the sequence_literal approach, support for proper move construct=
ion has the advantages mentioned in =C2=A74.4.
--=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=_0FC3F665-6AAB-43BB-81EE-A182F573551A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9322, at 1:30 AM, Tomasz <<a href=3D"mailto:tomaszkam@gmail.com" =
class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D"">Firstly, there is type in the destructor, i=
t should say ~own_initializer_list.</div></blockquote><div><br class=3D""><=
/div><div>Yikes, thanks for the correction.</div><br class=3D""><blockquote=
type=3D"cite" class=3D""><div class=3D""><div class=3D"">Secondly the iter=
ator typedef hides the declarations of the iterator for the initializer_lis=
t class, which are still used for the as the return for const begin overloa=
d inherited from initializer_list. I think it would be a lot cleaner if con=
st_iterator typedef would be provided and the const overload would be writt=
en explicitly in overview:<br class=3D"">constexpr const_iterator begin() c=
onst noexcept; //equivalent to: initializer_list< T >::begin();<br cl=
ass=3D""></div></div></blockquote><div><br class=3D""></div><div>Yes, that =
would be clearer. Should be fixed now.</div><div><br class=3D""></div><div>=
(The code is pulled from the prototype, which happens to actually be named =
<font face=3D"Courier" class=3D"">initializer_list<T&&></font=
> since N4166.)</div><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><div class=3D"">Futhermore in the paper, I didn't found =
any information if the conversion from own_initializer_list<own_initiali=
zer_list<T>> to initializer_list<initializer_list<T>> =
is quaranteed, It would be important in for </div></div></blockquote><div><=
br class=3D""></div><div>Yes, it=E2=80=99s publicly inherited. I=E2=80=99ll=
take it that this was clarified on further reading=E2=80=A6</div></div><di=
v class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div=
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9309=E2=80=9322, at 3:03 AM, Tomasz <<a href=3D"mailto:tomaszkam@gma=
il.com" class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><div class=3D"">This is a novum fro=
m the standard library perspective. Even for related optional, the lifetime=
of storage is bound to the lifetime of object, stored element may be destr=
oyed earlier. The nearest equivalent in hand written code would be:<br clas=
s=3D""><br class=3D"">alignas(double) char buffor[sizeof(double)];<br class=
=3D""></div></div></blockquote><div class=3D""><br class=3D""></div><div cl=
ass=3D"">Yes; following your earlier comments I added a section =C2=A74.4.1=
<i class=3D"">Implementation model</i>. Perhaps I should have mentioned th=
e revision. Here it is:</div><div class=3D""><br class=3D""></div><div clas=
s=3D""><blockquote type=3D"cite" class=3D""><p style=3D"margin: 0px 0px 8px=
; font-size: 13px; -webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-st=
roke-width: initial;" class=3D"">Implementation model</p></blockquote><bloc=
kquote type=3D"cite" class=3D""><span style=3D"-webkit-text-stroke-color: r=
gb(0, 0, 0); -webkit-text-stroke-width: initial;" class=3D"">The sequence i=
s allocated on the stack, and hence deallocated at the end of some scope. H=
owever, if ownership is transferred, it is destroyed before it is deallocat=
ed. Users are encouraged to take </span><span style=3D"-webkit-text-stroke-=
color: rgb(0, 0, 0); -webkit-text-stroke-width: initial; font-size: 11px; f=
ont-family: Courier; background-color: rgb(245, 245, 245);" class=3D"">own_=
initializer_list</span><span style=3D"-webkit-text-stroke-color: rgb(0, 0, =
0); -webkit-text-stroke-width: initial;" class=3D""> at face value. Accept =
that it offers the best of both worlds (the heap and the stack). Let the co=
mpiler worry about making it work.</span></blockquote><blockquote type=3D"c=
ite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=
=3D""><p style=3D"margin: 0px 0px 16px; -webkit-text-stroke-color: rgb(0, 0=
, 0); -webkit-text-stroke-width: initial;" class=3D"">Several models are vi=
able to describe or implement the details, for example, an <span style=3D"f=
ont-size: 11px; font-family: Courier; background-color: rgb(245, 245, 245);=
" class=3D"">optional</span> array object, or an <span style=3D"font-size: =
11px; font-family: Courier; background-color: rgb(245, 245, 245);" class=3D=
"">aligned_storage</span> buffer used with placement new. The prototype wor=
ks by creating a bona fide <span style=3D"font-size: 11px; font-family: Cou=
rier; background-color: rgb(245, 245, 245);" class=3D"">T[N]</span> array, =
but removing its destructor from the AST.</p></blockquote></div><div class=
=3D"">=E2=80=94=E2=80=94</div><div class=3D""><br class=3D""></div><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><div class=3D"">However, I wou=
ld make such class non-copyable and move-able to prevent transfer of owners=
hip (even if I can safely move it to nested scopes). </div></div></blockquo=
te><div class=3D""><br class=3D""></div><div class=3D"">Why?</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"">=
I know that this does not prevent all situations when such class could be c=
onstructed, but eliminates most of them. So my first expectation was that o=
wn_initializer_list will also follow this design. This does not eliminate p=
ossibility of construct leading to dangling reference, so special rules tha=
t makes them ill-formed would still be necessary, but exposition of this er=
rors will be reduced.<br class=3D""><br class=3D"">Furthermore, your paper =
also discuss possibility of introducing the sequence_literal const& as =
alternative for the initializer_list and deprecating old feature. In that c=
ase we cannot argument the confusing behavior by pointing to current design=
initializer_list - if we provide true replacement, then there will be no n=
eed to use initializer_list in new syntax.<br class=3D""></div></div></bloc=
kquote><div class=3D""><br class=3D""></div><div class=3D"">The committee r=
eview of N4166 made clear that <font face=3D"Courier" class=3D"">initialize=
r_list</font> is considered a =E2=80=9Cvocabulary type.=E2=80=9D They found=
the earlier paper lacking in motivation =E2=80=94 many feel that it works =
just fine as is.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div class=3D""><div class=3D"">Have you considered eliminating ability to d=
eclare own_initializer_list object by the programmer. And force use of auto=
&& list =3D { "ala"s, "ola"s } even of first declaration? Or droppi=
ng the initializer_list deduction for auto entirely? According to <a href=
=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html" cla=
ss=3D"">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html<=
/a>, the total elimination of special auto deduction also received strong s=
upport (but with opposition when compared to current resolution).<br class=
=3D""></div></div></blockquote></div><div class=3D""><div class=3D""><br cl=
ass=3D""></div></div><div class=3D"">A vote of =E2=80=9CSF-3 F-6 N-1 A-1 SA=
-2=E2=80=9D is still considered to be divided. Also, those numbers don=E2=
=80=99t tell the whole story. The proponents of the status quo are influent=
ial.</div><div class=3D""><br class=3D""></div><div class=3D"">Even given t=
he <font face=3D"Courier" class=3D"">sequence_literal</font> approach, supp=
ort for proper move construction has the advantages mentioned in =C2=A74.4.=
</div><div class=3D""><br class=3D""></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" 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=_0FC3F665-6AAB-43BB-81EE-A182F573551A--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Mon, 21 Sep 2015 23:20:03 -0700 (PDT)
Raw View
------=_Part_5864_1382921000.1442902804042
Content-Type: multipart/alternative;
boundary="----=_Part_5865_480628378.1442902804043"
------=_Part_5865_480628378.1442902804043
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> Futhermore in the paper, I didn't found any information if the conversion=
=20
> from own_initializer_list<own_initializer_list<T>> to=20
> initializer_list<initializer_list<T>> is quaranteed, It would be importan=
t=20
> in for=20
>
>
> Yes, it=E2=80=99s publicly inherited. I=E2=80=99ll take it that this was =
clarified on=20
> further reading=E2=80=A6
>
The public inheritance guarantees that the:=20
own_initializer_list<own_initializer_list<T>> to=20
initializer_list<own_initializer_list<T>>.=20
The conversion from initializer_list<own_initializer_list<T>> to=20
initializer_list<initializer_list<T>> is think that I have put in question,=
=20
requires conversion from initializer_list<U> to initializer_list<V> (if U=
=20
is convertible to V), which are not currently supported=20
(http://goo.gl/8J3U8q).
Furthermore if we consider own_initializer_list<T> to be member of=20
own_initializer_list<own_initializer_list<T>>, then the later should be=20
ill-formed according to your proposed rules.
=20
> However, I would make such class non-copyable and move-able to prevent=20
> transfer of ownership (even if I can safely move it to nested scopes).=20
>
>
> Why?
>
Because it my own class (inplace_object_handler) I cannot create a special=
=20
rules that would prevent transfer of ownership only to nested scopes. So by=
=20
adding move constructor I am enabling both safe transfers to nested scopes=
=20
and unsafe ones outside the scope (via new or return). From one side, we=20
aim to provide equal support for user defined types as built-in/standard=20
library, from other we are making standard classes special by giving it=20
rules not available for mere programmers. Ability to write an example=20
implementation of given class highly simplifies understanding of its=20
details.
I understand your motivation for introducing move constructor, but I=20
personally do not consider it justifying special treatment. For arguments:
1) Not-exposing moved-from sequence. The standard requires that moved-from=
=20
object are in valid state, so sequence of moved-from object is also valid=
=20
output. Notice that this thing I will receive after moving element from=20
list<T> to vector<T>.
2) Transition period for the code. The code in the form:
auto l1 =3D { "ala"s, "ola"s };
auto l2 =3D l1;
Will not longer compile, and require change. It could be either changed to:
auto l2 =3D std::move(l1);
And:
auto& l2 =3D l1;
The second one does not require move constructor.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5865_480628378.1442902804043
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><div>Futherm=
ore in the paper, I didn't found any information if the conversion from=
own_initializer_list<own_<wbr>initializer_list<T>> to initiali=
zer_list<initializer_<wbr>list<T>> is quaranteed, It would be i=
mportant in for </div></div></blockquote><div><br></div><div>Yes, it=E2=80=
=99s publicly inherited. I=E2=80=99ll take it that this was clarified on fu=
rther reading=E2=80=A6</div></div></div></blockquote><div><br>The public in=
heritance guarantees that the: own_initializer_list<own_initializer_list=
<T>> to initializer_list<own_initializer_list<T>>. <br=
>The conversion from initializer_list<own_initializer_list<T>> =
to initializer_list<initializer_list<T>> is think that I have p=
ut in question, requires conversion from initializer_list<U> to initi=
alizer_list<V> (if U is convertible to V), which are not currently su=
pported (http://goo.gl/8J3U8q).<br>Furthermore if we consider own_initializ=
er_list<T> to be member of own_initializer_list<own_initializer_li=
st<T>>, then the later should be ill-formed according to your prop=
osed rules.<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div><d=
iv>However, I would make such class non-copyable and move-able to prevent t=
ransfer of ownership (even if I can safely move it to nested scopes). </div=
></div></blockquote><div><br></div><div>Why?</div></div></div></blockquote>=
<div><br>Because it my own class (inplace_object_handler) I cannot create a=
special rules that would prevent transfer of ownership only to nested scop=
es. So by adding move constructor I am=C2=A0 enabling both safe transfers t=
o nested scopes and unsafe ones outside the scope (via new or return). From=
one side, we aim to provide equal support for user defined types as built-=
in/standard library, from other we are making standard classes special by g=
iving it rules not available for mere programmers. Ability to write an exam=
ple implementation of given class highly simplifies understanding of its de=
tails.<br><br>I understand your motivation for introducing move constructor=
, but I personally do not consider it justifying special treatment. For arg=
uments:<br>1) Not-exposing moved-from sequence. The standard requires that =
moved-from object are in valid state, so sequence of moved-from object is a=
lso valid output. Notice that this thing I will receive after moving elemen=
t from list<T> to vector<T>.<br>2) Transition period for the co=
de. The code in the form:<br>auto l1 =3D { "ala"s, "ola"=
;s };<br>auto l2 =3D l1;<br>Will not longer compile, and require change. It=
could be either changed to:<br>auto l2 =3D std::move(l1);<br>And:<br>auto&=
amp; l2 =3D l1;<br>The second one does not require move constructor.<br></d=
iv></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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_5865_480628378.1442902804043--
------=_Part_5864_1382921000.1442902804042--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 26 Sep 2015 15:33:34 +0800
Raw View
--Apple-Mail=_807DBABF-3DDF-4593-874E-BE6C020770B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Sorry about the late reply. The window for this email got buried under a st=
ack.
> On 2015=E2=80=9309=E2=80=9322, at 2:20 PM, Tomasz <tomaszkam@gmail.com> w=
rote:
>=20
> The public inheritance guarantees that the: own_initializer_list<own_init=
ializer_list<T>> to initializer_list<own_initializer_list<T>>.=20
> The conversion from initializer_list<own_initializer_list<T>> to initiali=
zer_list<initializer_list<T>> is think that I have put in question, require=
s conversion from initializer_list<U> to initializer_list<V> (if U is conve=
rtible to V), which are not currently supported (http://goo.gl/8J3U8q).
> Furthermore if we consider own_initializer_list<T> to be member of own_in=
itializer_list<own_initializer_list<T>>, then the later should be ill-forme=
d according to your proposed rules.
Ah, I understand the question now. Let=E2=80=99s abbreviate =E2=80=9Cinitia=
lizer_list" as =E2=80=9Cil."
il<own_il<T>> is the result of the conversion. Its iterators expose a seque=
nce of own_il<T> const&. These belong to its storage array, which is not a =
subobject, so no problem there. (Each has its own storage array, and everyt=
hing lives in the enclosing stack frame.) Each own_il<T> const& in turn beh=
aves just like an il<T>. Even if you try to move from the sequence of an ow=
n_il<T> const& (or an il<T>), the program still behaves correctly because o=
rdinary copy constructors are compatible with const&& rvalue references. (H=
owever, I don=E2=80=99t think things will even go that far awry in this exa=
mple.)
> Because it my own class (inplace_object_handler) I cannot create a specia=
l rules that would prevent transfer of ownership only to nested scopes. So =
by adding move constructor I am enabling both safe transfers to nested sco=
pes and unsafe ones outside the scope (via new or return). From one side, w=
e aim to provide equal support for user defined types as built-in/standard =
library, from other we are making standard classes special by giving it rul=
es not available for mere programmers. Ability to write an example implemen=
tation of given class highly simplifies understanding of its details.
What does this facility already do for il? Your choices are to static_asser=
t it yourself, or to rely on implementation-specific warnings firing inside=
your templates. The former option seems more viable. Given an existing C++=
11-compatible check against il, it should be a minor change to reject class=
es derived from il too.
I don=E2=80=99t think it=E2=80=99s reasonable to design this proposal for a=
world where il doesn=E2=80=99t exist. You=E2=80=99re free to take my ideas=
and propose to deprecate il, but I personally won=E2=80=99t.
> I understand your motivation for introducing move constructor, but I pers=
onally do not consider it justifying special treatment. For arguments:
> 1) Not-exposing moved-from sequence. The standard requires that moved-fro=
m object are in valid state, so sequence of moved-from object is also valid=
output. Notice that this thing I will receive after moving element from li=
st<T> to vector<T>.
own_il models a container well enough that it should follow the same conven=
tion for its moved-from state. You can=E2=80=99t directly move a list<T> to=
a vector<T>, and the moved-from state of containers is unspecified, but if=
you could, a post-condition of an empty vector would certainly be higher Q=
OI.
> 2) Transition period for the code. The code in the form:
> auto l1 =3D { "ala"s, "ola"s };
> auto l2 =3D l1;
> Will not longer compile, and require change. It could be either changed t=
o:
> auto l2 =3D std::move(l1);
> And:
> auto& l2 =3D l1;
> The second one does not require move constructor.
If initializer_list was never standardized in the first place, it would be =
easier to ask users to switch to references. I think that the committee wil=
l prefer adding std::move to changing the object declarations into referenc=
es.
--=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=_807DBABF-3DDF-4593-874E-BE6C020770B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">Sorry about the la=
te reply. The window for this email got buried under a stack.<div class=3D"=
"><br class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">=
On 2015=E2=80=9309=E2=80=9322, at 2:20 PM, Tomasz <<a href=3D"mailto:tom=
aszkam@gmail.com" class=3D"">tomaszkam@gmail.com</a>> wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D=
"">The public inheritance guarantees that the: own_initializer_list<own_=
initializer_list<T>> to initializer_list<own_initializer_list&l=
t;T>>. <br class=3D""><div class=3D"">The conversion from initia=
lizer_list<own_initializer_list<T>> to initializer_list<init=
ializer_list<T>> is think that I have put in question, requires co=
nversion from initializer_list<U> to initializer_list<V> (if U =
is convertible to V), which are not currently supported (<a href=3D"http://=
goo.gl/8J3U8q" class=3D"">http://goo.gl/8J3U8q</a>).<br class=3D"">Furtherm=
ore if we consider own_initializer_list<T> to be member of own_initia=
lizer_list<own_initializer_list<T>>, then the later should be i=
ll-formed according to your proposed rules.<br class=3D""></div></div></div=
></blockquote><div><br class=3D""></div><div>Ah, I understand the question =
now. Let=E2=80=99s abbreviate =E2=80=9C<font face=3D"Courier" class=3D"">in=
itializer_list</font>" as =E2=80=9C<font face=3D"Courier" class=3D"">il</fo=
nt>."</div><div><br class=3D""></div><div><font face=3D"Courier" class=3D""=
>il<own_il<T>></font> is the result of the conversion. Its iter=
ators expose a sequence of <font face=3D"Courier" class=3D"">own_il<T>=
; const&</font>. These belong to its storage array, which is not a subo=
bject, so no problem there. (Each has its own storage array, and everything=
lives in the enclosing stack frame.) Each <font face=3D"Courier" class=3D"=
">own_il<T> const&</font> in turn behaves just like an <font face=
=3D"Courier" class=3D"">il<T></font>. Even if you try to move from th=
e sequence of an <font face=3D"Courier" class=3D"">own_il<T> const&am=
p;</font> (or an <font face=3D"Courier" class=3D"">il<T></font>), the=
program still behaves correctly because ordinary copy constructors are com=
patible with <font face=3D"Courier" class=3D"">const&&</font> rvalu=
e references. (However, I don=E2=80=99t think things will even go that far =
awry in this example.)</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Because i=
t my own class (inplace_object_handler) I cannot create a special rules tha=
t would prevent transfer of ownership only to nested scopes. So by adding m=
ove constructor I am enabling both safe transfers to nested scopes an=
d unsafe ones outside the scope (via new or return). From one side, we aim =
to provide equal support for user defined types as built-in/standard librar=
y, from other we are making standard classes special by giving it rules not=
available for mere programmers. Ability to write an example implementation=
of given class highly simplifies understanding of its details.</div></div>=
</div></blockquote><div><br class=3D""></div><div>What does this facility a=
lready do for <font face=3D"Courier" class=3D"">il</font>? Your choices are=
to <font face=3D"Courier" class=3D"">static_assert</font> it yourself, or =
to rely on implementation-specific warnings firing inside your templates. T=
he former option seems more viable. Given an existing C++11-compatible chec=
k against <span style=3D"font-family: Courier;" class=3D"">il</span>, =
it should be a minor change to reject classes derived from <font face=3D"Co=
urier" class=3D"">il</font> too.</div><div><br class=3D""></div><div>I don=
=E2=80=99t think it=E2=80=99s reasonable to design this proposal for a worl=
d where <font face=3D"Courier" class=3D"">il</font> doesn=E2=80=99t exist. =
You=E2=80=99re free to take my ideas and propose to deprecate <span st=
yle=3D"font-family: Courier;" class=3D"">il</span>, but I personally won=E2=
=80=99t.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D""><div dir=3D"ltr" class=3D""><div class=3D"">I understand your motiva=
tion for introducing move constructor, but I personally do not consider it =
justifying special treatment. For arguments:<br class=3D"">1) Not-exposing =
moved-from sequence. The standard requires that moved-from object are in va=
lid state, so sequence of moved-from object is also valid output. Notice th=
at this thing I will receive after moving element from list<T> to vec=
tor<T>.<br class=3D""></div></div></div></blockquote><div><br class=
=3D""></div><div><font face=3D"Courier" class=3D"">own_il</font> model=
s a container well enough that it should follow the same convention for its=
moved-from state. You can=E2=80=99t directly move a <font face=3D"Courier"=
class=3D"">list<T></font> to a <font face=3D"Courier" class=3D"">vec=
tor<T></font>, and the moved-from state of containers is unspecified,=
but if you could, a post-condition of an empty <font face=3D"Courier" clas=
s=3D"">vector</font> would certainly be higher QOI.</div><br class=3D""><bl=
ockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D=
""><div class=3D"">2) Transition period for the code. The code in the form:=
<br class=3D"">auto l1 =3D { "ala"s, "ola"s };<br class=3D"">auto l2 =3D l1=
;<br class=3D"">Will not longer compile, and require change. It could be ei=
ther changed to:<br class=3D"">auto l2 =3D std::move(l1);<br class=3D"">And=
:<br class=3D"">auto& l2 =3D l1;<br class=3D"">The second one does not =
require move constructor.<br class=3D""></div></div></div></blockquote><br =
class=3D""></div>If <font face=3D"Courier" class=3D"">initializer_list</fon=
t> was never standardized in the first place, it would be easier to as=
k users to switch to references. I think that the committee will prefer add=
ing <font face=3D"Courier" class=3D"">std::move</font> to changing the obje=
ct declarations into references.</div><div class=3D""><br class=3D""></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" 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=_807DBABF-3DDF-4593-874E-BE6C020770B0--
.