Re: Disadvantage of using 'inline'
From: Andrey Tarasevich (andreytarasevich_at_hotmail.com)
Date: 09/25/04
- Next message: pete: "Re: integer to char table problems"
- Previous message: pete: "Re: contiguity of arrays"
- In reply to: Chris Barts: "Re: Disadvantage of using 'inline'"
- Next in thread: E. Robert Tisdale: "Re: Disadvantage of using 'inline'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 25 Sep 2004 14:49:41 -0700
Chris Barts wrote:
>>>>>> ...
>>>>>> Placing the inline keyword on all static (module-local) functions
is an
>>>>>> okay thing to do, if you trust your compiler; it'll figure out
when not
>>>>>> to do it, although you can't take an inline function's address to
call
>>>>>> it indirectly, and you'll look a bit silly.
>>
>>>>
>>>> While it is true that an indirect call cannot be inlined (for obvious
>>>> reasons), there is absolutely no problem with taking an address of an
>>>> inline function. You seem to be mistaking two different things: inline
>>>> functions and inlined calls to functions.
>>>>
>
>>
>> This seems odd to me, too: If the function `should' be inlined (and,
>> therefore, have no independent existence), what is the rationale for
>> allowing programmers to take its address?
Declaring a function as 'inline' never meant that is has no "independent
existence".
The decision to inline a call is made by the compiler on a per-call
basis. Nothing in the language specification says that a function should
be either always inlined or never inlined. This has never been the
intention with inline functions. The compiler is completely free to
choose which concrete calls to inline and which not to inline.
It is obvious that in general case indirect calls cannot be inlined.
This, however, doesn't in any way prevent direct calls from being inlined.
>> Wouldn't that pretty much defeat
>> the purpose, by forcing the compiler to generate code for the function at
>> a specific location?
No. Why? Direct calls that have access to the inline definition of the
function can still be perfectly inlined. No problems here. Other calls
(indirect calls or calls that have no access to the inline definition)
are made in the "traditional" way. It is up to you to design and
organize your program the way that maximizes inlining (if that's what
you wish to achieve).
>> My point of reference isn't C++, but the C `register' keyword. It turns
>> out that C compilers are under no obligation to listen to the programmer
>> about which variables to try and place in registers (and on plenty of
>> machines, there are so few registers that tying one up is stupid),
but the
>> compiler is obligated to act as if it had by disallowing the taking
of the
>> address of a register-qualified variable.
It is a bad analogy. The fundamental difference between function and
variables that makes this a bad analogy is that functions are "frozen",
they don't change. If some entity is "frozen", there's no problem in
keeping and using several copies of that entity - no one would ever
notice and no one would ever know which copy is being used in each
particular case.
With functions the property of being 'inline' is a property of the
function itself, while the property of being actually _inlined_ is a
property of a concrete function call. Different calls to the same
function can have different properties (i.e. they can be inlined or they
can be directed to a "regular" function body), they don't conflict with
each other. It is a very natural separation, it requires relatively
little effort from the compiler and imposes no performance penalties.
Variables, on the other hand, can change their values. In order to keep
several copies of a variable (a 'register' copy and a normal copy in
memory, to allow address taking) the program will have to make sure that
values stored in these copies are carefully synchronized. This is very
difficult, if at all possible (frankly, I don't think it is). And in any
case this will impose significant run-time performance penalty.
Now, with _const-qualified objects declared with 'register' keyword
address-taking would be easy to implement, just because constants are
similar to functions - they don't change.
-- Best regards, Andrey Tarasevich
- Next message: pete: "Re: integer to char table problems"
- Previous message: pete: "Re: contiguity of arrays"
- In reply to: Chris Barts: "Re: Disadvantage of using 'inline'"
- Next in thread: E. Robert Tisdale: "Re: Disadvantage of using 'inline'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
