--Apple-Mail=_75100711-2170-4B68-85A1-DCA700621036
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

I notice some proposals N4115 and N3728 (formerly N3416) advocating extensi=
ons for manipulation of parameter packs. I think they are rejecting std::tu=
ple unnecessarily, potentially adding legwork for users.

From N3728:

> Compilation speed is often gating in metaprogramming. In implementating t=
he bases trait proposed in N3729 as a g++4.7 extension, I compared the perf=
ormance of returning a tuple type giving all the base classes of a class wi=
th returning a simple typelist class containing no members and no recursive=
 expansion. The simple typelist class was 60 times faster to compile. A bui=
lt-in parameter list would presumably be even faster than that. Given that =
the recursive member generation in tuple provides no benefit for typelists,=
 tuple-based typelists should probably be avoided for performance reasons a=
lone.

From N4115:

> A class template that just holds a parameter pack:
>=20
>     template <class... T> struct packer { };
>=20
> This is inspired by std::tuple, but it lacks members, so it could serve a=
s an empty base class, and an object of the ultimate type could always be i=
nstantiated (even if the parameter pack contains void or some type that lac=
ks a default constructor).

My experience with using std::tuple has been quite positive. My project doe=
s heavy meta-lifting with what amounts to a first-order predicate unificati=
on engine, and it compiles in seconds. While developing it, my tests with t=
uple versus an empty packer-like alternative showed no difference.

The key is that instantiating tuple is the only part that's slow, but you n=
ever need to instantiate a metadata type. Before a template-id is ODR-used,=
 it only exists as a disembodied name, not resolved to a partial specializa=
tion, and equal in compiler cost to any other template-id of the same compl=
exity, which is just naked argument list (as proposed in N3728) plus a name=
.. I'm not sure what caused the slowdown mentioned in N3728. Perhaps GCC 4.7=
's std::tuple_element instantiated something, but this no longer happens si=
nce 4.8.

The tuple and tuple-like metafunction interface (std::tuple_size, std::tupl=
e_element, etc) are already specified so as to work without necessarily ins=
tantiating their argument. Rather than adding new facilities to the standar=
d, it would be better to reflect common implementation practice in a requir=
ement that they not instantiate.

Few scenarios exist where pure type-list instantiation is useful. If you ad=
d member metafunctions to the type-list class, then you pay for the declara=
tions of members that are not used. If you do not add members, then nothing=
 is really instantiated. There is tag dispatching, but usage like tag< tupl=
e< x, y, z > > is more expressive.

Codebases written on std::tuple and std::tuple_element exist, but nothing i=
s written against any other std::packer class or naked argument list facili=
ty, so there's a compatibility argument. std::tuple is ready to produce run=
time objects when the user does want them, so there's a convenience argumen=
t.

--
For what it's worth, my application does similar things to N4115, but a Boo=
lean tuple-set-contains metafunction never came up. I ended up with only tu=
ple_upto, which slices a tuple from the beginning to just before a given ty=
pe. (If the type is not found, the argument is returned unsliced.) In metap=
rogramming, if you're going to use initial results to drive further process=
ing, it's important to leverage memoization. I think Boolean set arithmetic=
 throws away too much information to make useful primitives under memoizati=
on. Or, perhaps the take-away lesson is that a generic type-list processing=
 library won't be very useful if built piecemeal from small proposals. Perf=
ormance would be easier to preserve if is_contained_in generated memoized i=
ntermediate results for likely subsequent operations.

--=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=_75100711-2170-4B68-85A1-DCA700621036
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">I notice some proposal=
s N4115 and N3728 (formerly N3416) advocating extensions for manipulation o=
f parameter packs. I think they are rejecting <font face=3D"Courier">std::t=
uple</font> unnecessarily, potentially adding legwork for users.<div><br></=
div><div>From N3728:<div><br></div><div></div><blockquote type=3D"cite"><di=
v>Compilation speed is often gating in metaprogramming. In implementating t=
he&nbsp;bases&nbsp;trait proposed in N3729&nbsp;as a g++4.7 extension, I co=
mpared the performance of returning a&nbsp;tuple&nbsp;type giving all the b=
ase classes of a&nbsp;class with returning a simple typelist&nbsp;class con=
taining no members and no recursive expansion. The simple&nbsp;typelist cla=
ss was 60&nbsp;times faster to compile. A built-in parameter list would pre=
sumably be even faster than&nbsp;that. Given that the recursive member gene=
ration in&nbsp;tuple&nbsp;provides no benefit for&nbsp;typelists,&nbsp;tupl=
e-based&nbsp;typelists should probably be avoided for performance reasons&n=
bsp;alone.</div></blockquote><div><br></div><div>From N4115:</div><div><br>=
</div><div></div><blockquote type=3D"cite"><div>A class template that just =
holds a parameter pack:<br><br><div>&nbsp; &nbsp; template &lt;class... T&g=
t; struct packer { };</div><br class=3D"Apple-interchange-newline">This is =
inspired by&nbsp;std::tuple, but it lacks members,&nbsp;so it could serve a=
s an empty base class,&nbsp;and an object of the&nbsp;ultimate type could a=
lways be instantiated&nbsp;(even if the parameter pack contains&nbsp;void&n=
bsp;or some type that lacks a&nbsp;default constructor).</div></blockquote>=
<div><br></div><div>My experience with using <font face=3D"Courier">std::tu=
ple</font> has been quite positive. My project does heavy meta-lifting with=
 what amounts to a first-order predicate unification engine, and it compile=
s in seconds. While developing it, my tests with tuple versus an empty <fon=
t face=3D"Courier">packer</font>-like alternative showed no difference.</di=
v><div><br></div><div>The key is that instantiating&nbsp;<font face=3D"Cour=
ier">tuple</font> is the only part that&rsquo;s slow, but you never need to=
 instantiate a metadata type. Before a template-id is ODR-used, it only exi=
sts as a disembodied name, not resolved to a partial specialization, and eq=
ual in compiler cost to any other template-id of the same complexity, which=
 is just naked argument list (as proposed in&nbsp;N3728) plus a name. I&rsq=
uo;m not sure what caused the slowdown mentioned in N3728. Perhaps GCC 4.7&=
rsquo;s <font face=3D"Courier">std::tuple_element</font> instantiated somet=
hing, but this no longer happens since 4.8.</div><div><br></div></div><div>=
The tuple and tuple-like metafunction interface (<font face=3D"Courier">std=
::tuple_size</font>, <font face=3D"Courier">std::tuple_element</font>, etc)=
 are already specified so as to work without necessarily instantiating thei=
r argument. Rather than adding new facilities to the standard, it would be =
better to reflect common implementation practice in a requirement that they=
 not instantiate.</div><div><br></div><div>Few scenarios exist where pure t=
ype-list instantiation is useful. If you add member metafunctions to the ty=
pe-list class, then you pay for the declarations of members that are not us=
ed. If you do not add members, then nothing is really instantiated. There i=
s tag dispatching, but usage like&nbsp;<font face=3D"Courier">tag&lt; tuple=
&lt; x, y, z &gt; &gt;</font> is more expressive.</div><div><br></div><div>=
Codebases written on <font face=3D"Courier">std::tuple</font>&nbsp;and <fon=
t face=3D"Courier">std::tuple_element</font> exist, but nothing is written =
against any other&nbsp;<font face=3D"Courier">std::packer</font> class or n=
aked argument list facility, so there&rsquo;s a compatibility argument. <fo=
nt face=3D"Courier">std::tuple</font>&nbsp;is ready to produce runtime obje=
cts when the user does want them, so there&rsquo;s a convenience argument.<=
/div><div><br></div><div>&mdash;</div><div>For what it&rsquo;s worth, my ap=
plication does similar things to N4115, but a Boolean tuple-set-contains me=
tafunction never came up. I ended up with only <font face=3D"Courier">tuple=
_upto</font>, which slices a tuple from the beginning to just before a give=
n type. (If the type is not found, the argument is returned unsliced.) In m=
etaprogramming, if you&rsquo;re going to use initial results&nbsp;to drive =
further processing, it&rsquo;s important to leverage memoization. I think B=
oolean set arithmetic throws away too much information to make useful primi=
tives under memoization. Or, perhaps the take-away lesson is that a generic=
 type-list processing library won&rsquo;t be very useful if built piecemeal=
 from small proposals. Performance would be easier to preserve if <font fac=
e=3D"Courier">is_contained_in</font> generated memoized intermediate result=
s for likely subsequent operations.</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_75100711-2170-4B68-85A1-DCA700621036--

.

On 11 July 2014 03:56, David Krauss <potswa@gmail.com> wrote:
> I notice some proposals N4115 and N3728 (formerly N3416) advocating
> extensions for manipulation of parameter packs. I think they are rejecting
> std::tuple unnecessarily, potentially adding legwork for users.
>
> From N3728:
>
> Compilation speed is often gating in metaprogramming. In implementating the
> bases trait proposed in N3729 as a g++4.7 extension, I compared the
> performance of returning a tuple type giving all the base classes of a class
> with returning a simple typelist class containing no members and no
> recursive expansion. The simple typelist class was 60 times faster to
> compile. A built-in parameter list would presumably be even faster than
> that. Given that the recursive member generation in tuple provides no
> benefit for typelists, tuple-based typelists should probably be avoided for
> performance reasons alone.


I don't see how a 60x difference in compilation speed is "rejecting tuple
unnecessarily".

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-07-11, at 3:29 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> I don't see how a 60x difference in compilation speed is "rejecting tuple
> unnecessarily".

Because it doesn't exist any more, and hasn't for a long time. Read my first paragraph.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 11 July 2014 10:51, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-07-11, at 3:29 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> I don't see how a 60x difference in compilation speed is "rejecting tuple
>> unnecessarily".
>
> Because it doesn't exist any more, and hasn't for a long time. Read my first paragraph.

Ah, all implementations have figured out a way to ensure the problem
doesn't happen,
great. After reading N3728, it gives rather more reasons for not using
tuple. Apparently
all of those are now moot.

Quite many people consider using pair as the element of maps a
mistake, since the
simple utility type gets feature bloat from the requirements of the
container. Perhaps
it would be a similar mistake to couple parameter pack access and
potentially also
reflection facilities with tuple.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_224258EE-A7E7-4F82-9300-EDDA0D9573EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-11, at 4:03 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> Ah, all implementations have figured out a way to ensure the problem
> doesn't happen,
> great. After reading N3728, it gives rather more reasons for not using
> tuple. Apparently
> all of those are now moot.

Well, points about convenience may still have merit. But it's a stretch to =
say we need a dedicated facility. Essentially it comes down to providing a =
shortcut to specialization matching.

> Quite many people consider using pair as the element of maps a
> mistake, since the
> simple utility type gets feature bloat from the requirements of the
> container. Perhaps
> it would be a similar mistake to couple parameter pack access and
> potentially also
> reflection facilities with tuple.

That's the thing about a non-instantiated template (may as well be an incom=
plete class): It has no features whatsoever. Whatever other name you give t=
ype_list, the facilities that use it should as a rule not instantiate it, b=
ecause that takes compiler time and memory.

--=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=_224258EE-A7E7-4F82-9300-EDDA0D9573EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;11, at 4:03 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Ah, all imp=
lementations have figured out a way to ensure the problem<br>doesn't happen=
,<br>great. After reading N3728, it gives rather more reasons for not using=
<br>tuple. Apparently<br>all of those are now moot.<br></blockquote><div><b=
r></div><div>Well, points about convenience may still have merit. But it&rs=
quo;s a stretch to say we need a dedicated facility. Essentially it comes d=
own to providing a shortcut to specialization matching.</div><br><blockquot=
e type=3D"cite">Quite many people consider using pair as the element of map=
s a<br>mistake, since the<br>simple utility type gets feature bloat from th=
e requirements of the<br>container. Perhaps<br>it would be a similar mistak=
e to couple parameter pack access and<br>potentially also<br>reflection fac=
ilities with tuple.<br></blockquote><div><br></div></div>That&rsquo;s the t=
hing about a non-instantiated template (may as well be an incomplete class)=
: It has no features whatsoever. Whatever other name you give <font face=3D=
"Courier">type_list</font>, the facilities that use it should as a rule not=
 instantiate it, because that takes compiler time and memory.<div><br></div=
></body></html>

<p></p>

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

--Apple-Mail=_224258EE-A7E7-4F82-9300-EDDA0D9573EC--

.