richk@uw-larry (Richard Korry) (10/06/88)
We have cfront 1.2.1 running on Suns. The problem is with too many
inline functions. When I compile code I have received from other
places, I often find cfront breaking when there are lots of inline
functions. When I make them real ones, the problem goes away. Is there
some constant I can change to increase the number of functions it
can handle or can I do something else about it? thanks
richday@grand.UUCP (Dave Yost) (10/07/88)
In article <33@beaver.cs.washington.edu> richk@uw-larry.UUCP (Richard Korry) writes: >We have cfront 1.2.1 running on Suns. The problem is with too many >inline functions. ... Is there >some constant I can change to increase the number of functions it >can handle or can I do something else about it? thanks > rich They're had better not be a constant that you tweak! If there's one thing I expect OO to do for us, it's to provide for arrays to which it's easy to add things without worrying about running out of room. This bug of failing on "large" or "complex" input for lack of array space is rampant in the unix utilities, and is possibly the worst tradition of C and unix*. Anyone committing this sin in a language that can support an automatically-resizing array type should be sentenced to 90 days of hard labor in assembly language. The array class should automatically grow the array for you. Ah, I hear you say, but if you reallocate an array and move it somewhere, what about the poor pointers that point into now-moved the array? Maybe you are using a language that isn't high-level enough. --dave * Examples I have personnally seen over the years are: awk, cc, comm, csh, dbx, diffmk, du, ed, egrep, fgrep, grep, sdb, sed, sh, sort, tbl troff, uucico, etc., and, of course, the exec call's fixed argument list.
bs@alice.UUCP (Bjarne Stroustrup) (10/10/88)
Dave Yost of Grand Software, Inc., Los Angels, CA 213-650-1089 writes: > In article <33@beaver.cs.washington.edu> richk@uw-larry.UUCP (Richard Korry) writes: > >We have cfront 1.2.1 running on Suns. The problem is with too many > >inline functions. ... Is there > >some constant I can change to increase the number of functions it > >can handle or can I do something else about it? thanks > > rich > > They're had better not be a constant that you tweak! > If there's one thing I expect OO to do for us, it's to > provide for arrays to which it's easy to add things > without worrying about running out of room. This bug > of failing on "large" or "complex" input for lack of > array space is rampant in the unix utilities, and is > possibly the worst tradition of C and unix*. Anyone > committing this sin in a language that can support an > automatically-resizing array type should be sentenced > to 90 days of hard labor in assembly language. Whatever bug Richard Korry encountered it is not the one Dave Yost assumes it is. In cfront names (objects of class name) lives in symbol tables (objects of class table). Each symbol table represents a scope and cannot overflow (as long as you don't run out of physical memory - my guess would be that this might be what really happend) because a table grows itself to hold all the names in its scope. Actually, a cfront table isn't a dumb array at all but a semi-smart object providing various operations related to scopes. The logical conclusion of this style of design are described in Steve Dewhurst's papers on the AT&T ``native'' C++ compiler. Please don't misunderstand me as claiming that cfront is an especially beautiful object-oriented program. It isn't. For starters I only had a subset of C++ available when I started writing it and though more C++ features are now used the fundamental design is rather conservative. The key resource you can run out of in cfront is physical memory and there are a set of sizes that are fixed at compile time (at the time of compiling cfront , that is) related to the YACC parser used. Examples are the size of the lexical input buffer and the maximum class declaration nesting. Maybe I deserve some hard labor for that, but 90 days seems excessive and I consider dealing with YACC a penalty in itself. > The array class should automatically grow the array for > you. Ah, I hear you say, but if you reallocate an > array and move it somewhere, what about the poor > pointers that point into now-moved the array? Maybe > you are using a language that isn't high-level enough. Rhetoric. That wasn't the problem.
soiffer@tekchips.CRL.TEK.COM (Neil Soiffer) (10/15/88)
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)));
}