This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: -fno-default-inline
- To: aoliva at redhat dot com (Alexandre Oliva)
- Subject: Re: -fno-default-inline
- From: Mike Harrold <mharrold at cas dot org>
- Date: Sat, 30 Jun 2001 00:47:16 -0400 (EDT)
- Cc: mharrold at cas dot org (Mike Harrold), gcc-help at gcc dot gnu dot org
>
> 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