Re: Problems with inline functions

[George Anzinger <george at pioneer dot net>]

Geoff Keating wrote:
> 
> > Date: Mon, 28 Aug 2000 18:51:46 -0700
> > From: George Anzinger <george@pioneer.net>
> 
> > Geoff Keating wrote:
> > >
> > > George Anzinger <george@pioneer.net> writes:
> > >
> > > > ... I think it would be nice to defer compiling
> > > > inline functions until they are actually used in normal code.  This
> > > > would make writing header files that have inline functions MUCH easier
> > > > to manage.
> > >
> > > This would violate the C standard.  The diagnostics you're seeing are
> > > required.
> >
> > Then the C standard says something like "non-locals in an inline
> > function are references to the environment that exists at the time the
> > function "appears" in the source stream"?  This sounds confusing to me,
> 
> It says:
> 
> Structure, union, and enumeration tags have scope that begins just
> after the appearance of the tag in a type specifier that declares the
> tag.  Each enumeration constant has scope that begins just after the
> appearance of its defining enumerator in an enumeration list.  Any
> other identifier has scope that begins just after the completion of
> its declarator.
> 
> It makes no special exemption for inline functions.  From the point of
> view of the C standard, inline functions behave just as if they were
> defined normally.

I don't see how this prevents the compiler from compiling the code on
reference as opposed to appearance.  The only thing that requires the
latter is the macro pass with its #undef, which allows redefinition of
things, after possible use (I did this once).  In other words, I don't
think it would break any standard conforming code, nor would it violate
the standard and it would make it MUCH easier to put inline functions in
header files.  Did I miss something?  I.e. I am not saying the compiler
is wrong, just that it could be much better.

> 
> > however, given that the standard says what it does, is there some neat
> > trick (short of using macros) that will get the desired effect?  I have
> > come across cases where it was impossible to get the correct ordering
> > and resorted to a dummy structure and a cast to allow a forward
> > reference to a structure.  (Of course, by impossible I mean without
> > major rewrite of the offending header files.)
> 
> Generally, you're supposed to declare things before they are used.
> With structures, this is always possible.

After modifying several headers and so on, I finally got to a point were
the header that defined the structure I needed indirectly included the
header containing the inline code that needed the structure.
> 
> > In short I needed a way to forward reference a structure offset.
> 
> One possibility is to split the structures and the inline functions
> out into different header files.

I am sure there are ways to do this, but the reality of OPEN SOURCE code
don't really allow it.  Big changes need too much community involvement
to make these sorts of changes a real option.  Thus, my suggestion to
change how the compiler handles the inline.  As long as it does not
violate the standard, I would assume it might be considered.

George