On Aug 3, 9:55 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:

> > On Aug 3, 9:37 am, "Alf P. Steinbach" <al...@start.no> wrote:
> >> * Barry:

> >> "inline" allows you to define a given function with extern linkage, in
> >> more than one compilation unit. In practice that's done by placing the
> >> function definition in a header file, and that's also the practical
> >> value, being able to define functions in header files (this was before
> >> templates were introduced: templates provide a slightly more powerful
> >> mechanism for the same, applying also to data). The mnemonic value of
> >> that keyword is that the function's code is "inline" in the header file.

> > That's not really what the standard says.

> That's meaningless unless you define what "that" refers to.

The paragraph immediately preceding. (I wasn't top posting, you
know.) The standard very explicitly says something about the
intent of inline, which you've chosen to ignore or deny.

> The standard says what I say in the first sentence.

Amongst other things. That's only a partial picture. The first
half of the second sentence is also OK, but after that, it goes
downhill very quickly. What's the practical value of being albe
to define a function in a header? And how are templates in any
way relevant (except that they also allow definitions in a
header)? As a general rule, the less you put in a header, the
better.

> > The standard
> > explicitly says "The inline specifier indicates to the
> > implementation that inline substitution of the function body at
> > the point of call is to be preferred to the usual function call
> > mechanism."

> Yes, and it also says much else that is irrelevant to the
> correctness of the above.

> You're argumentative.

And you're wrong, or at least, incomplete and misleading.

> > Of course "to be preferred" is definitly not what
> > could be considered normative; the strictly normative effect is
> > to allow the function to be defined in more than one translation
> > unit. But a compiler which ignores the clearly stated intent of
> > the standard, without good reason, cannot be considered a good
> > compiler.

> > And templates, of course, have a completely different role; a
> > template function is not implicitly inline, and an inline
> > function is not a template.

> Again, unless you didn't grasp the distinction you're argumentative. I
> wrote "mechanism for the same". The term "inline" has a very specific
> meaning in the standard, and I didn't write that templates are "inline".
> That's the less powerful mechanism.

I'll admit that I can't figure out what your point is here.
Unless it is that both templates and inline are broken, in that
they require additional information in the header, and thus
increase source code coupling. (In the case of inline, there is
a definite, technical motive. In the case of templates, it's
only because implementations don't care about implementing the
standard.)

> In particular, if you want to define an extern linkage data item in a
> header file that's included in multiple compilation units, "inline"
> wont't work (it doesn't apply to data items), but the template mechanism
> can do that for you.

So? You seem to have missed the point. You never want to do
anything like that, any more than you want to define a function
in a header. In the case of templates, you do it only because
you have to.

> And since I don't want more argumentative responses on this:
> the standard's term for "compilation unit" is "translation
> unit".

> [snipped more apparent-corrections-that-aren't]

> >> And that's it.

> >> Except that once upon a time "inline" also worked as an
> >> optimization hint.

> > The standard, including the latest draft, says that that's what
> > it should do.

> >> However, modern compilers mostly just
> >> ignore that,

> > Are you sure? A good compiler will not ignore it, unless the
> > optimizer really is capable of doing a better job. Some are,
> > but not that many.

> I guess you can define the most used compilers as ungood and
> wiggle out that way? Heh. :-)

Actually, I was just considering the compilers I use. I know
that there are compilers which do ignore inline, because they
can do a better job. But they are still exceedingly rare. With
the compilers I use daily (g++ and Sun CC), it can certainly
make a difference, and is an important optimization tool.

> And let's get concrete.

> Like, g++, or Visual C++.

> The behavior of g++ is partially discussed in <url:http://gcc.gnu.org/onlinedocs/gcc/Inline.html>, where the two most most
> relevant tidbits of information are that by default no inlining occurs,
> and that g++ does not conform to the standard's requirement of using
> "inline" in all compilation units. When you specify optimizations the
> behavior depends on (1) keyword "inline" + non-standard ditto keywords,
> (2) options for inlining, and there are a huge number of them, and (3)
> the optimizer's judgement.

In sum, the compiler doesn't ignore inline, unless you tell it
to.

FWIW: I've actually had to use inline with g++ on one or two
occasions, for optimization reasons. It measurably makes a
difference. And you cannot get more concrete than that.

> The behavior of Visual C++ is partially discussed in <url:http://msdn2.microsoft.com/en-us/library/z8y1yy88(VS.80).aspx>, where
> the most relevant info is that "The insertion (called inline expansion
> or inlining) occurs only if the compiler's cost/benefit analysis show it
> to be profitable.".

Which means?

> > It's an ugly hack (because who
> > wants code in the header), but at times, it's the only solution.

> >> Using
> >> "inline" that way is not recommended.

> > Use of inline in general is to be avoided in header files.

> Subjective.

Build times are not subjective.

> > It increases coupling.

> In some cases, but mostly not.

Are you kidding?

> Today, with template programming, many logical modules are
> implemented as headers only.

Today, because of the coupling templates imply (in the absence
of compilers implementing export), most shops very strictly
limit their use. They have a significant cost. For low level
things, like the standard containers, the advantages outweigh
the cost, but at the application level, that's rarely the case.

> As a concrete example, much of the usability of the Boost
> library stems from it being mainly a header-only library.

The fact that it's mainly header-only is a major disadvantage,
and does limit its use somewhat. But considerations for third
party libraries (reputed stable) are different than those for
application code. If I upgrade the compiler, or something like
Boost, I do a complete rebuild anyway. (But of course, it's
something that you typically don't want to have to do more than
once every two or three years.)

> The few logical modules that do require separate compilation
> are more troublesome to use.

In the case of Boost, that's because they use a hopelessly
broken build system.

> For such cases, /not/ using "inline" increases coupling,
> enormously, namely to the separately compiled file.

Now you're being silly. Do you know what coupling means?

> > Similarly, non-exported templates should be
> > avoided.

> Now you have gone over the hill, James.

> There's only one commercial compiler that officially supports "export".

> Are you advocating using only the Comeau compiler, or are you joking?

Actually, I'm advocating avoiding overuse of templates. For
extremely stable, third party libraries, fine. For application
code, no.

--
James Kanze (GABI Software) email:james.kanze:gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34