What is the gain of "inline"

[Michael Foukarakis]

Ben Bacarisse a écrit :


Inline will be a bad choice in general when then size of the inlined function's body
is bigger than the calling sequence of the normal call. I.e. when there is an
increase in the size of the code.

This is false. It depends on the amount of times that function is
called.

newbie-mode-on: That is, if it's only called once, inlining is faster
than calling. Regardless of instruction cache size.

It's for people who don't like macros.

Clever reference to the gcc documentation. Too bad they don't exactly
accomplish the same goals.

 

[Michael Foukarakis]

Inline functions MUST be written in header files...

Gawd, I'm going to die laughing today. In fact, I'm not.

But I will if you say the standard mandates this (as opposed to the
sub-psychotic ramblings of an incompetent lunatic)! Haha.

 

[Michael Foukarakis]

Don't be so silly. A macro is not the same thing in any shape or form.





Nothing worse than someone using an extreme case to support a rather
silly thought.

It's called reductio ad absurdum. It may seem extravagant, but his
point remains valid for fewer .c/.h files as well.

 

[Nick Keighley]

it can with inline...

I'm nota fan of many of the C99 changes, but inline functions seemed
pretty ok and C-like to me.

no. They *may* go in header files but they don't have to. An inline
function may only be used by one Translation Unit. Hell, the whole
program may be only one file!

If it's trivial enough that being in a header makes sense make it a
macro and uppercase.

there are all sorts of problems with macros, or at least, the
semantics of inline and macros are significantly different

inline int cube (int x) { return x * x * x; }

cube (n + 1);

Nothing worse than sorting through 250 unsorted .c and .h files trying
to find some random function with a mixed case name because some
jackass thought it was a good idea (bonus points for #ifdef hell).

shrug. Why is that any harder than searching for a macro definition?
My computer has a useful utility called "grep" and another one called
"find". Perhaps you should get a copy?

 

[Nick Keighley]

could people start trimming .sigs?

yes?

inline int next (int n) { return n + 1; }
x = next("HELLO");

that's a bit contrived I'm trying to come with an example where the
type checking matters.

It's called reductio ad absurdum. It may seem extravagant, but his
point remains valid for fewer .c/.h files as well.

no. get a source code browser or use grep. Anything above about 10
files is going to mean you have to search for thinsg occaisionally.
(Unless you are verey good with your naming conventions).

 

[Nick Keighley]

From my experience the sort of things that are short enough to warrant
inlining and tossing in a header are short enough that they can be
done via macros.  I've never had occasion to really put a full C
function as "static inline" inside header files.



Last I checked ctags and grep don't work through #ifdef hell.

other tools do though

 

[Nick Keighley]

I'm beginning to doubt this...


one argument would be that it's a C99 feature and C99 *still* isn't
available everywhere. Macros also really do inline things. (or rather,
are more likely to).

- multiple argument evaluation
- lack of type checking

I'm against putting code in a header file because it's just messy and
usually leads to disorganized code trees. [...]
Why would putting an inline function in a header file cause the
tree to be more disorganized than putting an equivalent macro in
the header file?

quite. Code is code however you wrapper it.


this is dogma not software engineering

Develop code how you want.  I don't give a rats ass really.  I'm
trying to offer some helpful advice from my experience as a software
developer.  

has it crossed your mind other people are trying to do the same thing?
I don't use inline in C because I don't like using C99 features. I use
it sparingly in C++ because it tends to lead to over-coupling,
breeches in encapsulation and fatty deposits in the arteries. But I am
aware it's there as another potential optimisation trick and I can
wave it at people who don't like getters and setters being proper
functions.

You're too prideful to either accept it or just graciously
decline it is YOUR OWN PROBLEM.

Mr Pot meet Mr Kettle

 

[Nick Keighley]

Don't macros also make debugging more of a mess at times too?

I once wrote a 30 line macro (poor man's template). That was fun to
debug.

 

[Nick Keighley]

You obviously haven't worked on highly configurable code before.  It's
not uncommon to have platform specific branches of code that include
platform specific macros.

sounds like poor design

 

[Nick Keighley]

On Dec 10, 1:19 pm, Richard <[email protected]> wrote:

You obviously haven't worked on highly configurable code before. [...]

LOL. Yeah right.

[It's]
not uncommon to have platform specific branches of code that include
platform specific macros.

And? How does that stop ctags working albeit ugly?

token pasting maybe? But then that would defeat near everything else
as well.

Nothing you said there makes it any easier to use macros over inlines in
terms of code navigation.

In fact, I'm not even sure where your ctags and and grep comment was
relevant. Inferior tools are inferior tools regardless of how you
prefer macros over inlines.

I think he decided "inline" is bad and is now trying to justify it.
Most of his arguments against inline apply to macros.

 

[Michael Foukarakis]

no. get a source code browser or use grep. Anything above about 10
files is going to mean you have to search for thinsg occaisionally.
(Unless you are verey good with your naming conventions).

I totally agree with you, I'm not going to work anywhere without at
least vim and ctags, but his point is still valid. Some people just
can't use a proper development environment (or deny, for whatever
reasons). His advice is a good rule of thumb, regardless.

 

[Nick Keighley]

Greetings,




Your wristwatch has a 1GHz pentium? You change the battery every 15 minutes?


No idea what you're getting at here, apparently in your world all
computers are on desks and run Windows.

presumably all his kitchen goods >20 years old and he doesn't have a
mobile phone

 

[gwowen]

 > Reference to r7.1.2 [dcl.fct.spec] in the C++ standard confirms this..
 > A function in C++ is never mandated to be inline... 

... So apparently C++ *never* mandates an actual inline...

Apparently

 

[Phil Carmody]

Really? I can only think of one place where C++ mandates inline (in
the absence of an explicit "inline" and thats when the definition of a
member function is included in the class definition. What are the
others?

Erm, if the "inline" is absent, then it's certainly not mandated.

Phil

 

[Phil Carmody]

I often think Kaz's posts are unnecessarily abrasive, but for coining
the word functino to mean "small function" I can forgive a great deal.
I do hope that word becomes accidentally adopted.

I hope it becomes *deliberately* adopted, prior different coinages
notwithstanding. I shall certainly try to use it that way.

Phil

 

[gwowen]

Erm, if the "inline" is absent, then it's certainly not mandated.

The point is, in certain circumstance the "inline" is implicit. Even
if it is absent, the compiler treats the function as if it were there.

class Foo
{
private:
size_t nfoo_;
public:
size_t get_nfoo() const {return nfoo_;}
}

The function Foo::get_nfoo() is treated as if it were declared
"inline".

 

[Phil Carmody]

In C, you're best off with the macro.

The one that can evaluate each of its operands twice?

Function solutions are clumsy because they constrain the left and right
operand to be of the same type , with a hard-coded return value.

Strange, I can imagine functions which have variable return values.

But if you're refering to having a deterministic return value, that's
a property I actually think's a good thing. You might even find that
macros share that property for the same reasons.

Phil

 

[Dik T. Winter]

>
> OK, I've considered it. I can think of several possible points
> here. Which one are you trying to make?

Multiple evaluation of arguments perhaps?

 

[Dik T. Winter]

>
> In C, you're best off with the macro.

Even if it evaluates its argument twice?

> The problem is that this is not how a max operator would behave, if it
> were built into the language. C operators are polymorphic: their ersult
> type is determined from the operand types, and, as well, the operands
> are normalized (i.e. one converted to the type of the other).
> The + operator can add a double and an int, a pointer and an unsigned
> long, etc.

Right, so having it as a function you need imax, fmax, dmax and perhaps a
few others. On the other hand, once you have fmax you have actually a
family of max functions, also those that return the maximum of an int and
a float.

 

[Tom St Denis]

Tom St Denis wrote:

)> No, not at all.  For example, the following inline function
)> cannot be implemented as a macro (in an obvious way, at least)
)> without evaluating its argument more than once:
)>
)>     static inline bool ovsdb_type_is_set(const struct ovsdb_type *type)
)>     {
)>         return (type->value_type == OVSDB_TYPE_VOID
)>                 && (type->n_min != 1 || type->n_max != 1));
)>     }
)
) Ok, but here's the question.  What is the performance hit of this
) being a normal function vs. inline?  Is it actually called enough to
) warrant this behaviour?
)
)> Because the properties of a C function are much more predictable
)> than the properties of a C macro.  For example, when foo is
)> defined as a function, the argument type and return type are
)> well-defined.
)
) Perhaps, I see what you're saying.  But if it's not a performance
) hazard who cares if the function is small, don't inline it.

Your arguments apply equally to macro's, so they are irrelevant to
this thread, which is about comparing macros with inline functions.

Well yeah and no. Too many macros in one file makes it harder to
maintain, but macros also don't affect compilation speed as much as
inlined functions. So the threshold of "when it's worth it" can be a
bit different.

For me, if a function isn't a performance hazard, it stays as a
function in its own .c file, no matter what.

Tom