question on inlining

[ben]

is it true that a function without an inline keyword never get inlined? If
not true when is it inlined or not?

ben

[Ioannis Vranos]

Alf P. Steinbach wrote:

As of compiler invocation, are you talking
about one additional file to compile while avoiding to recompile the rest when you decide
to change the definition, vs compile *all* the rest that make use of the function, once
you decide to modify the definition.

Parse error. I gather it's an attempt at phrasing a false dilemma? ;-)

In addition to the other things that I mentioned (that essentially boil down that the
points provided do not make much sense to me), in this way the compiler also has to parse
the same definitions more times than once, and thus making your above specific point of
having to parse an additional file(?!) having not much sense too.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

Alf P. Steinbach wrote:

As of compiler invocation, are you talking
about one additional file to compile while avoiding to recompile the rest when you decide
to change the definition, vs compile *all* the rest that make use of the function, once
you decide to modify the definition.

Parse error. I gather it's an attempt at phrasing a false dilemma? ;-)

In addition to the other things that I mentioned (that essentially boil down that the
points provided do not make much sense to me), in this way the compiler also has to parse
the same definitions more times than once, and thus making your above specific point of
having to parse an additional file(?!) having not much sense too.

I think that may be because you're thinking too much (or perhaps only)
about optimization.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

The question discussed is

* Ioannis Vranos:

why would someone want to place a function definition in a header file?

from which followed

* Ioannis Vranos: Alf P. Steinbach wrote:

* Ioannis Vranos:

This is a tool subject, and the discussion turns to providing
documentation by "hacking" the language.
Parse error.

Meaning, documentation is an entirely other subject, and it has not anything to do with
our subject. It is a matter of what documentation style one wants, and documentation tools.

Yes, it is a matter of documentation style, and no, that doesn't mean it
has nothing to do with the subject.

Remove

* The comment (can't be checked by the compiler)
* The #include.
* The repeated declaration of the function signature.

Move

* The body of the function to the header file.

Add

* 'inline'.

Now the function (assuming it's a small one) is self-documenting.

Sorry but I can't understand this. For me the function definition remains the same
"self-documenting" (whatever this means) when you place it in one implementation file only.

With the definition in the header file you need only look at the header
file.

With the definition in a separate implementation file you may need to look
in two files, and the comment(s) in the header file may be inconsistent with
the separate implementation.

For some functions that is a good reason for some programmers to put the
definition in the header file.

When you only have a header file, no implementation file, there is one
less file to compile separately.

The first time. In the case of inlined functions however, the second time
you will have to recompile *all* the other files that make use of the function.

Yes, and (1) there's no need to remind me of what I have written by
reflecting it back in distorted form, and (2) there is a difference between
a file being compiled and a necessery compiler invocation; the latter can be
a cost both in build time (which I suspect is the only aspect you've
considered?) and in convenience and programmer effort.

Did you understand this now?

It is not primarily about build or program execution efficiency.

It cuts down on _redundancy_ of declarations, the repeated function
signatures.

Redundancy is bad both because of more work, and because of the
possibility of unnoticed differences.

You place the declaration only once, inside the same header that you would place the
redundant inlined definition, and include it as you would do in your (strange) inlining
approach. And you avoid the recompile-all when you modify the function definition.

Sorry, I can't figure out what you mean here.

As of compiler invocation, are you talking
about one additional file to compile while avoiding to recompile the rest when you decide
to change the definition, vs compile *all* the rest that make use of the function, once
you decide to modify the definition.

Parse error. I gather it's an attempt at phrasing a false dilemma? ;-)

I think the parser is buggy, and not the data itself. :-)

It would be nice if you attempted to present the data in a more
understandable way, so that this buggy parser can cope with it.
[
Please don't cut quoting so that what remains is without meaning.

Reinserted:

Ioannis:
"it will inline whenever it can for the ones that you defined as inline and
have placed in scope before the function use in a translation unit"
]

No, that is incorrect.

The point that's been stressed (I feel) a thousand times in this thread
is that not only can you not rely on that.

With modern compilers you can rely on the opposite: that the compiler
will do the job much better you can, and the more information you give
the compiler to do that job, the better job it does.

I have parse error myself here. By making it inline when you think that there will be
specific benefit for the program if the function gets inline, you do give more information
to the compiler.

No, making something inline is not necessarily about "when you think there
will be ... a benefit ... if [it's inlined]".

That is, by the way, invalid reasoning in more than one way. Consider your
reasoning here: "[the compiler] will inline [machine code] wherever it can
because you're making [the source code] [textually] inline where you think
there will be a benefit if the machine code is inlined." The compiler is
not guessing your intentions, and your intentions are not e.g. mine.

Presumably the parse error is simply because you cut away the statement that
"that is incorrect" referred to.

...

Major Error: I cant comprehend your points.

Aborted.

Try:

* Better quoting, with more context, less irrelevant quoted, fewer
spurious line breaks, fewer empty lines, fewer very long lines.

* Thinking about OTHER things than optimization.

Cheers, and hope this helps,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

Alf P. Steinbach wrote:

I think that may be because you're thinking too much (or perhaps only)
about optimization.

Actually you made an argument about compile-time optimisation or something. :-)
It would help much, if you provided a summary table of your points regarding benefits that
inline provides other than inlining. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Owen Jacobson]

On Wed, 25 May 2005 08:03:30 -0700, E. Robert Tisdale wrote:

Alf P. Steinbach wrote:

Forgot one important there: the trend towards template oriented
programming.

TOP?

Don't say that too loud.

[Ioannis Vranos]

Alf P. Steinbach wrote:

It cuts down on _redundancy_ of declarations, the repeated function
signatures.

Redundancy is bad both because of more work, and because of the
possibility of unnoticed differences.

You place the declaration only once, inside the same header that you would place the
redundant inlined definition, and include it as you would do in your (strange) inlining
approach. And you avoid the recompile-all when you modify the function definition.

Sorry, I can't figure out what you mean here.

--somefunc.h

void somefunc();

--somefunc.cpp

#include "somefunc.h"

void somefunc()
{
// ...
}

--someotherfile.cpp

#include "somefunc.h"

// ...


--
Ioannis Vranos

http://www23.brinkster.com/noicys