By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,696 Members | 1,512 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,696 IT Pros & Developers. It's quick & easy.

inlining function objects

P: n/a
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
Share this Question
Share on Google+
6 Replies


P: n/a
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

P: n/a
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

P: n/a

"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

P: n/a
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

P: n/a


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

P: n/a
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.