Topic: add the metafunction scope
Author: liweifriends@gmail.com
Date: Thu, 29 Mar 2018 19:01:03 -0700 (PDT)
Raw View
------=_Part_4691_154450286.1522375263801
Content-Type: multipart/alternative;
boundary="----=_Part_4692_651785234.1522375263801"
------=_Part_4692_651785234.1522375263801
Content-Type: text/plain; charset="UTF-8"
In C++, We can introduce a scope to control the life-time of a runtime
variable. When the scrope is end, the variable inside the scope will be
removed to save the memory. For example:
{
int a = ...
shared_ptr<int> b = new int()
}
When running at the end of the scope, a and b will be removed from the
stack and heap.
But when considering the compile time calculation, currently C++ doesn't
have a similar mechanism to tell the compiler to "free" some useless
information. For example:
template <typename T>
struct RemoveConstReference
{
using tmp = typename std::remove_const<T>::type;
using type = typename std::remove_reference<tmp>::type;
};
using ResType = typename RemoveConstReference<const int&>::type; //
calling compile time calculation, ResType will be int
When calculating ResTypeat compile time, the compiler might generate some
Intermediate information (such as RemoveConstReference<const int&>::tmp).
The compiler might assume this information might be used further and
therefore allocate a memory to store these kind of information.
But in fact, the info such as RemoveConstReference<const int&>::tmp might
never be used anymore. Since it is just a "Intermediate result" of compile
time calculation and is useless after we get the type of ResType.
For a program that heavily depends on compile time calculation, this might
be a serious problem, since the compiler might store a lot of such
"useless" information during compile, this will increase the memory useage
of the compiler and slow down the compile procedure.
To solve this problem, I think we should introduce an "metafunction" scope,
as follows:
metafunction
{
template <typename T>
struct RemoveConstReference
{
using tmp = typename std::remove_const<T>::type;
using type = typename std::remove_reference<tmp>::type;
};
}
using ResType = typename RemoveConstReference<const int&>::type;
the RemoveConstReference is included inside this scope, so after the
calculation of ResType, the compiler might remove all the information
generated inside this scope. This will save the memory of the compiler and
speed up the compile procedure.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e47cc81-4834-4a68-8925-717fb2ec8612%40isocpp.org.
------=_Part_4692_651785234.1522375263801
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In C++, We can introduce a scope to control the life-time =
of a runtime variable. When the scrope is end, the variable inside the scop=
e will be removed to save the memory. For example:<br><br><span style=3D"co=
lor: rgb(255, 153, 0);">{<br>=C2=A0=C2=A0=C2=A0 int a =3D ...<br>=C2=A0=C2=
=A0=C2=A0 shared_ptr<int> b =3D new int()<br>}</span><br><br>When run=
ning at the end of the scope, a and b will be removed from the stack and he=
ap. <br><br>But when considering the compile time calculation, currently C+=
+ doesn't have a similar mechanism to tell the compiler to "free&q=
uot; some useless information. For example:<br><br><span style=3D"color: rg=
b(255, 153, 0);">template <typename T><br>struct RemoveConstReference=
<br>{<br>=C2=A0=C2=A0=C2=A0 using tmp =3D typename std::remove_const<T&g=
t;::type;<br>=C2=A0=C2=A0=C2=A0 using type =3D typename std::remove_referen=
ce<tmp>::type;<br>};<br><br>using ResType =3D typename RemoveConstRef=
erence<const int&>::type;=C2=A0 // calling compile time calculati=
on, ResType will be int</span><br><br>When calculating ResTypeat compile ti=
me, the compiler might generate some Intermediate information (such as Remo=
veConstReference<const int&>::tmp). The compiler might assume thi=
s information might be used further and therefore allocate a memory to stor=
e these kind of information.<br><br>But in fact, the info such as RemoveCon=
stReference<const int&>::tmp might never be used anymore. Since i=
t is just a "Intermediate result" of compile time calculation and=
is useless after we get the type of <span style=3D"color: rgb(255, 153, 0)=
;">ResType.<br><span style=3D"color: rgb(0, 0, 0);"><br>For a program that =
heavily depends on compile time calculation, this might be a serious proble=
m, since the compiler might store a lot of such "useless" informa=
tion during compile, this will increase the memory useage of the compiler a=
nd slow down the compile procedure.<br><br>To solve this problem, I think w=
e should introduce an "metafunction" scope, as follows:<br><br><s=
pan style=3D"color: rgb(255, 0, 0);">metafunction<br>{<br></span></span></s=
pan><span style=3D"color: rgb(255, 153, 0);">template <typename T><br=
>struct RemoveConstReference<br>{<br>=C2=A0=C2=A0=C2=A0 using tmp =3D typen=
ame std::remove_const<T>::type;<br>=C2=A0=C2=A0=C2=A0 using type =3D =
typename std::remove_reference<tmp>::type;<br>};<br><span style=3D"co=
lor: rgb(255, 0, 0);">}</span><br><br>using
ResType =3D typename RemoveConstReference<const int&>::type;<br>=
<span style=3D"color: rgb(0, 0, 0);"><br>the RemoveConstReference is includ=
ed inside this scope, so after the calculation of ResType, the compiler mig=
ht remove all the information generated inside this scope. This will save t=
he memory of the compiler and speed up the compile procedure.</span><br></s=
pan><span style=3D"color: rgb(255, 153, 0);"><span style=3D"color: rgb(0, 0=
, 0);"></span> </span></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e47cc81-4834-4a68-8925-717fb2ec8612%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e47cc81-4834-4a68-8925-717fb2ec8612=
%40isocpp.org</a>.<br />
------=_Part_4692_651785234.1522375263801--
------=_Part_4691_154450286.1522375263801--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 30 Mar 2018 07:47:57 +0200
Raw View
On Thu, Mar 29, 2018 at 07:01:03PM -0700, liweifriends@gmail.com wrote:
>
> For a program that heavily depends on compile time calculation, this might
> be a serious problem, since the compiler might store a lot of such
> "useless" information during compile, this will increase the memory useage
> of the compiler and slow down the compile procedure.
>
> To solve this problem, I think we should introduce an "metafunction" scope,
> as follows:
>
> metafunction
> {
> template <typename T>
> struct RemoveConstReference
> {
> using tmp = typename std::remove_const<T>::type;
> using type = typename std::remove_reference<tmp>::type;
> };
> }
>
> using ResType = typename RemoveConstReference<const int&>::type;
Your example does not make any sense.
Ain't RemoveConstReference out of scope at the point of "using ResType"?
> the RemoveConstReference is included inside this scope, so after the
> calculation of ResType, the compiler might remove all the information
> generated inside this scope. This will save the memory of the compiler and
> speed up the compile procedure.
If, on the other hand you put "using ResType" before the closing brace of
the metafunction clause then ResType would become undefined right after it's
definition and that also is unusable.
As a final thoght this sounds a lot like a namespace with an unutterable name,
how does your metafunction compare to a namespace?
/MF
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180330054757.GA2396%40noemi.
.
Author: =?UTF-8?B?5p2O5Lyf?= <liweifriends@gmail.com>
Date: Fri, 30 Mar 2018 14:07:38 +0800
Raw View
--94eb2c033e44a84c5f05689b0e85
Content-Type: text/plain; charset="UTF-8"
Hi Magnus:
Thanks for your response. I'd like to explain about your points:
1. Ain't RemoveConstReference out of scope at the point of "using ResType"?
For the oroginal code, after calculating the type of ResType, the compiler
keeps the information of RemoveConstReference<const int&>::tmp and
RemoveConstReference<const
int&>::type. They are useless any more. The metafunction scope just tells
the compiler to remove RemoveConstReference<const int&>::tmp and
RemoveConstReference<const
int&>::type (for example, from its symbol table) during compile time.
2. If, on the other hand you put "using ResType" before the closing brace
of the metafunction clause then ResType would become undefined right after
it's definition and that also is unusable.
For the most of time, we doing a compile time calculation, we just want to
calculate some type/value results for further usage. Therefore, the common
usage of metafunction is as follows:
metafunction {...}
Caller of metafunction, such as "using ResType" in the above code
The caller must located out of the metafunction scope, otherwise it might
be removed after the compile time calculation.
3. As a final thoght this sounds a lot like a namespace with an unutterable
name, how does your metafunction compare to a namespace?
It is definitely not a namespace. If we write the code as follows:
namespace {
template <typename T>
struct RemoveConstReference
{
using tmp = typename std::remove_const<T>::type;
using type = typename std::remove_reference<tmp>::type;
};
}
using ResType = typename RemoveConstReference<const int&>::type;
During compile time, the compiler would still maintain the information
about [namespace]::RemoveConstReference<const int&>::tmp and [namespace]::
RemoveConstReference<const int&>::type even after it finishes the
calculation of ResType, which might be a waste of a compile time memory.
Thanks
Wei
2018-03-30 13:47 GMT+08:00 Magnus Fromreide <magfr@lysator.liu.se>:
> On Thu, Mar 29, 2018 at 07:01:03PM -0700, liweifriends@gmail.com wrote:
> >
> > For a program that heavily depends on compile time calculation, this
> might
> > be a serious problem, since the compiler might store a lot of such
> > "useless" information during compile, this will increase the memory
> useage
> > of the compiler and slow down the compile procedure.
> >
> > To solve this problem, I think we should introduce an "metafunction"
> scope,
> > as follows:
> >
> > metafunction
> > {
> > template <typename T>
> > struct RemoveConstReference
> > {
> > using tmp = typename std::remove_const<T>::type;
> > using type = typename std::remove_reference<tmp>::type;
> > };
> > }
> >
> > using ResType = typename RemoveConstReference<const int&>::type;
>
> Your example does not make any sense.
>
> Ain't RemoveConstReference out of scope at the point of "using ResType"?
>
> > the RemoveConstReference is included inside this scope, so after the
> > calculation of ResType, the compiler might remove all the information
> > generated inside this scope. This will save the memory of the compiler
> and
> > speed up the compile procedure.
>
> If, on the other hand you put "using ResType" before the closing brace of
> the metafunction clause then ResType would become undefined right after
> it's
> definition and that also is unusable.
>
> As a final thoght this sounds a lot like a namespace with an unutterable
> name,
> how does your metafunction compare to a namespace?
>
> /MF
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/20180330054757.GA2396%40noemi.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANNXMwZMCpDOHj-e_mEmWQ37QEtmT_%2Bto8oyDHUkiUjrpC4NFA%40mail.gmail.com.
--94eb2c033e44a84c5f05689b0e85
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Hi Magnus:<br><br></div>Thanks for your response=
.. I'd like to explain about your points:<br><br>1.=20
Ain't RemoveConstReference out of scope at the point of "using Res=
Type"?
<br><br></div><div>For the oroginal code, after calculating the type of=20
<span class=3D"gmail-im">ResType, the compiler keeps the information of=20
<span class=3D"gmail-im"> RemoveConstReference<const int&></span>=
::tmp and </span>
<span class=3D"gmail-im"><span class=3D"gmail-im">RemoveConstReference<c=
onst int&></span>::type. They are useless any more. The metafunction=
scope just tells the compiler to remove=20
<span class=3D"gmail-im"><span class=3D"gmail-im">RemoveConstReference<c=
onst int&></span>::tmp</span>
and=20
<span class=3D"gmail-im"><span class=3D"gmail-im">RemoveConstReference<c=
onst int&></span>::type</span>
(for example, from its symbol table) during compile time. </span><br><br>2.=
=20
If, on the other hand you put "using ResType" before the closing =
brace of=C2=A0
the metafunction clause then ResType would become undefined right after it&=
#39;s definition and that also is unusable.
<br></div><div>For the most of time, we doing a compile time calculation, w=
e just want to calculate some type/value results for further usage. Therefo=
re, the common usage of=20
<span class=3D"gmail-im">metafunction</span> is as follows:<br><br>
<span class=3D"gmail-im">metafunction</span>
{...}<br></div><div>Caller of metafunction, such as=20
<span class=3D"gmail-im"> "using ResType</span>" in the above cod=
e<br><br></div><div>The caller must located out of the metafunction scope, =
otherwise it might be removed after the compile time calculation. <br><br>3=
..=20
As a final thoght this sounds a lot like a namespace with an unutterable na=
me, how does your metafunction compare to a namespace?
<br></div><div>It is definitely not a namespace. If we write the code as fo=
llows:<br>
<span class=3D"gmail-im">namespace {<br>=C2=A0=C2=A0 template <typename =
T><br>=C2=A0=C2=A0 struct RemoveConstReference<br>=C2=A0=C2=A0 {<br>=C2=
=A0=C2=A0 =C2=A0=C2=A0 using tmp =3D typename std::remove_const<T>::t=
ype;<br>
=C2=A0=C2=A0 =C2=A0=C2=A0 using type =3D typename std::remove_reference<=
tmp>::<wbr>type;<br>=C2=A0=C2=A0 };<br>}<br><br>using ResType =3D typena=
me RemoveConstReference<const int&>::type;</span>
<br><br></div><div>During compile time, the compiler would still maintain t=
he information about [namespace]::<span class=3D"gmail-im">RemoveConstRefer=
ence</span><<span class=3D"gmail-im"><span class=3D"gmail-im">const int&=
amp;</span></span>>::tmp and=20
[namespace]::<span class=3D"gmail-im">RemoveConstReference</span><<span =
class=3D"gmail-im"><span class=3D"gmail-im">const int&</span></span>>=
;::type even after it finishes the calculation of=20
<span class=3D"gmail-im">ResType, which might be a waste of a compile time =
memory.<br><br></span></div><div><span class=3D"gmail-im">Thanks<br><br></s=
pan></div><div><span class=3D"gmail-im">Wei<br></span></div><div><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2018-03-30 =
13:47 GMT+08:00 Magnus Fromreide <span dir=3D"ltr"><<a href=3D"mailto:ma=
gfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, Mar 29, 2018 at =
07:01:03PM -0700, <a href=3D"mailto:liweifriends@gmail.com">liweifriends@gm=
ail.com</a> wrote:<br>
><br>
> For a program that heavily depends on compile time calculation, this m=
ight<br>
> be a serious problem, since the compiler might store a lot of such<br>
> "useless" information during compile, this will increase the=
memory useage<br>
> of the compiler and slow down the compile procedure.<br>
><br>
> To solve this problem, I think we should introduce an "metafuncti=
on" scope,<br>
> as follows:<br>
><br>
> metafunction<br>
> {<br>
> template <typename T><br>
> struct RemoveConstReference<br>
> {<br>
>=C2=A0 =C2=A0 =C2=A0using tmp =3D typename std::remove_const<T>::=
type;<br>
>=C2=A0 =C2=A0 =C2=A0using type =3D typename std::remove_reference<tm=
p>::<wbr>type;<br>
> };<br>
> }<br>
><br>
> using ResType =3D typename RemoveConstReference<const int&>:=
:type;<br>
<br>
</span>Your example does not make any sense.<br>
<br>
Ain't RemoveConstReference out of scope at the point of "using Res=
Type"?<br>
<span class=3D""><br>
> the RemoveConstReference is included inside this scope, so after the<b=
r>
> calculation of ResType, the compiler might remove all the information<=
br>
> generated inside this scope. This will save the memory of the compiler=
and<br>
> speed up the compile procedure.<br>
<br>
</span>If, on the other hand you put "using ResType" before the c=
losing brace of<br>
the metafunction clause then ResType would become undefined right after it&=
#39;s<br>
definition and that also is unusable.<br>
<br>
As a final thoght this sounds a lot like a namespace with an unutterable na=
me,<br>
how does your metafunction compare to a namespace?<br>
<br>
/MF<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/20180330054757.GA2396%40noemi"=
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/20180330054757.<wbr>GA2396%40noemi</a>.<b=
r>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANNXMwZMCpDOHj-e_mEmWQ37QEtmT_%2Bto8=
oyDHUkiUjrpC4NFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANNXMwZMCpDOHj=
-e_mEmWQ37QEtmT_%2Bto8oyDHUkiUjrpC4NFA%40mail.gmail.com</a>.<br />
--94eb2c033e44a84c5f05689b0e85--
.
Author: liweifriends@gmail.com
Date: Fri, 30 Mar 2018 00:55:13 -0700 (PDT)
Raw View
------=_Part_5392_488472535.1522396513226
Content-Type: multipart/alternative;
boundary="----=_Part_5393_367966847.1522396513226"
------=_Part_5393_367966847.1522396513226
Content-Type: text/plain; charset="UTF-8"
Testing...
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%40isocpp.org.
------=_Part_5393_367966847.1522396513226
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Testing...<br>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96=
%40isocpp.org</a>.<br />
------=_Part_5393_367966847.1522396513226--
------=_Part_5392_488472535.1522396513226--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Sun, 01 Apr 2018 22:58:57 +0000
Raw View
--000000000000baf6ff0568d16b13
Content-Type: text/plain; charset="UTF-8"
I'm not an experienced compiler writer but wouldn't that actually be a
performance pessimization? Because now the compiler has to delete objects
instead of just keeping them around, or is the cost of finding
instantiations more expensive?
Do you have an implementation? I really think that you'll need actual
measurements to make this work, as it's not trivial: Keeping instantiations
around is a completely implementation defined thing not even mentioned by
the standard at any point AFAIK.
On Fri, Mar 30, 2018, 4:55 PM <liweifriends@gmail.com> wrote:
> Testing...
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1zuF95AfUZ9Mx23af%2BEFk-XaR7TwR01pc0tS_akgfeew%40mail.gmail.com.
--000000000000baf6ff0568d16b13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I'm not an experienced compiler writer but wouldn'=
;t that actually be a performance pessimization? Because now the compiler h=
as to delete objects instead of just keeping them around, or is the cost of=
finding instantiations more expensive?<div dir=3D"auto"><br></div><div dir=
=3D"auto">Do you have an implementation? I really think that you'll nee=
d actual measurements to make this work, as it's not trivial: Keeping i=
nstantiations around is a completely implementation defined thing not even =
mentioned by the standard at any point AFAIK.</div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr">On Fri, Mar 30, 2018, 4:55 PM <<a href=3D=
"mailto:liweifriends@gmail.com" target=3D"_blank" rel=3D"noreferrer">liweif=
riends@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tes=
ting...<br>
<p></p>
-- <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" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</=
a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/b8de3daf-019d-40e2-a039-082ca9c61c96%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1zuF95AfUZ9Mx23af%2BEFk-XaR7Tw=
R01pc0tS_akgfeew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1zuF95Af=
UZ9Mx23af%2BEFk-XaR7TwR01pc0tS_akgfeew%40mail.gmail.com</a>.<br />
--000000000000baf6ff0568d16b13--
.