Re: Bloat

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Fri, Jan 30, 2009 at 07:45:32PM +0200, Antti Kantee wrote:
> > I still think "keep it to 5 lines, but do use inline instead of a macro
> > wherever possible" is a decent rule of thumb.
> 
> Yes, the hardware really cares how many lines of code something is.

Of course it does, because source code length is a reasonable if imperfect
proxy for machine code length, in C anyway.

Since you have not clearly defined what appears to be your principal
objection to the use of inline (that it mixes implementation and
interface, or words along those lines) I can't dispute whether that
objection is reasonable or not.  From my point of view, the use of
inlines or macros in header files _for certain purposes_ is actually
an important and useful way to hide implementation details (thus
preserving object opacity in cases where that is a good practice) and
thus I am in favor of inline use _IN SOME CASES_ for reasons which to
me sound almost like the same reason as one of the reasons you're against
it.

This suggests to me that I am probably right in some cases and you are
probably right in others, but that neither of us is always right.

Except that you seem to be making the absolute argument that all uses
of inline are bad, while I am (trying to) make the very different argument
that _some_ uses of inline are good while others are clearly very bad,
including most of those that have been in our tree for a long time.

> If you can't construct a micro test case showing your inline makes
> any difference, nevermind a real world scenario, what's the benefit?

"Constructing a micro test case" for every instance of a particular
language construct throughout the system is not practical nor reasonable.
If you think you've persuaded anyone by using that argument, I have
to suggest that either:

        A) whoever you persuaded already agreed with you, or
        B) whoever you "persuaded" was just annoyed by your mode of
           argument and went away without saying any more.

There are obvious cases in which use of macros or inlines will in
fact expose information to the compiler which will clearly allow it
to perform useful optimizations it otherwise can't.  These cases seem,
to me, so obvious that their existence is a persuasive argument that
inline should be used for them.

For example:

struct X
{
    int x;
    int y;
}

for (i = 0; i < HUGE; i++) {
    other = get_x(X) + get_y(Y);
}

If get_x and get_y are the obvious trivial inline functions, the
compiler can do much better with this than if they're real functions
that live in some other source file.  And functions like these are
basically the _only_ ones I am suggesting should be inlines.

From a code-cleanliness point of view, to me they also seem like accessors
that are really logically part of the datastructures they access anyway.
The only way we have to do that in C, and keep the whole datastructure
definition in one place, is to use an inline function or a macro -- and
the inline function gives you argument type-checking and doesn't confuse
the debugger, which are useful advantages.

Can you please explain why in this particular case, you find inlines
so objectionable?

> Seems like inline functions is the inline assembly of 2000's ...

Seems like hitler is the new black.

I actually think some of the gigantic macros in our tree are far worse
offenders than many uses of inline.  Can we agree that those should die?

-- 
Thor Lancelot Simon                                        
tls%rek.tjls.com@localhost
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper