Topic: What else can be template, extending the
Author: David Krauss <potswa@gmail.com>
Date: Mon, 2 Feb 2015 13:45:52 +0800
Raw View
--Apple-Mail=_94B552FF-3EB9-490B-8546-A00E475F54E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9302=E2=80=9302, at 10:07 AM, mobiphil <mobi@mobiphil.com> =
wrote:
>=20
> (please read previous posts)
Please take your own advice. The archives of this mailing list are searchab=
le on groups.google.com. AST manipulations have been suggested before, and =
the idea is always half-baked.
> Also c++ compiler is becoming very very slow because the language tried t=
o be backward compatible etc.
The compilers are getting faster (as are the CPUs executing them). Any slow=
down you see is a result of bloat, as library headers get bigger (often due=
to their own legacies) and templates get deeper (not a legacy issue, but t=
his does tend to be compounded over time).
There=E2=80=99s ongoing work to improve header caching. The troublesome =E2=
=80=9Cbackwards compatibility=E2=80=9D is mainly the specter of macro name =
collisions with library identifiers. On one hand, the Modules extension pro=
poses new rules to eliminate this by replacing #include headers with someth=
ing else. On the other hand, it would be nice simply to have existing heade=
rs (and template instantiations) be cached, with diagnoses when macro colli=
sions (or whatever) defeat the cache. In the big picture, the backwards-com=
patible feature would have been nicer, but the community got tired of waiti=
ng for it. (See also: export templates.)
--=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=_94B552FF-3EB9-490B-8546-A00E475F54E2
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=9302=
=E2=80=9302, at 10:07 AM, mobiphil <<a href=3D"mailto:mobi@mobiphil.com"=
class=3D"">mobi@mobiphil.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D""><span style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display=
: inline !important;" class=3D"">(please read previous posts)</span><br cla=
ss=3D"Apple-interchange-newline"></div></blockquote></div><br class=3D""><d=
iv class=3D"">Please take your own advice. The archives of this mailing lis=
t are searchable on <a href=3D"http://groups.google.com" class=3D"">groups.=
google.com</a>. AST manipulations have been suggested before, and the idea =
is always half-baked.</div><div class=3D""><br class=3D""></div><div class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">Also c++ compile=
r is becoming very very slow because the language tried to be backward comp=
atible etc.</div></blockquote></div><div class=3D""><div class=3D""><span c=
lass=3D"" style=3D"float: none; display: inline !important;"><br class=3D""=
></span></div></div><div class=3D""><span class=3D"" style=3D"float: none; =
display: inline !important;">The compilers are getting faster (as are the C=
PUs executing them). Any slowdown you see is a result of bloat, as library =
headers get bigger (often due to their own legacies) and templates get deep=
er (<i class=3D"">not</i> a legacy issue, but this does tend to be com=
pounded over time).</span></div><div class=3D""><span class=3D"" style=3D"f=
loat: none; display: inline !important;"><br class=3D""></span></div><div c=
lass=3D""><span class=3D"" style=3D"float: none; display: inline !important=
;">There=E2=80=99s ongoing work to improve header caching. The troublesome =
=E2=80=9Cbackwards compatibility=E2=80=9D is mainly the specter of macro na=
me collisions with library identifiers. On one hand, the Modules extension =
proposes new rules to eliminate this by replacing <font face=3D"Courier" cl=
ass=3D"">#include</font> headers with something else. On the other han=
d, it would be nice simply to have existing headers (and template instantia=
tions) be cached, with diagnoses when macro collisions (or whatever) defeat=
the cache. In the big picture, the backwards-compatible feature would have=
been nicer, but the community got tired of waiting for it. (See also: <fon=
t face=3D"Courier" class=3D"">export</font> templates.)</span></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=_94B552FF-3EB9-490B-8546-A00E475F54E2--
.
Author: mobiphil <mobi@mobiphil.com>
Date: Mon, 2 Feb 2015 02:30:23 -0800 (PST)
Raw View
------=_Part_3217_873901669.1422873023663
Content-Type: multipart/alternative;
boundary="----=_Part_3218_1024689050.1422873023663"
------=_Part_3218_1024689050.1422873023663
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> Please take your own advice. The archives of this mailing list are=20
> searchable on groups.google.com. AST manipulations have been suggested=20
> before, and the idea is always half-baked.
>
Thanks for pointing me to archives. I prefer then to remove the word AST=20
manipulation from the ideas I am playing with. I will instead come back to=
=20
code pasting, or compile time macros. The emphasis is on pasting code. So=
=20
not really AST manipulation. One would think about changing the AST once it=
=20
is built. No. It is about pasting code exactly as templates are pasting=20
code. Is templating considered AST manipulation? Well... yes and no... but=
=20
you got the point.
> Also c++ compiler is becoming very very slow because the language tried t=
o=20
> be backward compatible etc.
>
> The compilers are getting faster (as are the CPUs executing them). Any=20
> slowdown you see is a result of bloat, as library headers get bigger (oft=
en=20
> due to their own legacies) and templates get deeper (*not* a legacy=20
> issue, but this does tend to be compounded over time).
>
Compilers are not getting faster, but CPU's are getting faster. If I look=
=20
at some code that is using boost libraries (functions, signals etc.) the=20
amount of functions and compile times are scary. Looking a bit deeper into=
=20
the code one can realize that the reason of this slowdown is due to the=20
template "hacks".
I studied myself a bit in depth the clang compiler. Clang family of tools=
=20
is very great, but discovered recently a serious weekness in compound=20
templates. Compound templates just do not scale with clang. Take something=
=20
like map<map<string, string>, map<string, string> > recursively. Gcc=20
template expansion time is linear, where with clang is exponential with the=
=20
level of composition. Did not dig very deep, but I am affraid thea=20
There=E2=80=99s ongoing work to improve header caching. The troublesome =E2=
=80=9Cbackwards=20
> compatibility=E2=80=9D is mainly the specter of macro name collisions wit=
h library=20
> identifiers. On one hand, the Modules extension proposes new rules to=20
> eliminate this by replacing #include headers with something else. On the=
=20
> other hand, it would be nice simply to have existing headers (and templat=
e=20
> instantiations) be cached, with diagnoses when macro collisions (or=20
> whatever) defeat the cache. In the big picture, the backwards-compatible=
=20
> feature would have been nicer, but the community got tired of waiting for=
=20
> it. (See also: export templates.)
>
Played with the idea of header caching with clang, but in several cases=20
does not help too much. There is for instance no way to force template=20
instantiation caching.
But, sorry, my point is neither about compiler performance, nor about AST=
=20
manipulation, nor about header caching. It is about some language=20
extensions that would allow pasting code at compile time based on compiler=
=20
knowledge.
=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_3218_1024689050.1422873023663
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div>Please take your own advice. The archives of th=
is mailing list are searchable on <a href=3D"http://groups.google.com" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://groups.go=
ogle.com';return true;" onclick=3D"this.href=3D'http://groups.google.com';r=
eturn true;">groups.google.com</a>. AST manipulations have been suggested b=
efore, and the idea is always half-baked.</div></div></blockquote><div><br>=
</div><div>Thanks for pointing me to archives. I prefer then to remove the =
word AST manipulation from the ideas I am playing with. I will instead come=
back to code pasting, or compile time macros. The emphasis is on pasting c=
ode. So not really AST manipulation. One would think about changing the AST=
once it is built. No. It is about pasting code exactly as templates are pa=
sting code. Is templating considered AST manipulation? Well... yes and no..=
.. but you got the point.</div><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"><div><blockquote type=3D"cite"><div>Als=
o c++ compiler is becoming very very slow because the language tried to be =
backward compatible etc.</div></blockquote></div><div><span style=3D"float:=
none;display:inline!important">The compilers are getting faster (as are the=
CPUs executing them). Any slowdown you see is a result of bloat, as librar=
y headers get bigger (often due to their own legacies) and templates get de=
eper (<i>not</i> a legacy issue, but this does tend to be compounded o=
ver time).</span></div></div></blockquote><div><br></div><div>Compilers are=
not getting faster, but CPU's are getting faster. If I look at some code t=
hat is using boost libraries (functions, signals etc.) the amount of functi=
ons and compile times are scary. Looking a bit deeper into the code one can=
realize that the reason of this slowdown is due to the template "hacks".</=
div><div>I studied myself a bit in depth the clang compiler. Clang fa=
mily of tools is very great, but discovered recently a serious weekness in =
compound templates. Compound templates just do not scale with clang. Take s=
omething like map<map<string, string>, map<string, string=
> > recursively. Gcc template expansion time is linear, where with cl=
ang is exponential with the level of composition. Did not dig very deep, bu=
t I am affraid thea <br></div><div><br></div><div><br></div><blockquot=
e 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=
>There=E2=80=99s ongoing work to improve header caching. The troublesome =
=E2=80=9Cbackwards compatibility=E2=80=9D is mainly the specter of macro na=
me collisions with library identifiers. On one hand, the Modules extension =
proposes new rules to eliminate this by replacing <font face=3D"Courier">#i=
nclude</font> headers with something else. On the other hand, it would=
be nice simply to have existing headers (and template instantiations) be c=
ached, with diagnoses when macro collisions (or whatever) defeat the cache.=
In the big picture, the backwards-compatible feature would have been nicer=
, but the community got tired of waiting for it. (See also: <font face=3D"C=
ourier">export</font> templates.)<br></div></div></blockquote><div>Played w=
ith the idea of header caching with clang, but in several cases does not he=
lp too much. There is for instance no way to force template instantiation c=
aching.</div><div><br></div><div>But, sorry, my point is neither about comp=
iler performance, nor about AST manipulation, nor about header caching. &nb=
sp;It is about some language extensions that would allow pasting code at co=
mpile time based on compiler knowledge.</div><div><br></div><div> </di=
v></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_3218_1024689050.1422873023663--
------=_Part_3217_873901669.1422873023663--
.