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

re: inlining function objects

glen_stark wrote:[color=blue]
> 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.[/color]

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.

re: inlining function objects

glen_stark wrote:
[color=blue]
> 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.[/color]

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

re: inlining function objects

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:c1dqld$9ss$07$1@news.t-online.com...[color=blue]
> glen_stark wrote:
>[color=green]
> > 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.[/color]
>
> Actually, one reason to use function objects is because can be inlined
> in some situations where normal functions can't.[/color]

Could you show a specific example please?

-Mike

re: inlining function objects

On Tue, 24 Feb 2004 01:40:40 GMT in comp.lang.c++, "Mike Wahler"
<mkwahler@mkwahler.net> was alleged to have written:[color=blue][color=green]
>> Actually, one reason to use function objects is because can be inlined
>> in some situations where normal functions can't.[/color]
>
>Could you show a specific example please?[/color]

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.

re: inlining function objects

David Harmon wrote:[color=blue][color=green][color=darkred]
>>> Actually, one reason to use function objects is because can be inlined
>>> in some situations where normal functions can't.[/color]
>>
>>Could you show a specific example please?[/color]
>
> 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.
> ...[/color]

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

re: inlining function objects

Andrey Tarasevich wrote:
[color=blue]
> David Harmon wrote:[color=green][color=darkred]
>>>> 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?[/color]
>>
>> 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.
>> ...[/color]
>
> 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.[/color]

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.
[color=blue]
> Run-time parametrization can be implemented with both ordinary
> functions and functional objects (through virtual functions). In both
> cases inlining is impossible.[/color]

Right.
[color=blue]
> 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.[/color]

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.