Topic: Improving compile times for non-template
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 23 Jan 2019 19:11:49 +0300
Raw View
On 1/23/19 6:58 PM, p groarke wrote:
> I'll take a wild guess this has already been asked, thought-of or=20
> written about, but lets ask anyways. I'm curious why one cannot write=20
> the implementation of non-template dependent member function in a=20
> compile unit, in the hopes of improving compile times.
>=20
> For example :
>=20
> .h
>=20
> |
> template<classT>
> structtest {
> intval()const;
>=20
> private:
> intval {42};
> =C2=A0 =C2=A0 T t;
> };
> |
>=20
>=20
> .cpp
>=20
> |
> // I do not depend on T, can implement in compile unit.
> // Declaration semantics unimportant.
> inttest::val()const{
> returnval;
> }
> |
>=20
>=20
> I remember a cppcon talk from Ubisoft, where they bypass this issue by=20
> inheriting a base class with non-template dependent behavior implemented=
=20
> in their compile unit. Template dependent behavior is implemented in the=
=20
> header of the derived class.
> Why not offer this compilation behavior out-of-the-box?
I assume, the main reason is that because the method is not instantiated=20
until it is ODR-used (e.g. called). This is a useful property, which, in=20
fact, may improve compile times if the method body causes a lot of other=20
template instantiations or expensive code generation.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a97e361c-772e-6fb5-5ca8-d72250f45541%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 23 Jan 2019 08:20:34 -0800
Raw View
On Wednesday, 23 January 2019 07:58:54 PST p groarke wrote:
> template <class T>
> struct test {
> int val() const;
>
> private:
> int val_ { 42 };
> T t;
> };
Explain how, given the above, the compiler can decide whether test::val()
depends on T or not.
Remember: this is all the compiler sees when compiling other translation units
that include this header.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/7140056.skhr9ZE8Xc%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 23 Jan 2019 19:30:21 +0300
Raw View
On 1/23/19 7:20 PM, Thiago Macieira wrote:
> On Wednesday, 23 January 2019 07:58:54 PST p groarke wrote:
>> template <class T>
>> struct test {
>> int val() const;
>>
>> private:
>> int val_ { 42 };
>> T t;
>> };
>
> Explain how, given the above, the compiler can decide whether test::val()
> depends on T or not.
>
> Remember: this is all the compiler sees when compiling other translation units
> that include this header.
It doesn't need to know that. When val() is ODR-used, the compiler will
simply leave a reference to the val symbol to be resolved by the linker.
The question is really whether the compiler that sees the implementation
of val() should emit its compiled body. Currently it doesn't, presumably
due to the reason I described in my reply.
--
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/511c9222-ae06-222e-4f1b-c4843b5f83fe%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 23 Jan 2019 19:34:31 +0300
Raw View
On 1/23/19 7:11 PM, Andrey Semashev wrote:
> On 1/23/19 6:58 PM, p groarke wrote:
>> I'll take a wild guess this has already been asked, thought-of or=20
>> written about, but lets ask anyways. I'm curious why one cannot write=20
>> the implementation of non-template dependent member function in a=20
>> compile unit, in the hopes of improving compile times.
>>
>> For example :
>>
>> .h
>>
>> |
>> template<classT>
>> structtest {
>> intval()const;
>>
>> private:
>> intval {42};
>> =C2=A0=C2=A0 =C2=A0 T t;
>> };
>> |
>>
>>
>> .cpp
>>
>> |
>> // I do not depend on T, can implement in compile unit.
>> // Declaration semantics unimportant.
>> inttest::val()const{
>> returnval;
>> }
>> |
>>
>>
>> I remember a cppcon talk from Ubisoft, where they bypass this issue by=
=20
>> inheriting a base class with non-template dependent behavior=20
>> implemented in their compile unit. Template dependent behavior is=20
>> implemented in the header of the derived class.
>> Why not offer this compilation behavior out-of-the-box?
>=20
> I assume, the main reason is that because the method is not instantiated=
=20
> until it is ODR-used (e.g. called). This is a useful property, which, in=
=20
> fact, may improve compile times if the method body causes a lot of other=
=20
> template instantiations or expensive code generation.
Also, even if val's body does not depend on template parameters of its=20
class, it is still dependent. test<T>::val are distinct functions for=20
different Ts. There are also template specializations to consider.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f6ad2ae2-079e-3ecd-b40c-3898319a80c4%40gmail.com=
..
.
Author: p groarke <philippe.groarke@gmail.com>
Date: Wed, 23 Jan 2019 08:54:10 -0800 (PST)
Raw View
------=_Part_2849_1044282344.1548262450743
Content-Type: multipart/alternative;
boundary="----=_Part_2850_64177459.1548262450744"
------=_Part_2850_64177459.1548262450744
Content-Type: text/plain; charset="UTF-8"
On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev wrote:
>
> On 1/23/19 7:11 PM, Andrey Semashev wrote:
> > On 1/23/19 6:58 PM, p groarke wrote:
> >> I'll take a wild guess this has already been asked, thought-of or
> >> written about, but lets ask anyways. I'm curious why one cannot write
> >> the implementation of non-template dependent member function in a
> >> compile unit, in the hopes of improving compile times.
> >>
> >> For example :
> >>
> >> .h
> >>
> >> |
> >> template<classT>
> >> structtest {
> >> intval()const;
> >>
> >> private:
> >> intval {42};
> >> T t;
> >> };
> >> |
> >>
> >>
> >> .cpp
> >>
> >> |
> >> // I do not depend on T, can implement in compile unit.
> >> // Declaration semantics unimportant.
> >> inttest::val()const{
> >> returnval;
> >> }
> >> |
> >>
> >>
> >> I remember a cppcon talk from Ubisoft, where they bypass this issue by
> >> inheriting a base class with non-template dependent behavior
> >> implemented in their compile unit. Template dependent behavior is
> >> implemented in the header of the derived class.
> >> Why not offer this compilation behavior out-of-the-box?
> >
> > I assume, the main reason is that because the method is not instantiated
> > until it is ODR-used (e.g. called). This is a useful property, which, in
> > fact, may improve compile times if the method body causes a lot of other
> > template instantiations or expensive code generation.
>
> Also, even if val's body does not depend on template parameters of its
> class, it is still dependent. test<T>::val are distinct functions for
> different Ts. There are also template specializations to consider.
>
Is it though? Couldn't the compiler mark the function as non-dependent on
T, and generate one member function for all test<T>?
--
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/09ae316c-664f-4508-a8a8-5beaf33c6fcf%40isocpp.org.
------=_Part_2850_64177459.1548262450744
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, January 23, 2019 at 11:34:36 AM UTC-=
5, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1/=
23/19 7:11 PM, Andrey Semashev wrote:
<br>> On 1/23/19 6:58 PM, p groarke wrote:
<br>>> I'll take a wild guess this has already been asked, though=
t-of or=20
<br>>> written about, but lets ask anyways. I'm curious why one c=
annot write=20
<br>>> the implementation of non-template dependent member function i=
n a=20
<br>>> compile unit, in the hopes of improving compile times.
<br>>>
<br>>> For example :
<br>>>
<br>>> .h
<br>>>
<br>>> |
<br>>> template<classT>
<br>>> structtest {
<br>>> intval()const;
<br>>>
<br>>> private:
<br>>> intval {42};
<br>>> =C2=A0=C2=A0 =C2=A0 T t;
<br>>> };
<br>>> |
<br>>>
<br>>>
<br>>> .cpp
<br>>>
<br>>> |
<br>>> // I do not depend on T, can implement in compile unit.
<br>>> // Declaration semantics unimportant.
<br>>> inttest::val()const{
<br>>> returnval;
<br>>> }
<br>>> |
<br>>>
<br>>>
<br>>> I remember a cppcon talk from Ubisoft, where they bypass this =
issue by=20
<br>>> inheriting a base class with non-template dependent behavior=
=20
<br>>> implemented in their compile unit. Template dependent behavior=
is=20
<br>>> implemented in the header of the derived class.
<br>>> Why not offer this compilation behavior out-of-the-box?
<br>>=20
<br>> I assume, the main reason is that because the method is not instan=
tiated=20
<br>> until it is ODR-used (e.g. called). This is a useful property, whi=
ch, in=20
<br>> fact, may improve compile times if the method body causes a lot of=
other=20
<br>> template instantiations or expensive code generation.
<br>
<br>Also, even if val's body does not depend on template parameters of =
its=20
<br>class, it is still dependent. test<T>::val are distinct functions=
for=20
<br>different Ts. There are also template specializations to consider.
<br></blockquote><div>=C2=A0</div><div>Is it though? Couldn't the compi=
ler mark the function as non-dependent on T, and generate one member functi=
on for all test<T>?<br></div></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/09ae316c-664f-4508-a8a8-5beaf33c6fcf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09ae316c-664f-4508-a8a8-5beaf33c6fcf=
%40isocpp.org</a>.<br />
------=_Part_2850_64177459.1548262450744--
------=_Part_2849_1044282344.1548262450743--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 23 Jan 2019 19:56:57 +0300
Raw View
On 1/23/19 7:54 PM, p groarke wrote:
>
> On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev wrote:
>
> Also, even if val's body does not depend on template parameters of its
> class, it is still dependent. test<T>::val are distinct functions for
> different Ts. There are also template specializations to consider.
>
> Is it though? Couldn't the compiler mark the function as non-dependent
> on T, and generate one member function for all test<T>?
No.
--
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/feb17ed2-6565-1d67-ec5c-86deb4602854%40gmail.com.
.
Author: p groarke <philippe.groarke@gmail.com>
Date: Wed, 23 Jan 2019 08:58:42 -0800 (PST)
Raw View
------=_Part_2784_275371868.1548262722896
Content-Type: multipart/alternative;
boundary="----=_Part_2785_1665305472.1548262722897"
------=_Part_2785_1665305472.1548262722897
Content-Type: text/plain; charset="UTF-8"
On Wednesday, January 23, 2019 at 11:57:02 AM UTC-5, Andrey Semashev wrote:
>
> On 1/23/19 7:54 PM, p groarke wrote:
> >
> > On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev
> wrote:
> >
> > Also, even if val's body does not depend on template parameters of
> its
> > class, it is still dependent. test<T>::val are distinct functions
> for
> > different Ts. There are also template specializations to consider.
> >
> > Is it though? Couldn't the compiler mark the function as non-dependent
> > on T, and generate one member function for all test<T>?
>
> No.
>
Why not?
--
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/46c9454a-7d31-426d-9031-a8ca4f3d7add%40isocpp.org.
------=_Part_2785_1665305472.1548262722897
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, January 23, 2019 at 11:57:02 AM UTC-=
5, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1/=
23/19 7:54 PM, p groarke wrote:
<br>>=20
<br>> On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semash=
ev wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 Also, even if val's body does not depend on temp=
late parameters of its
<br>> =C2=A0 =C2=A0 class, it is still dependent. test<T>::val are=
distinct functions for
<br>> =C2=A0 =C2=A0 different Ts. There are also template specialization=
s to consider.
<br>>=20
<br>> Is it though? Couldn't the compiler mark the function as non-d=
ependent=20
<br>> on T, and generate one member function for all test<T>?
<br>
<br>No.
<br></blockquote><div><br></div><div>Why not? <br></div></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/46c9454a-7d31-426d-9031-a8ca4f3d7add%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46c9454a-7d31-426d-9031-a8ca4f3d7add=
%40isocpp.org</a>.<br />
------=_Part_2785_1665305472.1548262722897--
------=_Part_2784_275371868.1548262722896--
.
Author: Matthias Gehre <gehre.matthias@gmail.com>
Date: Thu, 24 Jan 2019 19:30:57 +0100
Raw View
--0000000000004495290580386a52
Content-Type: text/plain; charset="UTF-8"
I guess val() could contain static local variables, which would need to be
different objects for each T?
Am Mi., 23. Jan. 2019 um 17:58 Uhr schrieb p groarke <
philippe.groarke@gmail.com>:
>
>
> On Wednesday, January 23, 2019 at 11:57:02 AM UTC-5, Andrey Semashev wrote:
>>
>> On 1/23/19 7:54 PM, p groarke wrote:
>> >
>> > On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev
>> wrote:
>> >
>> > Also, even if val's body does not depend on template parameters of
>> its
>> > class, it is still dependent. test<T>::val are distinct functions
>> for
>> > different Ts. There are also template specializations to consider.
>> >
>> > Is it though? Couldn't the compiler mark the function as non-dependent
>> > on T, and generate one member function for all test<T>?
>>
>> No.
>>
>
> Why not?
>
> --
> 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/46c9454a-7d31-426d-9031-a8ca4f3d7add%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46c9454a-7d31-426d-9031-a8ca4f3d7add%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/CAOCE36VYA0mMJVn5xok0aMmU1ZcQbD%3DO5Y-6kJ%2BxqK3xxDr6Jw%40mail.gmail.com.
--0000000000004495290580386a52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I guess val() could contain static local variables, which =
would need to be different objects for each T?</div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Am Mi., 23. Jan. 2019 um 17:5=
8=C2=A0Uhr schrieb p groarke <<a href=3D"mailto:philippe.groarke@gmail.c=
om">philippe.groarke@gmail.com</a>>:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, January 23, =
2019 at 11:57:02 AM UTC-5, Andrey Semashev wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">On 1/23/19 7:54 PM, p groarke wrote:
<br>>=20
<br>> On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semash=
ev wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 Also, even if val's body does not depend on temp=
late parameters of its
<br>> =C2=A0 =C2=A0 class, it is still dependent. test<T>::val are=
distinct functions for
<br>> =C2=A0 =C2=A0 different Ts. There are also template specialization=
s to consider.
<br>>=20
<br>> Is it though? Couldn't the compiler mark the function as non-d=
ependent=20
<br>> on T, and generate one member function for all test<T>?
<br>
<br>No.
<br></blockquote><div><br></div><div>Why not? <br></div></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" 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" 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/46c9454a-7d31-426d-9031-a8ca4f3d7add%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46c9454a-7d31-=
426d-9031-a8ca4f3d7add%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/CAOCE36VYA0mMJVn5xok0aMmU1ZcQbD%3DO5Y=
-6kJ%2BxqK3xxDr6Jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOCE36VYA0mM=
JVn5xok0aMmU1ZcQbD%3DO5Y-6kJ%2BxqK3xxDr6Jw%40mail.gmail.com</a>.<br />
--0000000000004495290580386a52--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 24 Jan 2019 14:45:01 -0500
Raw View
On 23/01/2019 11.58, p groarke wrote:
> On Wednesday, January 23, 2019 at 11:57:02 AM UTC-5, Andrey Semashev wrote:
>> On 1/23/19 7:54 PM, p groarke wrote:
>>> On Wednesday, January 23, 2019 at 11:34:36 AM UTC-5, Andrey Semashev wrote:
>>>> Also, even if val's body does not depend on template
>>>> parameters of its class, it is still dependent. test<T>::val
>>>> are distinct functions for different Ts. There are also
>>>> template specializations to consider.
>>>
>>> Is it though? Couldn't the compiler mark the function as non-dependent
>>> on T, and generate one member function for all test<T>?
>>
>> No.
>
> Why not?
Ahem. "There are also template specializations to consider."
template <>
test<int>::val() const
{ return -1; }
What *might* be possible would be for the compiler to automatically
generate an implementation of test<T>::val that calls the generic version.
Whether that's useful enough to warrant spending committee time is
another question...
--
Matthew
--
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/cb502204-61cc-d19b-9b1b-dc64df2c79b8%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 24 Jan 2019 15:00:45 -0500
Raw View
On 23/01/2019 11.30, Andrey Semashev wrote:
> On 1/23/19 7:20 PM, Thiago Macieira wrote:
>> On Wednesday, 23 January 2019 07:58:54 PST p groarke wrote:
>>> template <class T>
>>> struct test {
>>> =C2=A0=C2=A0=C2=A0=C2=A0 int val() const;
>>>
>>> private:
>>> =C2=A0=C2=A0=C2=A0=C2=A0 int val_ { 42 };
>>> =C2=A0=C2=A0=C2=A0=C2=A0 T t;
>>> };
>>
>> Explain how, given the above, the compiler can decide whether test::val(=
)
>> depends on T or not.
>>
>> Remember: this is all the compiler sees when compiling other
>> translation units
>> that include this header.
>=20
> It doesn't need to know that. When val() is ODR-used, the compiler will
> simply leave a reference to the val symbol to be resolved by the linker.
Er... that works today (since C++98 even). It requires explicit template
instantiation, though.
You would need a way to tell the compiler a) to assume that val() will
not be dependent, and b) that a definition is non-dependent.
> The question is really whether the compiler that sees the implementation
> of val() should emit its compiled body. Currently it doesn't, presumably
> due to the reason I described in my reply.
The point (b) above would take care of this.
It might look something like:
// .h
template <class T>
struct test {
int val() const =3D template<...>;
//...
};
// .cpp
template <>
test<...>::val() const // non-dependent specialization
{ ... }
The `=3D template<...>` tells the compiler that, if it hasn't seen
otherwise (e.g. a specialization), calls to test<T>::val should be
replaced with calls to the non-type-dependent symbol test<...>::val
(which is also declared by the same syntax). The latter syntax for
defining said symbol will of course always generate code. Note,
additionally, that the template parameter is unavailable in the
definition of this member, so anything that would depend on it
(including class statics, I suppose) is an error.
(Straw syntax, of course...)
--=20
Matthew
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9c7f6fed-17c2-cd06-1b86-b2a64d12437e%40gmail.com=
..
.