Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: Debugging on the GCC and G++ compilers
Summary: Macros, just as inlines, should be used rarely...
Message-ID: <1521@aber-cs.UUCP>
Date: 19 Dec 89 22:01:44 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 44

In article <0294@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
    > rfg@ICS.UCI.EDU
    > I have never understood why rms used such an immense number of MACROS().
    > [...] I personally think that this execssive use of macros is made completely
    > indefensible just based on rms' own statement (in the GCC manual) that:
    > "An inline function is as fast as a macro."

    But there are things that can be done with macros that cannot be done
    with functions in pure C, such as producing an lvalue, There are other
    things that cannot be done even in pure C++, such as multiple by-name
    evaluations when desired.  This was even pointed out in the description
    of how to convert the one to the other and sidestep the general problem
    raised here (the problem of adequate debugging support in the presence
    of macros).

Macros are useful for syntax extensions, and inlines cannot be used for that.
On the other both syntax extensions and inlines should be used sparingly
(syntax extensions especially so) and should be very small, otherwise they
don't buy you a lot.

Rms is writing very opaque code because he is using the macros either as
inlines, and for large pieces of code, or as syntax extensions, to implement
a degree of data abstraction over structures, and the latter is simply not
C; one uses suitably named struct members or whatever to achieve code
readibility.

The use of macros for inlines is also overdone, IMNHO, in gcc, because
macros/inlines buy you something in speed ONLY when the code is going to
execute often AND is small; code that is not going to execute often is not
worth optimizing, and proc overheads are irrelevant with code that is
not small, and putting inline large pieces of code increases paging.

If there is possibility of serious code simplification with macros/inlining,
things change a bit, but this is both rare and tipically only concerns a fast
path in the macro/inline, and the rest can be offlined.

The excessive macros/inlines in gcc and other programs (most notably X11R3)
also mean that code size gets large, and this is bad for programs that run
under virtual memory. Even small improvements in locality reduce page fault
rates dramatically...
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk