Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cbmvax!uunet!grand!day
From: day@grand.UUCP (Dave Yost)
Newsgroups: comp.lang.c++
Subject: Re: fixing cfront 1.2.1
Summary: no more brick wall array limits
Message-ID: <435@grand.UUCP>
Date: 7 Oct 88 03:27:18 GMT
References: <33@beaver.cs.washington.edu>
Reply-To: day@grand.UUCP (Dave Yost)
Distribution: na
Organization: Grand Software, Inc., Los Angels, CA 213-650-1089
Lines: 30

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.