Path: utzoo!utgpu!watserv1!watmath!att!dptg!pegasus!hansen
From: hansen@pegasus.ATT.COM (Tony L. Hansen)
Newsgroups: comp.lang.c++
Subject: Re: Request for C++ coding "guidelines"
Summary: "don't use inlines" is implementation dependent
Keywords: C++, inlines
Message-ID: <4446@pegasus.ATT.COM>
Date: 8 Feb 90 16:15:33 GMT
References: <2754@arran.tcom.stc.co.uk> <25D0B18E.27508@paris.ics.uci.edu>
Reply-To: hansen@pegasus.ATT.COM (Tony L. Hansen)
Organization: AT&T Bell Labs Middletown/Lincroft NJ USA
Lines: 54

< Regarding the extent to which inline functions should be used, I believe
< that there have been numerous comments here lately pointing out that the
< use of inline functions should be highly restricted.  Some radicals among
< us (Who, me?) may say that inline functions should never be used.  I am
< reminded of the ending of the movie 2010.

I think that the comments lately have been pointing out problems with some
current implementations of inline functions:

	When the inline must be outlined, a static version will be created
	as needed in EVERY .o file where it is needed. When the .o's are
	combined, you suddenly have N occurrences of the static function
	which wastes considerable space.

Now, there is nothing in this description of the problem which indicates a
problem with the language feature. Instead, the real problem is that there's
currently no implementation which causes those outlined static functions to
be combined into a single function at link time.

Here's a conceivable implementation for cfront+COFF/ELF-based systems:

    Cfront would produce two (or more) files for each .c file; the first is
    the C code for the user's code (call it usercode.c), and the second (and
    on) is the C code for each outlined static functions (call them
    outlined1.c through outlinedN.c).

    cc is run on all files, producing two (or more) .o's. These .o's are
    then combined into a single .o file with the following modification: the
    .text, .data and .bss sections of the outlined1.o through outlinedN.o
    files would be renamed .O1text, .O1data and .O1bss through .ONtext,
    .ONdata and .ONbss, and then stuck into usercode.o. (This is where
    COFF/ELF is required; I don't know any other a.out format which has
    arbitrarily-named sections.)

    Now the linker comes along. For each .o file, it pulls in the .text,
    .data and .bss sections as normally done. It then looks at the .O*text,
    .O*data and .O*bss sections and ONLY pulls it in if a symbol within it
    satisfies a currently-unresolved symbol. (Just as if that function had
    been found within a library.)

Here's another implementation:

    Each .c which is compiled somehow produces a file which is treated just
    like a library file (a .a archive) by the linker except that the first
    .o in such archives is ALWAYS forced to be pulled in.

    Those people who have their own compilers and linkers and can control
    the format of the object file can do this easily enough by having
    optional sections at the end of the object file which are treated by the
    linker as optional (only load as needed).

					Tony Hansen
				att!pegasus!hansen, attmail!tony
				    hansen@pegasus.att.com