Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!mntgfx!franka
From: franka@mentor.com (Frank A. Adrian)
Newsgroups: comp.lang.c++
Subject: Re: Request for C++ coding "guidelines"
Keywords: C++, inlines
Message-ID: <1990Feb10.165633.4358@mentor.com>
Date: 10 Feb 90 16:56:33 GMT
References: <2754@arran.tcom.stc.co.uk> <25D0B18E.27508@paris.ics.uci.edu> <4446@pegasus.ATT.COM>
Reply-To: franka@mntgfx.UUCP (Frank A. Adrian)
Organization: /etc/organization
Lines: 22

In article <4446@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes:
> [A bunch of stuff having to do with linkers and loaders to try to fix the
> problem of C++ creating static copies of inline functions...]

An even better solution is to just have the compiler generate inline code
when you tell it to.  Yes, I know that naive users can get screwed when
code size balloons, but now naive users (and some experienced users) are
getting screwed because of ballooning static inline copies.  The arbitrary
limit on inlining in cfront doesn't help at all to make it clear when things
will be inlined and when things won't - I know, you get a warning, but that's
small consolation.  The arbitrary limit that cfront puts on inline complexity
doesn't help at all.  I want to use inline functions to replace macros.  I
can write arbitrarily complex macros (and have done so) to great benefit.
Cfront does not allow this.  If I get over a certain number of operators, if I
construct enough objects in an inline, I'm screwed.  DAMMIT, I KNOW WHEN I
WANT SOMETHING INLINED AND ALSO WHEN I DON'T.  Sorry for the flame, but it
seems that a lot of C++'s problems are QUITE self-inflicted...
-- 

Frank A. Adrian
Mentor Graphics, Inc.
franka@mntgfx.com