-fno-default-inline

-fno-default-inline

[Mike Harrold]

Hi,

I use the -fno-default-inline a lot, sometimes for debugging purposes and
othertimes (with pragma interface/implementation) for class containment.
I specifically mark as inline those functions that I want inlined.

However, the C++ library headers do not contain inline specifiers, thus
using -fno-default-inline causes all standard library functions to be
external, something that is pointless for the more trivial functions
(such as list::begin, etc.).

Would it be possible to differentiate between system headers and userspace
headers for -fno-default-inline, or perhaps to add a different pair of
options that exclude system headers?

Or is this a case of pleading with the libstdc++ folks to mark functions
as inline where appropriate?

Thanks,

/Mike

Re: -fno-default-inline

[Alexandre Oliva]

On Jun 29, 2001, Mike Harrold <mharrold@cas.org> wrote:

> Or is this a case of pleading with the libstdc++ folks to mark functions
> as inline where appropriate?

I'm not sure we should add redundant keywords to libstdc++ code to
make room for a non-standard extension.  Is it really too hard for you
to move the member function definitions out of the class body, so that
the implicit inline Standard rule doesn't apply to them?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: -fno-default-inline

[Mike Harrold]

> 
> On Jun 29, 2001, Mike Harrold <mharrold@cas.org> wrote:
> 
> > Or is this a case of pleading with the libstdc++ folks to mark functions
> > as inline where appropriate?
> 
> I'm not sure we should add redundant keywords to libstdc++ code to
> make room for a non-standard extension.  Is it really too hard for you
> to move the member function definitions out of the class body, so that
> the implicit inline Standard rule doesn't apply to them?

I could, yes, but then that defeats the purpose of using pragma interface
and pragma implementation.

From the info page:

   "C++ object definitions can be quite complex.  In principle, your
source code will need two kinds of things for each object that you use
across more than one source file.  First, you need an "interface"
specification, describing its structure with type declarations and
function prototypes.  Second, you need the "implementation" itself.  It
can be tedious to maintain a separate interface description in a header
file, in parallel to the actual implementation.  It is also dangerous,
since separate interface and implementation definitions may not remain
parallel."

Not to mention maintaining consistant documentation in both the header
and source files is next to impossible. Hence why I chose to follow this
path.

I agree; inserting "inline" all over the standard library headers is
probably not the way to go. So would it be possible to refine the
-fno-default-inline option in some way to exclude them from non-inlining?

Regards,

/Mike