Topic: variant construction/assignment from braced value
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Feb 2016 16:56:30 +0800
Raw View
--Apple-Mail=_FB425172-0E99-4E1B-A0AA-464E01E882FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Hi Axel and Agust=C3=ADn,
The latest variant proposal and implementation provide catch-all constructo=
r and assignment operator templates. These implement overload resolution to=
determine which (if any) alternative type is most suitable to receive the =
given value, then forward to the appropriate delegate.
However, perfect forwarding isn=E2=80=99t completely perfect. It doesn=E2=
=80=99t support braced init lists.
variant< char, string > q =3D { { 999 } }; // error: can=E2=80=99t deduce T=
..
variant< char, string > r =3D { 999 }; // valid, but overflows.
variant< char, string > s =3D { 'a', 'b', 'c' }; // error.
Wouldn=E2=80=99t it be better to provide overload sets of non-template cons=
tructors and assignment operators? This might present a different set of im=
plementation challenges, but the wrapping would be thinner and the compile-=
time complexity may ultimately be lower. The specification would certainly =
be simpler.
- Cheers,
D
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_FB425172-0E99-4E1B-A0AA-464E01E882FB
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"">Hi=
Axel and Agust=C3=ADn,</div><div class=3D""><br class=3D""></div>The lates=
t <font face=3D"Courier" class=3D"">variant</font> proposal and implementat=
ion provide catch-all constructor and assignment operator templates. T=
hese implement overload resolution to determine which (if any) alternative =
type is most suitable to receive the given value, then forward to the appro=
priate delegate.<div class=3D""><br class=3D""></div><div class=3D"">Howeve=
r, perfect forwarding isn=E2=80=99t completely perfect. It doesn=E2=80=99t =
support braced init lists.</div><div class=3D""><br class=3D""></div><div c=
lass=3D""><font face=3D"Courier" class=3D"">variant< char, string > q=
=3D { { 999 } }; // error: can=E2=80=99t deduce T.</font></div><div class=
=3D""><div class=3D""><font face=3D"Courier" class=3D"">variant< char, s=
tring > r =3D { 999 }; // valid, but overflows.</font></div></div><div c=
lass=3D""><div class=3D""><font face=3D"Courier" class=3D"">variant< cha=
r, string > s =3D { </font><span style=3D"font-family: Courier;" cl=
ass=3D"">'</span><font face=3D"Courier" class=3D"">a', </font><span st=
yle=3D"font-family: Courier;" class=3D"">'</span><font face=3D"Courier" cla=
ss=3D"">b</font><span style=3D"font-family: Courier;" class=3D"">'</span><f=
ont face=3D"Courier" class=3D"">, </font><span style=3D"font-family: C=
ourier;" class=3D"">'</span><font face=3D"Courier" class=3D"">c</font><span=
style=3D"font-family: Courier;" class=3D"">'</span><font face=3D"Courier" =
class=3D""> }; // error.</font></div></div><div class=3D""><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D"">Wouldn=
=E2=80=99t it be better to provide overload sets of non-template constructo=
rs and assignment operators? This might present a different set of implemen=
tation challenges, but the wrapping would be thinner and the compile-time c=
omplexity may ultimately be lower. The specification would certainly be sim=
pler.</div><div class=3D""><br class=3D""></div><div class=3D""><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- Cheers,</div><div c=
lass=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
D</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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_FB425172-0E99-4E1B-A0AA-464E01E882FB--
.
Author: Axel Naumann <Axel.Naumann@cern.ch>
Date: Thu, 11 Feb 2016 10:18:33 +0100
Raw View
--------------000606080509080901030803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi David,
Thank you, that's a good argument. Would you mind writing a paper on
this? I don't want to halt the LWG process for this. The current variant
will hopefully end up in a TS at some point; before we vote that out we
can have your improvement in.
I'd rather not stop the current variant by going back to LEWG and
re-opening the design discussion at this stage. I'd prefer it to arrive
in the TS, even at the cost of a only partially perfect (-ly forwarding)
variant.
Cheers, Axel.
On 11/02/16 09:56, David Krauss wrote:
> Hi Axel and Agust=C3=ADn,
>
> The latest variant proposal and implementation provide catch-all
> constructor and assignment operator templates. These implement
> overload resolution to determine which (if any) alternative type is
> most suitable to receive the given value, then forward to the
> appropriate delegate.
>
> However, perfect forwarding isn=E2=80=99t completely perfect. It doesn=E2=
=80=99t
> support braced init lists.
>
> variant< char, string > q =3D { { 999 } }; // error: can=E2=80=99t deduce=
T.
> variant< char, string > r =3D { 999 }; // valid, but overflows.
> variant< char, string > s =3D { 'a', 'b', 'c' }; // error.
>
> Wouldn=E2=80=99t it be better to provide overload sets of non-template
> constructors and assignment operators? This might present a different
> set of implementation challenges, but the wrapping would be thinner
> and the compile-time complexity may ultimately be lower. The
> specification would certainly be simpler.
>
> - Cheers,
> D
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------000606080509080901030803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi David,<br>
<br>
Thank you, that's a good argument. Would you mind writing a paper on
this? I don't want to halt the LWG process for this. The current
variant will hopefully end up in a TS at some point; before we vote
that out we can have your improvement in.<br>
<br>
I'd rather not stop the current variant by going back to LEWG and
re-opening the design discussion at this stage. I'd prefer it to
arrive in the TS, even at the cost of a only partially perfect (-ly
forwarding) variant.<br>
<br>
Cheers, Axel.<br>
<br>
<div class=3D"moz-cite-prefix">On 11/02/16 09:56, David Krauss wrote:<b=
r>
</div>
<blockquote
cite=3D"mid:9A41B088-08C0-4222-8558-FA734F61BDE5@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<div class=3D"">Hi Axel and Agust=C3=ADn,</div>
<div class=3D""><br class=3D"">
</div>
The latest <font class=3D"" face=3D"Courier">variant</font> proposal
and implementation provide catch-all constructor and assignment
operator templates.=C2=A0These implement overload resolution to
determine which (if any) alternative type is most suitable to
receive the given value, then forward to the appropriate delegate.
<div class=3D""><br class=3D"">
</div>
<div class=3D"">However, perfect forwarding isn=E2=80=99t completely
perfect. It doesn=E2=80=99t support braced init lists.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D""><font class=3D"" face=3D"Courier">variant< char,
string > q =3D { { 999 } }; // error: can=E2=80=99t deduce T.<=
/font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">variant< char,
string > r =3D { 999 }; // valid, but overflows.</font></div=
>
</div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">variant< char,
string > s =3D {=C2=A0</font><span style=3D"font-family: Cou=
rier;"
class=3D"">'</span><font class=3D"" face=3D"Courier">a',=C2=A0<=
/font><span
style=3D"font-family: Courier;" class=3D"">'</span><font
class=3D"" face=3D"Courier">b</font><span style=3D"font-family:
Courier;" class=3D"">'</span><font class=3D"" face=3D"Courier">=
,=C2=A0</font><span
style=3D"font-family: Courier;" class=3D"">'</span><font
class=3D"" face=3D"Courier">c</font><span style=3D"font-family:
Courier;" class=3D"">'</span><font class=3D"" face=3D"Courier">=
=C2=A0};
// error.</font></div>
</div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D"">Wouldn=E2=80=99t it be better to provide overload set=
s of
non-template constructors and assignment operators? This might
present a different set of implementation challenges, but the
wrapping would be thinner and the compile-time complexity may
ultimately be lower. The specification would certainly be
simpler.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>-
Cheers,</div>
<div class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>D</div>
<div class=3D""><br class=3D"">
</div>
</blockquote>
<br>
</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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------000606080509080901030803--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Feb 2016 17:54:14 +0800
Raw View
--Apple-Mail=_8938B3E1-FEEA-4978-AEDB-89E5358AF857
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
I suppose I can write a paper for Oulu, but it=E2=80=99s looking a little d=
oubtful that I=E2=80=99ll get anything at all submitted for Jacksonville. A=
prototype would probably be in order.
Is this certainly a design matter? Perhaps it could be handled as a defect =
report regarding implementation latitude. Switching from templates to non-t=
emplates should only break operator@<T>() function calls with template argu=
ment lists. Un-blessing that particular usage might be a small enough chang=
e to avoid holding up the TS. Then, a valid TS implementation could use tem=
plates or pre-computed overloads.
- D
> On 2016=E2=80=9302=E2=80=9311, at 5:18 PM, Axel Naumann <Axel.Naumann@cer=
n.ch> wrote:
>=20
> Hi David,
>=20
> Thank you, that's a good argument. Would you mind writing a paper on this=
? I don't want to halt the LWG process for this. The current variant will h=
opefully end up in a TS at some point; before we vote that out we can have =
your improvement in.
>=20
> I'd rather not stop the current variant by going back to LEWG and re-open=
ing the design discussion at this stage. I'd prefer it to arrive in the TS,=
even at the cost of a only partially perfect (-ly forwarding) variant.
>=20
> Cheers, Axel.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_8938B3E1-FEEA-4978-AEDB-89E5358AF857
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"">I suppose I can wr=
ite a paper for Oulu, but it=E2=80=99s looking a little doubtful that I=E2=
=80=99ll get anything at all submitted for Jacksonville. A prototype would =
probably be in order.<div class=3D""><br class=3D""></div><div class=3D"">I=
s this certainly a design matter? Perhaps it could be handled as a defect r=
eport regarding implementation latitude. Switching from templates to non-te=
mplates should only break <font face=3D"Courier" class=3D"">operator@&=
lt;T>()</font> function calls with template argument lists. Un-bles=
sing that particular usage might be a small enough change to avoid holding =
up the TS. Then, a valid TS implementation could use templates or pre-compu=
ted overloads.</div><div class=3D""><br class=3D""></div><div class=3D""><s=
pan class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- D</div><di=
v class=3D""><br class=3D""><div class=3D""><div class=3D""><br class=3D"">=
<div><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=930=
2=E2=80=9311, at 5:18 PM, Axel Naumann <<a href=3D"mailto:Axel.Naumann@c=
ern.ch" class=3D"">Axel.Naumann@cern.ch</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D"">
=20
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
" class=3D"">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
Hi David,<br class=3D"">
<br class=3D"">
Thank you, that's a good argument. Would you mind writing a paper on
this? I don't want to halt the LWG process for this. The current
variant will hopefully end up in a TS at some point; before we vote
that out we can have your improvement in.<br class=3D"">
<br class=3D"">
I'd rather not stop the current variant by going back to LEWG and
re-opening the design discussion at this stage. I'd prefer it to
arrive in the TS, even at the cost of a only partially perfect (-ly
forwarding) variant.<br class=3D"">
<br class=3D"">
Cheers, Axel.<br class=3D""></div></div></blockquote></div><br class=3D=
""></div></div></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_8938B3E1-FEEA-4978-AEDB-89E5358AF857--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 11 Feb 2016 11:56:34 +0200
Raw View
On 11 February 2016 at 11:54, David Krauss <potswa@gmail.com> wrote:
> I suppose I can write a paper for Oulu, but it=E2=80=99s looking a little=
doubtful
> that I=E2=80=99ll get anything at all submitted for Jacksonville. A proto=
type would
> probably be in order.
>
> Is this certainly a design matter? Perhaps it could be handled as a defec=
t
> report regarding implementation latitude. Switching from templates to
> non-templates should only break operator@<T>() function calls with templa=
te
> argument lists. Un-blessing that particular usage might be a small enough
> change to avoid holding up the TS. Then, a valid TS implementation could =
use
> templates or pre-computed overloads.
Is it a defect? The examples you gave are not convincing.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Feb 2016 18:14:54 +0800
Raw View
--Apple-Mail=_8643B2D9-B85B-46F9-BF2D-891F40A315E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9302=E2=80=9311, at 5:56 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 11 February 2016 at 11:54, David Krauss <potswa@gmail.com> wrote:
>> I suppose I can write a paper for Oulu, but it=E2=80=99s looking a littl=
e doubtful
>> that I=E2=80=99ll get anything at all submitted for Jacksonville. A prot=
otype would
>> probably be in order.
>>=20
>> Is this certainly a design matter? Perhaps it could be handled as a defe=
ct
>> report regarding implementation latitude. Switching from templates to
>> non-templates should only break operator@<T>() function calls with templ=
ate
>> argument lists. Un-blessing that particular usage might be a small enoug=
h
>> change to avoid holding up the TS. Then, a valid TS implementation could=
use
>> templates or pre-computed overloads.
>=20
>=20
> Is it a defect?=20
The defect would be that the spec is too constraining. Implementations shou=
ld be free to expose overload sets, rather than wrapping them indirectly in=
templates. The resolution would only forbid users from the template syntax=
, and mark the form of the synopsis as expository.
Maybe that=E2=80=99s not worth the trouble of filing it. That=E2=80=99s why=
I=E2=80=99m asking :vP .
> The examples you gave are not convincing.
Besides the braces, there could be a reduction in metaprogramming under the=
hood. Only a prototype would determine that.
Perhaps a sexier example would be,
std::variant< std::vector< int >, std::vector< double > > vv;
void foo( vv );
foo({ 1, 2, 3 }); // OK
foo({ 1.2, 3.4, 5.6 }); // OK
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_8643B2D9-B85B-46F9-BF2D-891F40A315E4
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 2016=E2=80=9302=
=E2=80=9311, at 5:56 PM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">=
On 11 February 2016 at 11:54, David Krauss <<a href=3D"mailto:potswa@gma=
il.com" class=3D"">potswa@gmail.com</a>> wrote:<br class=3D""><blockquot=
e type=3D"cite" class=3D"">I suppose I can write a paper for Oulu, but it=
=E2=80=99s looking a little doubtful<br class=3D"">that I=E2=80=99ll get an=
ything at all submitted for Jacksonville. A prototype would<br class=3D"">p=
robably be in order.<br class=3D""><br class=3D"">Is this certainly a desig=
n matter? Perhaps it could be handled as a defect<br class=3D"">report rega=
rding implementation latitude. Switching from templates to<br class=3D"">no=
n-templates should only break operator@<T>() function calls with temp=
late<br class=3D"">argument lists. Un-blessing that particular usage might =
be a small enough<br class=3D"">change to avoid holding up the TS. Then, a =
valid TS implementation could use<br class=3D"">templates or pre-computed o=
verloads.<br class=3D""></blockquote><br class=3D""><br class=3D"">Is it a =
defect? <br class=3D""></div></div></blockquote></div><br class=3D""><=
div class=3D"">The defect would be that the spec is too constraining. Imple=
mentations should be free to expose overload sets, rather than wrapping the=
m indirectly in templates. The resolution would only forbid users from the =
template syntax, and mark the form of the synopsis as expository.</div=
><div class=3D""><br class=3D""></div><div class=3D"">Maybe that=E2=80=99s =
not worth the trouble of filing it. That=E2=80=99s why I=E2=80=99m asking :=
vP .</div><div class=3D""><br class=3D""></div><div class=3D""><blockquote =
type=3D"cite" class=3D"">The examples you gave are not convincing.</blockqu=
ote><br class=3D""></div><div class=3D""><div class=3D"">Besides the braces=
, there could be a reduction in metaprogramming under the hood. Only a prot=
otype would determine that.</div></div><div class=3D""><br class=3D""></div=
><div class=3D"">Perhaps a sexier example would be,</div><div class=3D""><b=
r class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">std::v=
ariant< std::vector< int >, std::vector< double > > vv;</=
font></div><div class=3D""><font face=3D"Courier" class=3D"">void foo( vv )=
;</font></div><div class=3D""><font face=3D"Courier" class=3D""><br class=
=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D"">foo({ =
1, 2, 3 }); // OK</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">foo({ 1.2, 3.4, 5.6 }); // OK</font></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_8643B2D9-B85B-46F9-BF2D-891F40A315E4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 11 Feb 2016 12:24:08 +0200
Raw View
On 11 February 2016 at 12:14, David Krauss <potswa@gmail.com> wrote:
> Is it a defect?
>
>
> The defect would be that the spec is too constraining. Implementations
> should be free to expose overload sets, rather than wrapping them indirectly
> in templates. The resolution would only forbid users from the template
> syntax, and mark the form of the synopsis as expository.
However, the spec needs to be accurate/constraining enough that it
defines what the behavior of the overload set is. Implementations
should not be free to alter the behavior of it.
> Perhaps a sexier example would be,
>
> std::variant< std::vector< int >, std::vector< double > > vv;
> void foo( vv );
>
> foo({ 1, 2, 3 }); // OK
> foo({ 1.2, 3.4, 5.6 }); // OK
That's much more convincing, yes, thanks. I find that tuple allows doing that,
as does optional. Therefore I think it would indeed be beneficial
for variant to support it as well, for consistency reasons.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 11 Feb 2016 20:13:31 +0800
Raw View
--Apple-Mail=_81A96393-BB36-4A6D-9113-B2E6B65915EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9302=E2=80=9311, at 6:24 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> However, the spec needs to be accurate/constraining enough that it
> defines what the behavior of the overload set is. Implementations
> should not be free to alter the behavior of it.
Right. Allowing overload resolution to succeed on braces would be rather sp=
ecial, and maybe we=E2=80=99ve evolved past the point where success in such=
things is just chalked up to QOI. On the other hand, TSes and their implem=
entations have a high degree of flux. After all, most people just refer to =
std::experimental, not std::experimental::fundamentals_v2 in particular =E2=
=80=94 so they might get fundamentals_v3 :vP .
Forbidding template arguments helps provide wiggle room for a extension. On=
the other hand, likewise, that wiggle room is probably already inherent in=
being in a TS. So I=E2=80=99m not going to worry about this for now.
>> Perhaps a sexier example would be,
>>=20
>> std::variant< std::vector< int >, std::vector< double > > vv;
>> void foo( vv );
>>=20
>> foo({ 1, 2, 3 }); // OK
>> foo({ 1.2, 3.4, 5.6 }); // OK
>=20
> That's much more convincing, yes, thanks. I find that tuple allows doing =
that,
> as does optional. Therefore I think it would indeed be beneficial
> for variant to support it as well, for consistency reasons.
Cool. Unfortunately, now that I tried it, it doesn=E2=80=99t quite work lik=
e that. This is more accurate:
std::variant< std::vector< int >, std::array_view< int > > vvv;
void foo( vvv );
foo({{ 1, 2, 3 }}); // OK, variant is a container
foo({ std::list< int >{ 1, 2, 3 }}); // OK, variant is a view
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_81A96393-BB36-4A6D-9113-B2E6B65915EA
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 2016=E2=80=9302=
=E2=80=9311, at 6:24 PM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">=
However, the spec needs to be accurate/constraining enough that it<br class=
=3D"">defines what the behavior of the overload set is. Implementations<br =
class=3D"">should not be free to alter the behavior of it.<br class=3D""></=
div></div></blockquote><div><br class=3D""></div><div>Right. Allowing overl=
oad resolution to succeed on braces would be rather special, and maybe we=
=E2=80=99ve evolved past the point where success in such things is just cha=
lked up to QOI. On the other hand, TSes and their implementations have a hi=
gh degree of flux. After all, most people just refer to <font face=3D"Couri=
er" class=3D"">std::experimental</font>, not <font face=3D"Courier" class=
=3D"">std::experimental::fundamentals_v2</font> in particular =E2=80=94 so =
they might get <font face=3D"Courier" class=3D"">fundamentals_v3</font>&nbs=
p;:vP .</div><div><br class=3D""></div><div>Forbidding template arguments h=
elps provide wiggle room for a extension. On the other hand, likewise, that=
wiggle room is probably already inherent in being in a TS. So I=E2=80=99m =
not going to worry about this for now.</div><div><br class=3D""></div><bloc=
kquote type=3D"cite" class=3D""><div class=3D""><div class=3D""><blockquote=
type=3D"cite" class=3D"">Perhaps a sexier example would be,<br class=3D"">=
<br class=3D"">std::variant< std::vector< int >, std::vector< d=
ouble > > vv;<br class=3D"">void foo( vv );<br class=3D""><br class=
=3D"">foo({ 1, 2, 3 }); // OK<br class=3D"">foo({ 1.2, 3.4, 5.6 }); // OK<b=
r class=3D""></blockquote><br class=3D"">That's much more convincing, yes, =
thanks. I find that tuple allows doing that,<br class=3D"">as does optional=
.. Therefore I think it would indeed be beneficial<br class=3D"">for variant=
to support it as well, for consistency reasons.<br class=3D""></div></div>=
</blockquote><div><br class=3D""></div><div>Cool. Unfortunately, now that I=
tried it, it doesn=E2=80=99t quite work like that. This is more accurate:<=
/div><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">std::=
variant< std::vector< int >, std::array_view< int > > vvv=
;<br class=3D"">void foo( vvv );</font></div><div><font face=3D"Courier" cl=
ass=3D""><br class=3D""></font></div><div><font face=3D"Courier" class=3D""=
>foo({{ 1, 2, 3 }}); // OK, variant is a container<br class=3D""></font></d=
iv><div><font face=3D"Courier" class=3D"">foo({ std::list< int >{ 1, =
2, 3 }}); // OK, variant is a view</font></div><div><br class=3D""></div></=
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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_81A96393-BB36-4A6D-9113-B2E6B65915EA--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Thu, 11 Feb 2016 09:44:00 -0300
Raw View
On 2/11/2016 5:56 AM, David Krauss wrote:
> Hi Axel and Agust=C3=ADn,
>
> The latest variant proposal and implementation provide catch-all
> constructor and assignment operator templates. These implement overload
> resolution to determine which (if any) alternative type is most suitable
> to receive the given value, then forward to the appropriate delegate.
>
> However, perfect forwarding isn=E2=80=99t completely perfect. It doesn=E2=
=80=99t support
> braced init lists.
>
> variant< char, string > q =3D { { 999 } }; // error: can=E2=80=99t deduce=
T.
> variant< char, string > r =3D { 999 }; // valid, but overflows.
> variant< char, string > s =3D { 'a', 'b', 'c' }; // error.
>
> Wouldn=E2=80=99t it be better to provide overload sets of non-template
> constructors and assignment operators? This might present a different
> set of implementation challenges, but the wrapping would be thinner and
> the compile-time complexity may ultimately be lower. The specification
> would certainly be simpler.
Speaking from my Eggs.Variant experience, the reason I designed that=20
constructor as doing overload resolution was to approximate what a true=20
set of constructors would do (imperfect), while leaving the door open to=20
a proper implementation in terms of inherited constructors (supports=20
braced init lists and stuff).
The reason I never changed that was that I implemented the proper=20
solution, or rather a simplified version that gets all the corner cases=20
wrong=20
(https://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2c33=
2d2843cb0),=20
and the implementation costs in terms of compilation-time and binary=20
size were just too big.
The set of inherited constructor implementation does not really provide=20
that many different implementation challenges for the proposed=20
`variant`. Since it supports reference types as members, the number of=20
constructors you'd need for each type is the same as those needed for=20
determining overload resolution (4 for object, 2 for non-const=20
reference, 1 for const reference, 0 for void). The only difference is=20
that for a duplicated (decayed) type you'd need to delete the=20
corresponding constructors, given that inheritance would otherwise hide=20
the rest and just pick the last rather than causing an ambiguity like=20
overloading resolution does.
In short, a proper set of non-template constructors is the way it was=20
intended from the beginning, and it has been proved to be viable. Now if=20
you could get implementors to do something about the cost of those=20
recursive instantiation, then that would be great.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9
http://talesofcpp.fusionfenix.com
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Anthony Williams <anthony.ajw@gmail.com>
Date: Thu, 11 Feb 2016 13:49:34 +0000
Raw View
On 11/02/16 12:13, David Krauss wrote:
>=20
>> On 2016=E2=80=9302=E2=80=9311, at 6:24 PM, Ville Voutilainen
>> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote=
:
>>
>>> Perhaps a sexier example would be,
>>>
>>> std::variant< std::vector< int >, std::vector< double > > vv;
>>> void foo( vv );
>>>
>>> foo({ 1, 2, 3 }); // OK
>>> foo({ 1.2, 3.4, 5.6 }); // OK
>>
>> That's much more convincing, yes, thanks. I find that tuple allows
>> doing that,
>> as does optional. Therefore I think it would indeed be beneficial
>> for variant to support it as well, for consistency reasons.
>=20
> Cool. Unfortunately, now that I tried it, it doesn=E2=80=99t quite work l=
ike
> that.
That all depends on your implementation technique. My implementation at
https://bitbucket.org/anthonyw/variant handles that just fine:
typedef se::variant< std::vector< int >, std::vector< double > > vv;
unsigned foo(vv v){
return v.index();
}
int main(){
assert(foo({ 1, 2, 3 })=3D=3D0); // OK
assert(foo({ 1.2, 3.4, 5.6 })=3D=3D1); // OK
}
It handles 2 out of 3 of your earlier examples too:
se::variant< char, std::string > q=3D { { 999 } }; // error: can=E2=80=
=99t
deduce T.
se::variant< char, std::string > r =3D { 999 }; // valid, but overflows=
..
se::variant< char, std::string > s =3D { 'a', 'b', 'c' }; // OK.
The only non-emplace constructors are:
template<typename _Type>
constexpr variant(_Type&& __x);
template<typename _Type,
typename _Enable=3D
typename std::enable_if<
(__constructible_matches<std::initializer_list<_Type>,_Types...>::__type::_=
_length>0)
>::type>
constexpr variant(std::initializer_list<_Type> __x);
Anthony
--=20
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 12 Feb 2016 01:30:51 +0800
Raw View
--Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9302=E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3=
=A9 <kaballo86@hotmail.com> wrote:
>=20
> Speaking from my Eggs.Variant experience, the reason I designed that cons=
tructor as doing overload resolution was to approximate what a true set of =
constructors would do (imperfect), while leaving the door open to a proper =
implementation in terms of inherited constructors (supports braced init lis=
ts and stuff).
>=20
> The reason I never changed that was that I implemented the proper solutio=
n, or rather a simplified version that gets all the corner cases wrong (htt=
ps://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2c332d28=
43cb0), and the implementation costs in terms of compilation-time and binar=
y size were just too big.
The inheriting constructors are causing quadratic bloat because each Nth in=
heritance level needs to instantiate the N inherited constructors. (Inherit=
ing constructors are more than just a name lookup hack.)
That=E2=80=99s tough=E2=80=A6 perhaps limiting the depth to log(N) would he=
lp, using an inheritance tree. How many types did it take to cause trouble?
> The set of inherited constructor implementation does not really provide t=
hat many different implementation challenges for the proposed `variant`. Si=
nce it supports reference types as members, the number of constructors you'=
d need for each type is the same as those needed for determining overload r=
esolution (4 for object, 2 for non-const reference, 1 for const reference, =
0 for void).
Hmm, & and const&& copy constructor overloads seem like a waste. They do pr=
ovide parity with the template solution, but most of the standard library i=
gnores those cases.
> The only difference is that for a duplicated (decayed) type you'd need to=
delete the corresponding constructors, given that inheritance would otherw=
ise hide the rest and just pick the last rather than causing an ambiguity l=
ike overloading resolution does.
Right. Putting all the implementation at the leaves of a tree could help th=
at, too.
That=E2=80=99s easier said than done, of course. Here=E2=80=99s a technique=
that could help. It=E2=80=99s at the fringes of conformance, but Clang and=
GCC both let it pass. More fleshed-out demo at http://melpon.org/wandbox/p=
ermlink/5ZOUb4tZ7vmOhvKL <http://melpon.org/wandbox/permlink/5ZOUb4tZ7vmOhv=
KL> .
struct b { // Base class wants to initialize derived state.
constexpr b( int i );
};
struct d : b {
using b::b;
int s =3D s; // Self-assignment is free for a trivially-copyable type.
};
constexpr b::b( int i )
{ static_cast< d * >( this )->s =3D i; } // Start the derived lifetime =
early.
constexpr d q( 5 );
static_assert ( q.s =3D=3D 5, "" );
This technique could be used to initialize the trivially-copyable alternati=
ves. Non-constexpr constructors could use placement new in the base leaf fo=
llowed by a no-op union mem-initializer in the storage class.
> In short, a proper set of non-template constructors is the way it was int=
ended from the beginning, and it has been proved to be viable. Now if you c=
ould get implementors to do something about the cost of those recursive ins=
tantiation, then that would be great.
Richard Smith is currently working to improve the model for inheriting cons=
tructors, but I don=E2=80=99t suppose that will improve the bloat issue. It=
=E2=80=99s too bad that implementation decided to link all the inline funct=
ions.
> On 2016=E2=80=9302=E2=80=9311, at 9:49 PM, Anthony Williams <anthony.ajw@=
gmail.com> wrote:
>=20
> That all depends on your implementation technique. My implementation at
> https://bitbucket.org/anthonyw/variant <https://bitbucket.org/anthonyw/va=
riant> handles that just fine:
Well, that=E2=80=99s by deducing an initializer list and then passing its c=
ontents. That doesn=E2=80=99t cover aggregates; it=E2=80=99s a separate dis=
cussion.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F
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 2016=E2=80=9302=
=E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3=A9 <<a href=3D"mai=
lto:kaballo86@hotmail.com" class=3D"">kaballo86@hotmail.com</a>> wrote:<=
/div><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"=
">Speaking from my Eggs.Variant experience, the reason I designed that cons=
tructor as doing overload resolution was to approximate what a true set of =
constructors would do (imperfect), while leaving the door open to a proper =
implementation in terms of inherited constructors (supports braced init lis=
ts and stuff).<br class=3D""><br class=3D"">The reason I never changed that=
was that I implemented the proper solution, or rather a simplified version=
that gets all the corner cases wrong (<a href=3D"https://github.com/eggs-c=
pp/variant/commit/0372c94d99f3442e2fbe026d18b2c332d2843cb0" class=3D"">http=
s://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2c332d284=
3cb0</a>), and the implementation costs in terms of compilation-time and bi=
nary size were just too big.<br class=3D""></div></div></blockquote><div><b=
r class=3D""></div><div>The inheriting constructors are causing quadratic b=
loat because each Nth inheritance level needs to instantiate the N inherite=
d constructors. (Inheriting constructors are more than just a name lookup h=
ack.)</div><div><br class=3D""></div><div>That=E2=80=99s tough=E2=80=A6 per=
haps limiting the depth to log(N) would help, using an inheritance tree. Ho=
w many types did it take to cause trouble?</div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D"">The set of inherit=
ed constructor implementation does not really provide that many different i=
mplementation challenges for the proposed `variant`. Since it supports refe=
rence types as members, the number of constructors you'd need for each type=
is the same as those needed for determining overload resolution (4 for obj=
ect, 2 for non-const reference, 1 for const reference, 0 for void).</div></=
div></blockquote><div><br class=3D""></div><div>Hmm, <font face=3D"Cou=
rier" class=3D"">&</font> and <font face=3D"Courier" class=3D"">const&a=
mp;&</font> copy constructor overloads seem like a waste. They do provi=
de parity with the template solution, but most of the standard library igno=
res those cases.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div class=3D""><div class=3D"">The only difference is that for a duplicated=
(decayed) type you'd need to delete the corresponding constructors, given =
that inheritance would otherwise hide the rest and just pick the last rathe=
r than causing an ambiguity like overloading resolution does.<br class=3D""=
></div></div></blockquote><div><br class=3D""></div><div>Right. Putting all=
the implementation at the leaves of a tree could help that, too.</div><div=
><br class=3D""></div><div>That=E2=80=99s easier said than done, of course.=
Here=E2=80=99s a technique that could help. It=E2=80=99s at the fringes of=
conformance, but Clang and GCC both let it pass. More fleshed-out demo at&=
nbsp;<a href=3D"http://melpon.org/wandbox/permlink/5ZOUb4tZ7vmOhvKL" class=
=3D"">http://melpon.org/wandbox/permlink/5ZOUb4tZ7vmOhvKL</a> .</div><=
div><br class=3D""></div><div><font face=3D"Courier" class=3D"">struct b { =
// Base class wants to initialize derived state.<br class=3D"">  =
; constexpr b( int i );<br class=3D"">};<br class=3D""><br class=3D"">struc=
t d : b {<br class=3D""> using b::b;<br class=3D""><br class=
=3D""> int s =3D s; // Self-assignment is free for a trivially=
-copyable type.<br class=3D"">};<br class=3D"">constexpr b::b( int i )<br c=
lass=3D""> { static_cast< d * >( this )->s =3D i; } /=
/ Start the derived lifetime early.<br class=3D""><br class=3D"">constexpr =
d q( 5 );</font></div><div><font face=3D"Courier" class=3D"">static_assert =
( q.s =3D=3D 5, ""</font><span style=3D"font-family: Courier;" class=3D"">&=
nbsp;);</span><font face=3D"Courier" class=3D""><br class=3D""><br class=3D=
""></font></div><div>This technique could be used to initialize the trivial=
ly-copyable alternatives. Non-constexpr constructors could use placement ne=
w in the base leaf followed by a no-op union mem-initializer in the storage=
class.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div class=3D"">In short, a proper set of non-template constructors i=
s the way it was intended from the beginning, and it has been proved to be =
viable. Now if you could get implementors to do something about the cost of=
those recursive instantiation, then that would be great.<br class=3D""></d=
iv></div></blockquote></div><br class=3D""><div class=3D"">Richard Smith is=
currently working to improve the model for inheriting constructors, but I =
don=E2=80=99t suppose that will improve the bloat issue. It=E2=80=99s too b=
ad that implementation decided to link all the inline functions.</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=
=80=9302=E2=80=9311, at 9:49 PM, Anthony Williams <<a href=3D"mailto:ant=
hony.ajw@gmail.com" class=3D"">anthony.ajw@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><div class=3D""><span class=3D"" styl=
e=3D"float: none; display: inline !important;">That all depends on your imp=
lementation technique. My implementation at</span><br class=3D""><a href=3D=
"https://bitbucket.org/anthonyw/variant" class=3D"">https://bitbucket.org/a=
nthonyw/variant</a><span class=3D"" style=3D"float: none; display: inline !=
important;"> handles that just fine:</span><br class=3D""></div></bloc=
kquote><br class=3D""></div><div class=3D"">Well, that=E2=80=99s by deducin=
g an initializer list and then passing its contents. That doesn=E2=80=99t c=
over aggregates; it=E2=80=99s a separate discussion.</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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Thu, 11 Feb 2016 14:49:52 -0300
Raw View
On 2/11/2016 2:30 PM, David Krauss wrote:
>
>> On 2016=E2=80=9302=E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3=
=A9
>> <kaballo86@hotmail.com <mailto:kaballo86@hotmail.com>> wrote:
>>
>> Speaking from my Eggs.Variant experience, the reason I designed that
>> constructor as doing overload resolution was to approximate what a
>> true set of constructors would do (imperfect), while leaving the door
>> open to a proper implementation in terms of inherited constructors
>> (supports braced init lists and stuff).
>>
>> The reason I never changed that was that I implemented the proper
>> solution, or rather a simplified version that gets all the corner
>> cases wrong
>> (https://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2=
c332d2843cb0),
>> and the implementation costs in terms of compilation-time and binary
>> size were just too big.
>
> The inheriting constructors are causing quadratic bloat because each Nth
> inheritance level needs to instantiate the N inherited constructors.
> (Inheriting constructors are more than just a name lookup hack.)
Yes, but you are on the right track. I hope this serves as a nudge for=20
implementors to look at the compile-time/bloat issue.
> That=E2=80=99s tough=E2=80=A6 perhaps limiting the depth to log(N) would =
help, using an
> inheritance tree. How many types did it take to cause trouble?
Perhaps... I tried a log(N) approach for the storage union=20
(https://github.com/eggs-cpp/variant/commit/434115664bca9492b1eb66b980f2021=
b12e7f9ae),=20
as the cut in symbol length alone should be enough to reduce the bloat.=20
That solution turned out to be slightly worse though, possibly due to=20
the poor pack splitting, but I still believe there's potential and I=20
need to get back to working on that.
Define trouble? The inherited constructors recursive instantiation adds=20
to the recursive union for constexpr support which makes it approach the=20
recursion limit faster, and the bloat increases even for a single type.
>> The set of inherited constructor implementation does not really
>> provide that many different implementation challenges for the proposed
>> `variant`. Since it supports reference types as members, the number of
>> constructors you'd need for each type is the same as those needed for
>> determining overload resolution (4 for object, 2 for non-const
>> reference, 1 for const reference, 0 for void).
>
> Hmm, & and const&& copy constructor overloads seem like a waste. They do
> provide parity with the template solution, but most of the standard
> library ignores those cases.
The proposed `variant` supports references, and not providing a full set=20
of overloads leads to "incorrect" overload resolution. Do we really want=20
`variant<int const&, int&&>(42)` to work rather than being ambiguous?
>> The only difference is that for a duplicated (decayed) type you'd need
>> to delete the corresponding constructors, given that inheritance would
>> otherwise hide the rest and just pick the last rather than causing an
>> ambiguity like overloading resolution does.
>
> Right. Putting all the implementation at the leaves of a tree could help
> that, too.
I did not consider that, it would be a lot *lot* better than having to=20
do pack lookup and conditional deletion at each recursion level. Thank=20
you for this tip.
> That=E2=80=99s easier said than done, of course. Here=E2=80=99s a techniq=
ue that could
> help. It=E2=80=99s at the fringes of conformance, but Clang and GCC both =
let it
> pass. More fleshed-out demo at
> http://melpon.org/wandbox/permlink/5ZOUb4tZ7vmOhvKL .
>
> struct b { // Base class wants to initialize derived state.
> constexpr b( int i );
> };
>
> struct d : b {
> using b::b;
>
> int s =3D s; // Self-assignment is free for a trivially-copyable typ=
e.
> };
> constexpr b::b( int i )
> { static_cast< d * >( this )->s =3D i; } // Start the derived
> lifetime early.
>
> constexpr d q( 5 );
> static_assert ( q.s =3D=3D 5, "" );
>
> This technique could be used to initialize the trivially-copyable
> alternatives. Non-constexpr constructors could use placement new in the
> base leaf followed by a no-op union mem-initializer in the storage class.
AFAIK there are no non-constexpr constructors. Consider something like=20
`variant<mutex> v;` at namespace scope doing constant initialization.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9
http://talesofcpp.fusionfenix.com
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 11 Feb 2016 20:03:38 +0200
Raw View
On 11 February 2016 at 19:49, Agust=C3=ADn K-ballo Berg=C3=A9
<kaballo86@hotmail.com> wrote:
>>> The reason I never changed that was that I implemented the proper
>>> solution, or rather a simplified version that gets all the corner
>>> cases wrong
>>>
>>> (https://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b=
2c332d2843cb0),
>>> and the implementation costs in terms of compilation-time and binary
>>> size were just too big.
>>
>>
>> The inheriting constructors are causing quadratic bloat because each Nth
>> inheritance level needs to instantiate the N inherited constructors.
>> (Inheriting constructors are more than just a name lookup hack.)
>
>
> Yes, but you are on the right track. I hope this serves as a nudge for
Well, if we get a solution for
http://cplusplus.github.io/EWG/ewg-active.html#102,
for which there will be a proposal for Jacksonville, you don't need to inhe=
rit
a chain, just inherit a pack and do a using-declaration for the pack.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: John Bytheway <jbytheway@gmail.com>
Date: Fri, 12 Feb 2016 21:18:58 -0500
Raw View
On 2016-02-11 12:30, David Krauss wrote:
>=20
>> On 2016=E2=80=9302=E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3=
=A9
>> <kaballo86@hotmail.com <mailto:kaballo86@hotmail.com>> wrote:
>>
>> Speaking from my Eggs.Variant experience, the reason I designed that
>> constructor as doing overload resolution was to approximate what a
>> true set of constructors would do (imperfect), while leaving the door
>> open to a proper implementation in terms of inherited constructors
>> (supports braced init lists and stuff).
>>
>> The reason I never changed that was that I implemented the proper
>> solution, or rather a simplified version that gets all the corner
>> cases wrong
>> (https://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2=
c332d2843cb0),
>> and the implementation costs in terms of compilation-time and binary
>> size were just too big.
>=20
> The inheriting constructors are causing quadratic bloat because each Nth
> inheritance level needs to instantiate the N inherited constructors.
> (Inheriting constructors are more than just a name lookup hack.)
>=20
> That=E2=80=99s tough=E2=80=A6 perhaps limiting the depth to log(N) would =
help, using an
> inheritance tree. How many types did it take to cause trouble?
I suspect a more practical solution in terms of simplifying the
implementation would be to 'unroll' the inheritance and do a direct
implementation of, say, up to 5 or 10 alternatives in the variant
(writing everything out 'by hand') which would make virtually all
real-world cases use the minimal number of instantiations (and minimal
symbol size).
Of course, this requires O(n^2) code to implement all these by hand up
to size n (and that code has to be parsed every time regardless of how
many alternatives your variant actually uses), so there is a trade-off
to be had.
John Bytheway
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.