Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!tektronix!tekcrl!tekchips!soiffer
From: soiffer@tekchips.CRL.TEK.COM (Neil Soiffer)
Newsgroups: comp.lang.c++
Subject: Re: fixing cfront 1.2.1
Summary: Not all 'inline' bugs have to do with table sizes
Message-ID: <3167@tekcrl.CRL.TEK.COM>
Date: 15 Oct 88 01:22:36 GMT
References: <33@beaver.cs.washington.edu> <435@grand.UUCP>
Sender: ftp@tekcrl.CRL.TEK.COM
Reply-To: soiffer@tekchips.CRL.TEK.COM (Neil Soiffer)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 45


Below is a bit of code that causes a bug if I try and inline a function.
cfront (1.2.1) puts out code that results in '_fixnum_zero' being
multiply defined.  There is no problem with '_fixnum_one'.

Note:  I doubt that this is the minimal code to produce the bug, but it is
paired way down from the original problem.

	Neil Soiffer
	Textronix Computer Research Lab
	UUCP:  ...!tektronix!tekchips!soiffer
	ARPA:  soiffer%tekchips.tek.com@relay.cs.net
	CSNET: soiffer%tekchips.tek.com

------------------------------------------------------


class number {
public:
    virtual number* zero() {return this;};
    virtual number* one() {return this;};
protected:
};

class fixnum: public number {
public:
    fixnum(int num) { n = num; };
private:
    int n;
    number* zero();
    number* one();
    static fixnum *Zero;
    static fixnum *One;
};

// inlining these two functions makes cfront complain (multiply declared)
inline number* fixnum::zero()
{
    return(fixnum::Zero ? fixnum::Zero : (fixnum::Zero = new fixnum(0)));
}

number* fixnum::one()
{
    return(fixnum::One ? fixnum::One : (fixnum::One = new fixnum(1)));
}