471,613 Members | 2,249 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,613 software developers and data experts.

inlining function objects

Hi.

I'm just curious if there any warnings or caveats or whatever to be
aware of when inlining function object calls? If the answer is no, they
inline just like everything else, that's good news for me.

glen
Jul 22 '05 #1
6 1503
glen_stark wrote:
Hi.

I'm just curious if there any warnings or caveats or whatever to be
aware of when inlining function object calls? If the answer is no, they
inline just like everything else, that's good news for me.


I suspect you mean "member function" in the place of "function object
calls".

This is an implementation detail. You'll need to check your specific
compiler.

Having said that, most (if not all) implementations don't have any
constraints in this area that I have seen.

Jul 22 '05 #2
glen_stark wrote:
Hi.

I'm just curious if there any warnings or caveats or whatever to be
aware of when inlining function object calls? If the answer is no,
they inline just like everything else, that's good news for me.


Actually, one reason to use function objects is because can be inlined
in some situations where normal functions can't.

Jul 22 '05 #3

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c1*************@news.t-online.com...
glen_stark wrote:
Hi.

I'm just curious if there any warnings or caveats or whatever to be
aware of when inlining function object calls? If the answer is no,
they inline just like everything else, that's good news for me.


Actually, one reason to use function objects is because can be inlined
in some situations where normal functions can't.


Could you show a specific example please?

-Mike
Jul 22 '05 #4
On Tue, 24 Feb 2004 01:40:40 GMT in comp.lang.c++, "Mike Wahler"
<mk******@mkwahler.net> was alleged to have written:
Actually, one reason to use function objects is because can be inlined
in some situations where normal functions can't.


Could you show a specific example please?


template <typename F>
void callfun(F *f)
{
(*f)();
}

Now, if you pass a function to this, the function to be called is (*f)
and only by dereferencing the pointer passed can the generated code call
the function.

But, if you pass a functional object the function to be called is
sometype::operator() regardless of the pointer value, and the call can
probably be inlined.
Jul 22 '05 #5


David Harmon wrote:
Actually, one reason to use function objects is because can be inlined
in some situations where normal functions can't.


Could you show a specific example please?


template <typename F>
void callfun(F *f)
{
(*f)();
}

Now, if you pass a function to this, the function to be called is (*f)
and only by dereferencing the pointer passed can the generated code call
the function.

But, if you pass a functional object the function to be called is
sometype::operator() regardless of the pointer value, and the call can
probably be inlined.
...


This is not a fair comparison. The above version of the code is run-time
parametrized and the call cannot be resolved at compile time (which
prevents inlining). The functional object version is compile-time
parametrized, which makes inlining possible.

Run-time parametrization can be implemented with both ordinary functions
and functional objects (through virtual functions). In both cases
inlining is impossible.

Compile-time parametrization can also be implemented with both ordinary
functions and functional objects. In both cases inlining is possible.

Both run-time and compile-time parametrization has its own uses and its
own advantages/disadvantages.

In order to make fair comparison in our case, you have to make "ordinary
function" version compile-time parametrized. For example, like this

template <char (*F)(int)> char callfun(int i)
{
return F(i);
}

Function call can be inlined in this case.

--
Best regards,
Andrey Tarasevich

Jul 22 '05 #6
Andrey Tarasevich wrote:
David Harmon wrote:
Actually, one reason to use function objects is because can be
inlined in some situations where normal functions can't.

Could you show a specific example please?
template <typename F>
void callfun(F *f)
{
(*f)();
}

Now, if you pass a function to this, the function to be called is
(*f) and only by dereferencing the pointer passed can the generated
code call the function.

But, if you pass a functional object the function to be called is
sometype::operator() regardless of the pointer value, and the call
can probably be inlined.
...


This is not a fair comparison. The above version of the code is
run-time parametrized and the call cannot be resolved at compile time
(which prevents inlining). The functional object version is
compile-time parametrized, which makes inlining possible.


Right. But often, you don't actually need the run-time parametrization,
but still are forced to pay the penalty. Think of std::sort with a
custom comparison function.
Run-time parametrization can be implemented with both ordinary
functions and functional objects (through virtual functions). In both
cases inlining is impossible.
Right.
Compile-time parametrization can also be implemented with both
ordinary functions and functional objects. In both cases inlining is
possible.
Both run-time and compile-time parametrization has its own uses and
its own advantages/disadvantages.

In order to make fair comparison in our case, you have to make
"ordinary function" version compile-time parametrized. For example,
like this

template <char (*F)(int)> char callfun(int i)
{
return F(i);
}

Function call can be inlined in this case.


Hm, do any compilers actually do that? Anyway, none of the standard
library algorithms are using this, so you either have to use funciton
objects or go without inlining.
Jul 22 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

17 posts views Thread by Tony Vitonis | last post: by
8 posts views Thread by Mat Booth | last post: by
11 posts views Thread by Elpoca | last post: by
15 posts views Thread by Lloyd Dupont | last post: by
21 posts views Thread by Michael Hull | last post: by
5 posts views Thread by copx | last post: by
58 posts views Thread by sh.vipin | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.