Topic: Frameless functions (force inline)
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Mon, 19 Dec 2016 23:36:57 -0800 (PST)
Raw View
------=_Part_1341_462713676.1482219417185
Content-Type: multipart/alternative;
boundary="----=_Part_1342_690420060.1482219417185"
------=_Part_1342_690420060.1482219417185
Content-Type: text/plain; charset=UTF-8
MARK: moving post from std-discussions
Question:
Hi.
The problem I would like to address, which has got no solution on language
level is programmer not being able to force function to be inlined.
I am completely fine with the fact, that compiler can decide, whether it's
optimal to make function inlined or not and do so appropriately, so that
inline is just a hint for the compiler.
On the other hand there are situations, when you need to have a control
over the call stack. Especially when playing with std::longjmp and
std::setjmp for example
to implement co-routines (this case however has already been addressed), so
that one can create await() function (it's just an example).
Solution would seem, to use compiler options to force inline functions, but
then gcc rejects any function, that is to be force inlined, when using
std::setjmp in it.
This would seem to be a rare case, when one will have to use force inline.
It also creates a risk, that people will start using force inline instead
of simple inline to make
"optimizations" therefore discarding compiler wisdom.
Has this problem been addressed? Do you think it would be usefull?
--
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/146727c3-d49d-480d-950f-76a8104b5220%40isocpp.org.
------=_Part_1342_690420060.1482219417185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">MARK: moving post from std-discussions<br><br>Question:<br=
>Hi.<br><br>The problem I would like to address, which has got no=20
solution on language level is programmer not being able to force=20
function to be inlined.<br><br>I am completely fine with the fact, that=20
compiler can decide, whether it's optimal to make function inlined or=
=20
not and do so appropriately, so that<br>inline is just a hint for the compi=
ler.<br><br>On
the other hand there are situations, when you need to have a control=20
over the call stack. Especially when playing with std::longjmp and=20
std::setjmp for example<br> to implement co-routines (this case however=20
has already been addressed), so that one can create await() function=20
(it's just an example).<br><br>Solution would seem, to use compiler=20
options to force inline functions, but then gcc rejects any function,=20
that is to be force inlined, when using std::setjmp in it.<br><br>This=20
would seem to be a rare case, when one will have to use force inline. It
also creates a risk, that people will start using force inline instead=20
of simple inline to make<br>"optimizations" therefore discarding =
compiler wisdom.<br><br>Has this problem been addressed? Do you think it wo=
uld be usefull?<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/146727c3-d49d-480d-950f-76a8104b5220%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-76a8104b5220=
%40isocpp.org</a>.<br />
------=_Part_1342_690420060.1482219417185--
------=_Part_1341_462713676.1482219417185--
.
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Tue, 20 Dec 2016 08:42:39 +0100
Raw View
--001a1130d2ea420f190544122ef0
Content-Type: text/plain; charset=UTF-8
MARK: moved from std-discussion
answer: from charleyb123
Agree that it could be useful to have more information on controlling
'inline' (since it's currently just a "suggestion"), and would be nice to
have better mechanism to "know" if a given function was *actually* inlined
(after it was requested to be inlined).
There does seem to be a tricky contrast with ODR, where actually-inlined
code (by definition) is defined multiple times. Today's compilers seem to
do a really good job with that tradeoff.
For highly performance-sensitive code where I've needed to "force" an
inline, below is an example where the *function-address* is the
template-parameter, which must be expanded by the compiler at template
instantiation, thereby "forcing" the function call to be "inline".
(This example is C++98, I much prefer the 'using' style of C++11.)
-charley
-----
// FILE: test4.cpp
#include <cassert>
#include <iostream>
// EXAMPLE: Force "inline" of function-pointer by parameterizing
// through template-function
// SHOWS: Compiler-forced inlining (through function-template
instantiation)
// REQUIRES: C++98
// NOTES:
// *- Function-template cannot be instantiated without
parameterized
// function-address, so compiler "sees" address and
function-pointer
// will be executed directly (without runtime
double-indirection)
//
//----------------
//----------------
typedef int(*PFunc)(std::string s, float f);
// TRICK: Function-pointer is template-argument (needed at compile
// to instantiate function)
template<PFunc pfunc>
int doCall(std::string s, float f) {
assert(pfunc != nullptr);
return (*pfunc)(s, f);
}
//----------------
//----------------
int MyProduct(std::string s, float f)
{
int i = s.c_str() ? atoi(s.c_str()) : 0;
return static_cast<int>(f * i);
}
int MySum(std::string s, float f)
{
int i = s.c_str() ? atoi(s.c_str()) : 0;
return static_cast<int>(f + i);
}
//----------------
//----------------
#if __cplusplus > 199711L
// C++11
int (&doCall_product)(std::string s, float f) = doCall<&MyProduct>;
int (&doCall_sum)(std::string s, float f) = doCall<&MySum>;
#endif
//----------------
//----------------
int main(void)
{
std::cout << "Hello, World!" << std::endl;
std::cout << doCall<&MyProduct>("40", 2) << std::endl;
std::cout << doCall<&MySum>("40", 2) << std::endl;
#if __cplusplus > 199711L
// C++11
std::cout << doCall_product("40", 2) << std::endl;
std::cout << doCall_sum("40", 2) << std::endl;
#endif
PFunc my_pfunc;
my_pfunc = &doCall<MyProduct>;
std::cout << (*my_pfunc)("40", 2) << std::endl;
my_pfunc = &doCall<MySum>;
std::cout << (*my_pfunc)("40", 2) << std::endl;
return 0;
}
//Output:
// |--------------------
// |Hello, World!
// |80
// |42
// |80
// |42
// |80
// |42
// |--------------------
2016-12-20 8:36 GMT+01:00 Dawid Pilarski <dawidpicpp@gmail.com>:
> MARK: moving post from std-discussions
>
> Question:
> Hi.
>
> The problem I would like to address, which has got no solution on language
> level is programmer not being able to force function to be inlined.
>
> I am completely fine with the fact, that compiler can decide, whether it's
> optimal to make function inlined or not and do so appropriately, so that
> inline is just a hint for the compiler.
>
> On the other hand there are situations, when you need to have a control
> over the call stack. Especially when playing with std::longjmp and
> std::setjmp for example
> to implement co-routines (this case however has already been addressed),
> so that one can create await() function (it's just an example).
>
> Solution would seem, to use compiler options to force inline functions,
> but then gcc rejects any function, that is to be force inlined, when using
> std::setjmp in it.
>
> This would seem to be a rare case, when one will have to use force inline.
> It also creates a risk, that people will start using force inline instead
> of simple inline to make
> "optimizations" therefore discarding compiler wisdom.
>
> Has this problem been addressed? Do you think it would be usefull?
>
> --
> 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/146727c3-d49d-480d-
> 950f-76a8104b5220%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-76a8104b5220%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/CAOkZZiH8Y8W0Sju8S0iK84%3D%2BmJ571OnQtFMQ4%2B20oU1FbiGMdA%40mail.gmail.com.
--001a1130d2ea420f190544122ef0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>MARK: moved from std-discussion<br></div>answer: from=
charleyb123<br><br>Agree that it could be useful to have more
information on controlling 'inline' (since it's currently just=
a=20
"suggestion"), and would be nice to have better mechanism to &quo=
t;know" if a
given function was *actually* inlined (after it was requested to be=20
inlined).<div><br></div><div>There does seem to be a tricky contrast=20
with ODR, where actually-inlined code (by definition) is defined=20
multiple times.=C2=A0 Today's compilers seem to do a really good job wi=
th=20
that tradeoff.</div><div><br></div><div>For highly performance-sensitive
code where I've needed to "force" an inline, below is an exa=
mple where=20
the *function-address* is the template-parameter, which must be expanded
by the compiler at template instantiation, thereby "forcing" the=
=20
function call to be "inline".</div><div><br></div><div>(This exam=
ple is C++98, I much prefer the 'using' style of C++11.)</div><div>=
<br></div><div>-charley</div><div><br></div><div>-----</div><br><div>// FIL=
E: test4.cpp</div><div><br></div><div>#include <cassert></div><div>#i=
nclude <iostream></div><div><br></div><div><br></div><div>// =C2=A0EX=
AMPLE: =C2=A0Force "inline" of function-pointer by parameterizing=
</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0through template-fun=
ction</div><div>// =C2=A0 =C2=A0SHOWS: =C2=A0Compiler-forced inlining (thro=
ugh function-template instantiation)</div><div>// REQUIRES: =C2=A0C++98</di=
v><div>// =C2=A0 =C2=A0NOTES:</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0*- Function-template cannot be instantiated without parameterized=
</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 function-add=
ress, so compiler "sees" address and function-pointer</div><div>/=
/ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will be executed directl=
y (without runtime double-indirection)</div><div>//</div><div>//-----------=
-----</div><div>//----------------</div><div><br></div><div>typedef int(*PF=
unc)(std::string s, float f);</div><div><br></div><div>// TRICK: Function-p=
ointer is template-argument (needed at compile</div><div>// to instantiate =
function)</div><div>template<PFunc pfunc></div><div>int doCall(std::s=
tring s, float f) {</div><div>=C2=A0 assert(pfunc !=3D nullptr);</div><div>=
=C2=A0 return (*pfunc)(s, f);</div><div>}</div><div><br></div><div>//------=
----------</div><div>//----------------</div><div>int MyProduct(std::string=
s, float f)</div><div>{</div><div>=C2=A0 int i =3D s.c_str() ? atoi(s.c_st=
r()) : 0;</div><div>=C2=A0 return static_cast<int>(f * i);</div><div>=
}</div><div>int MySum(std::string s, float f)</div><div>{</div><div>=C2=A0 =
int i =3D s.c_str() ? atoi(s.c_str()) : 0;</div><div>=C2=A0 return static_c=
ast<int>(f + i);</div><div>}</div><div><br></div><div>//-------------=
---</div><div>//----------------</div><div><br></div><div>#if __cplusplus &=
gt; 199711L</div><div>=C2=A0 // C++11</div><div>=C2=A0 int (&doCall_pro=
duct)(std::string s, float f) =3D doCall<&MyProduct>;</div><div>=
=C2=A0 int (&doCall_sum)(std::string s, float f) =C2=A0 =C2=A0 =3D doCa=
ll<&MySum>;</div><div>#endif</div><div><br></div><div>//---------=
-------</div><div>//----------------</div><div>int main(void)</div><div>{</=
div><div>=C2=A0 std::cout << "Hello, World!" << std::=
endl;</div><div><br></div><div>=C2=A0 std::cout << doCall<&MyP=
roduct>("40", 2) << std::endl;</div><div>=C2=A0 std::cou=
t << doCall<&MySum>("40", 2) << std::endl;<=
/div><div><br></div><div>#if __cplusplus > 199711L</div><div>=C2=A0 // C=
++11</div><div>=C2=A0 std::cout << doCall_product("40", 2) =
<< std::endl;</div><div>=C2=A0 std::cout << doCall_sum("40=
", 2) << std::endl;</div><div>#endif</div><div><br></div><div>=
=C2=A0 PFunc my_pfunc;</div><div><br></div><div>=C2=A0 my_pfunc =3D &do=
Call<MyProduct>;</div><div>=C2=A0 std::cout << (*my_pfunc)(&quo=
t;40", 2) << std::endl;</div><div><br></div><div>=C2=A0 my_pfunc=
=3D &doCall<MySum>;</div><div>=C2=A0 std::cout << (*my_pfu=
nc)("40", 2) << std::endl;</div><div><br></div><div>=C2=A0 =
return 0;</div><div>}</div><div><br></div><div>//Output:</div><div>// =C2=
=A0|--------------------</div><div>// =C2=A0|Hello, World!</div><div>// =C2=
=A0|80</div><div>// =C2=A0|42</div><div>// =C2=A0|80</div><div>// =C2=A0|42=
</div><div>// =C2=A0|80</div><div>// =C2=A0|42</div><div>// =C2=A0|--------=
------------</div><br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2016-12-20 8:36 GMT+01:00 Dawid Pilarski <span dir=3D"ltr"><<=
a href=3D"mailto:dawidpicpp@gmail.com" target=3D"_blank">dawidpicpp@gmail.c=
om</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">MARK:=
moving post from std-discussions<br><br>Question:<br>Hi.<br><br>The proble=
m I would like to address, which has got no=20
solution on language level is programmer not being able to force=20
function to be inlined.<br><br>I am completely fine with the fact, that=20
compiler can decide, whether it's optimal to make function inlined or=
=20
not and do so appropriately, so that<br>inline is just a hint for the compi=
ler.<br><br>On
the other hand there are situations, when you need to have a control=20
over the call stack. Especially when playing with std::longjmp and=20
std::setjmp for example<br> to implement co-routines (this case however=20
has already been addressed), so that one can create await() function=20
(it's just an example).<br><br>Solution would seem, to use compiler=20
options to force inline functions, but then gcc rejects any function,=20
that is to be force inlined, when using std::setjmp in it.<br><br>This=20
would seem to be a rare case, when one will have to use force inline. It
also creates a risk, that people will start using force inline instead=20
of simple inline to make<br>"optimizations" therefore discarding =
compiler wisdom.<br><br>Has this problem been addressed? Do you think it wo=
uld be usefull?<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></=
span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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@<wbr>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/146727c3-d49d-480d-950f-76a8104b5220%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1467=
27c3-d49d-480d-<wbr>950f-76a8104b5220%40isocpp.org</a><wbr>.<br>
</font></span></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/CAOkZZiH8Y8W0Sju8S0iK84%3D%2BmJ571OnQ=
tFMQ4%2B20oU1FbiGMdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH8Y8=
W0Sju8S0iK84%3D%2BmJ571OnQtFMQ4%2B20oU1FbiGMdA%40mail.gmail.com</a>.<br />
--001a1130d2ea420f190544122ef0--
.
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Tue, 20 Dec 2016 08:56:49 +0100
Raw View
--089e013d1ae0eb6d2e05441260c1
Content-Type: text/plain; charset=UTF-8
I do not unfortunatelly see, how above works. I must be missing something.
for the templated function:
template<PFunc pfunc>
int doCall(std::string s, float f) {
assert(pfunc != nullptr);
return (*pfunc)(s, f);
}
Why is compiler forbidden to create code like:
//set params
lcall pfunc // for each PFunc different constant pfunc
ret
? I can see this perfectly valid for compiler to create function when known
pfunc (when template is instantiated), that calls pfunc by not inlining it.
Did you mean, that doCall will be inlined? Here I also do not see the
reason, why doCall is inlined.
You example does not show, whether or not functions are inlined or not.
Could you please explain?
2016-12-20 8:42 GMT+01:00 Dawid Pilarski <dawidpicpp@gmail.com>:
> MARK: moved from std-discussion
> answer: from charleyb123
>
> Agree that it could be useful to have more information on controlling
> 'inline' (since it's currently just a "suggestion"), and would be nice to
> have better mechanism to "know" if a given function was *actually* inlined
> (after it was requested to be inlined).
>
> There does seem to be a tricky contrast with ODR, where actually-inlined
> code (by definition) is defined multiple times. Today's compilers seem to
> do a really good job with that tradeoff.
>
> For highly performance-sensitive code where I've needed to "force" an
> inline, below is an example where the *function-address* is the
> template-parameter, which must be expanded by the compiler at template
> instantiation, thereby "forcing" the function call to be "inline".
>
> (This example is C++98, I much prefer the 'using' style of C++11.)
>
> -charley
>
> -----
>
> // FILE: test4.cpp
>
> #include <cassert>
> #include <iostream>
>
>
> // EXAMPLE: Force "inline" of function-pointer by parameterizing
> // through template-function
> // SHOWS: Compiler-forced inlining (through function-template
> instantiation)
> // REQUIRES: C++98
> // NOTES:
> // *- Function-template cannot be instantiated without
> parameterized
> // function-address, so compiler "sees" address and
> function-pointer
> // will be executed directly (without runtime
> double-indirection)
> //
> //----------------
> //----------------
>
> typedef int(*PFunc)(std::string s, float f);
>
> // TRICK: Function-pointer is template-argument (needed at compile
> // to instantiate function)
> template<PFunc pfunc>
> int doCall(std::string s, float f) {
> assert(pfunc != nullptr);
> return (*pfunc)(s, f);
> }
>
> //----------------
> //----------------
> int MyProduct(std::string s, float f)
> {
> int i = s.c_str() ? atoi(s.c_str()) : 0;
> return static_cast<int>(f * i);
> }
> int MySum(std::string s, float f)
> {
> int i = s.c_str() ? atoi(s.c_str()) : 0;
> return static_cast<int>(f + i);
> }
>
> //----------------
> //----------------
>
> #if __cplusplus > 199711L
> // C++11
> int (&doCall_product)(std::string s, float f) = doCall<&MyProduct>;
> int (&doCall_sum)(std::string s, float f) = doCall<&MySum>;
> #endif
>
> //----------------
> //----------------
> int main(void)
> {
> std::cout << "Hello, World!" << std::endl;
>
> std::cout << doCall<&MyProduct>("40", 2) << std::endl;
> std::cout << doCall<&MySum>("40", 2) << std::endl;
>
> #if __cplusplus > 199711L
> // C++11
> std::cout << doCall_product("40", 2) << std::endl;
> std::cout << doCall_sum("40", 2) << std::endl;
> #endif
>
> PFunc my_pfunc;
>
> my_pfunc = &doCall<MyProduct>;
> std::cout << (*my_pfunc)("40", 2) << std::endl;
>
> my_pfunc = &doCall<MySum>;
> std::cout << (*my_pfunc)("40", 2) << std::endl;
>
> return 0;
> }
>
> //Output:
> // |--------------------
> // |Hello, World!
> // |80
> // |42
> // |80
> // |42
> // |80
> // |42
> // |--------------------
>
>
> 2016-12-20 8:36 GMT+01:00 Dawid Pilarski <dawidpicpp@gmail.com>:
>
>> MARK: moving post from std-discussions
>>
>> Question:
>> Hi.
>>
>> The problem I would like to address, which has got no solution on
>> language level is programmer not being able to force function to be inlined.
>>
>> I am completely fine with the fact, that compiler can decide, whether
>> it's optimal to make function inlined or not and do so appropriately, so
>> that
>> inline is just a hint for the compiler.
>>
>> On the other hand there are situations, when you need to have a control
>> over the call stack. Especially when playing with std::longjmp and
>> std::setjmp for example
>> to implement co-routines (this case however has already been addressed),
>> so that one can create await() function (it's just an example).
>>
>> Solution would seem, to use compiler options to force inline functions,
>> but then gcc rejects any function, that is to be force inlined, when using
>> std::setjmp in it.
>>
>> This would seem to be a rare case, when one will have to use force
>> inline. It also creates a risk, that people will start using force inline
>> instead of simple inline to make
>> "optimizations" therefore discarding compiler wisdom.
>>
>> Has this problem been addressed? Do you think it would be usefull?
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-
>> 76a8104b5220%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/146727c3-d49d-480d-950f-76a8104b5220%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/CAOkZZiHpoyu4Zv0UJ9ZEF9kVsCb3ZRJ_fo4caVRpKptRAJkvYQ%40mail.gmail.com.
--089e013d1ae0eb6d2e05441260c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I do not unfortunatelly see, how above works. I must =
be missing something.<br><br></div>for the templated function:<br><div><div=
>template<PFunc pfunc></div><div>int doCall(std::string s, float f) {=
</div><div>=C2=A0 assert(pfunc !=3D nullptr);</div><div>=C2=A0 return (*pfu=
nc)(s, f);</div><div>}<br><br></div><div>Why is compiler forbidden to creat=
e code like:<br><br></div><div>//set params<br></div><div>lcall pfunc // fo=
r each PFunc different constant pfunc<br></div><div>ret<br><br></div><div>?=
I can see this perfectly valid for compiler to create function when known =
pfunc (when template is instantiated), that calls pfunc by not inlining it.=
<br><br></div><div>Did you mean, that doCall will be inlined? Here I also d=
o not see the reason, why doCall is inlined.<br><br></div><div>You example =
does not show, whether or not functions are inlined or not. Could you pleas=
e explain?<br></div><br></div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2016-12-20 8:42 GMT+01:00 Dawid Pilarski <span dir=3D"lt=
r"><<a href=3D"mailto:dawidpicpp@gmail.com" target=3D"_blank">dawidpicpp=
@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>MARK: moved from std-discussion<br></div>answer: from charleyb123<b=
r><br>Agree that it could be useful to have more
information on controlling 'inline' (since it's currently just=
a=20
"suggestion"), and would be nice to have better mechanism to &quo=
t;know" if a
given function was *actually* inlined (after it was requested to be=20
inlined).<div><br></div><div>There does seem to be a tricky contrast=20
with ODR, where actually-inlined code (by definition) is defined=20
multiple times.=C2=A0 Today's compilers seem to do a really good job wi=
th=20
that tradeoff.</div><div><br></div><div>For highly performance-sensitive
code where I've needed to "force" an inline, below is an exa=
mple where=20
the *function-address* is the template-parameter, which must be expanded
by the compiler at template instantiation, thereby "forcing" the=
=20
function call to be "inline".</div><div><br></div><div>(This exam=
ple is C++98, I much prefer the 'using' style of C++11.)</div><div>=
<br></div><div>-charley</div><div><br></div><div>-----</div><br><div>// FIL=
E: test4.cpp</div><div><br></div><div>#include <cassert></div><div>#i=
nclude <iostream></div><div><br></div><div><br></div><div>// =C2=A0EX=
AMPLE: =C2=A0Force "inline" of function-pointer by parameterizing=
</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0through template-fun=
ction</div><div>// =C2=A0 =C2=A0SHOWS: =C2=A0Compiler-forced inlining (thro=
ugh function-template instantiation)</div><div>// REQUIRES: =C2=A0C++98</di=
v><div>// =C2=A0 =C2=A0NOTES:</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0*- Function-template cannot be instantiated without parameterized=
</div><div>// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 function-add=
ress, so compiler "sees" address and function-pointer</div><div>/=
/ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will be executed directl=
y (without runtime double-indirection)</div><div>//</div><div>//-----------=
-----</div><div>//----------------</div><div><br></div><div>typedef int(*PF=
unc)(std::string s, float f);</div><div><br></div><div>// TRICK: Function-p=
ointer is template-argument (needed at compile</div><div>// to instantiate =
function)</div><div>template<PFunc pfunc></div><div>int doCall(std::s=
tring s, float f) {</div><div>=C2=A0 assert(pfunc !=3D nullptr);</div><div>=
=C2=A0 return (*pfunc)(s, f);</div><div>}</div><div><br></div><div>//------=
----------</div><div>//----------------</div><div>int MyProduct(std::string=
s, float f)</div><div>{</div><div>=C2=A0 int i =3D s.c_str() ? atoi(s.c_st=
r()) : 0;</div><div>=C2=A0 return static_cast<int>(f * i);</div><div>=
}</div><div>int MySum(std::string s, float f)</div><div>{</div><div>=C2=A0 =
int i =3D s.c_str() ? atoi(s.c_str()) : 0;</div><div>=C2=A0 return static_c=
ast<int>(f + i);</div><div>}</div><div><br></div><div>//-------------=
---</div><div>//----------------</div><div><br></div><div>#if __cplusplus &=
gt; 199711L</div><div>=C2=A0 // C++11</div><div>=C2=A0 int (&doCall_pro=
duct)(std::string s, float f) =3D doCall<&MyProduct>;</div><div>=
=C2=A0 int (&doCall_sum)(std::string s, float f) =C2=A0 =C2=A0 =3D doCa=
ll<&MySum>;</div><div>#endif</div><div><br></div><div>//---------=
-------</div><div>//----------------</div><div>int main(void)</div><div>{</=
div><div>=C2=A0 std::cout << "Hello, World!" << std::=
endl;</div><div><br></div><div>=C2=A0 std::cout << doCall<&MyP=
roduct>("40", 2) << std::endl;</div><div>=C2=A0 std::cou=
t << doCall<&MySum>("40", 2) << std::endl;<=
/div><div><br></div><div>#if __cplusplus > 199711L</div><div>=C2=A0 // C=
++11</div><div>=C2=A0 std::cout << doCall_product("40", 2) =
<< std::endl;</div><div>=C2=A0 std::cout << doCall_sum("40=
", 2) << std::endl;</div><div>#endif</div><div><br></div><div>=
=C2=A0 PFunc my_pfunc;</div><div><br></div><div>=C2=A0 my_pfunc =3D &do=
Call<MyProduct>;</div><div>=C2=A0 std::cout << (*my_pfunc)(&quo=
t;40", 2) << std::endl;</div><div><br></div><div>=C2=A0 my_pfunc=
=3D &doCall<MySum>;</div><div>=C2=A0 std::cout << (*my_pfu=
nc)("40", 2) << std::endl;</div><div><br></div><div>=C2=A0 =
return 0;</div><div>}</div><div><br></div><div>//Output:</div><div>// =C2=
=A0|--------------------</div><div>// =C2=A0|Hello, World!</div><div>// =C2=
=A0|80</div><div>// =C2=A0|42</div><div>// =C2=A0|80</div><div>// =C2=A0|42=
</div><div>// =C2=A0|80</div><div>// =C2=A0|42</div><div>// =C2=A0|--------=
------------</div><br></div><div class=3D"HOEnZb"><div class=3D"h5"><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-12-20 8:36 GMT+01:0=
0 Dawid Pilarski <span dir=3D"ltr"><<a href=3D"mailto:dawidpicpp@gmail.c=
om" target=3D"_blank">dawidpicpp@gmail.com</a>></span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">MARK: moving post from std-discussions<b=
r><br>Question:<br>Hi.<br><br>The problem I would like to address, which ha=
s got no=20
solution on language level is programmer not being able to force=20
function to be inlined.<br><br>I am completely fine with the fact, that=20
compiler can decide, whether it's optimal to make function inlined or=
=20
not and do so appropriately, so that<br>inline is just a hint for the compi=
ler.<br><br>On
the other hand there are situations, when you need to have a control=20
over the call stack. Especially when playing with std::longjmp and=20
std::setjmp for example<br> to implement co-routines (this case however=20
has already been addressed), so that one can create await() function=20
(it's just an example).<br><br>Solution would seem, to use compiler=20
options to force inline functions, but then gcc rejects any function,=20
that is to be force inlined, when using std::setjmp in it.<br><br>This=20
would seem to be a rare case, when one will have to use force inline. It
also creates a risk, that people will start using force inline instead=20
of simple inline to make<br>"optimizations" therefore discarding =
compiler wisdom.<br><br>Has this problem been addressed? Do you think it wo=
uld be usefull?<span class=3D"m_9011549888916568040HOEnZb"><font color=3D"#=
888888"><br></font></span></div><span class=3D"m_9011549888916568040HOEnZb"=
><font color=3D"#888888">
<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@isoc<wbr>pp.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/146727c3-d49d-480d-950f-76a8104b5220%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/1467=
27c3-d49d-480d-950f-<wbr>76a8104b5220%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>
</div></div></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/CAOkZZiHpoyu4Zv0UJ9ZEF9kVsCb3ZRJ_fo4c=
aVRpKptRAJkvYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiHpoyu4Zv0U=
J9ZEF9kVsCb3ZRJ_fo4caVRpKptRAJkvYQ%40mail.gmail.com</a>.<br />
--089e013d1ae0eb6d2e05441260c1--
.