Path: utzoo!utgpu!watmath!clyde!att!mtuxo!rolls!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: object data type
Summary: Where space is ... Oasys
Message-ID: <136@mole-end.UUCP>
Date: 2 Jan 89 03:46:37 GMT
References: <5382@watdcsu.waterloo.edu> <5136@siemens.UUCP>
Distribution: comp
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 33

> ...  Does anyone have any recommendations for a C++ environment which will
> support large source code files?  The problem is that the yacc output is
> fairly large and the OASYS compiler (ver 1.1) that we have yields an
> internal cfront error.  (We also have a bison problem, but that is another
> story...Any recommendations or suggestions would be appreciated.

If the problem really is space, there are some things that I can suggest
for dealing with the Oasys packaging of cfront.

Contrary to what ought to be happening in cfront, there is some memory lost
when processing each function.  What this means is that you should split files
when you can.  It also means that you should reduce the size of yyparse.  You
might also look for a way (I haven't tried) to take the yyparse table
initializations out of the code that cfront sees and put them into a file that
is compiled seperately, perhaps as C rather than as C++.  Some magic with
make, the C preprocessor, and your source code might do the job, perhaps with
a little help from your sed(1).

If you can do it in a function, don't do it in yyparse.  Likewise, watch
for inlines that are ``plausible'' but that are more costly than you can
afford.  yyparse probably will trigger lots of initialization constructors
unless you pass arguments to functions by reference; watch out.  If you must,
create a special non-inline version of your functions, make them private, and
make yyparse a friend.  (ugh!)  Or create a friend class with private
functions that do those things and make yyparse a friend of *it*. (Better.)

I got some mail from Oasys about versions of C++ for the 386; presumably
these versions use the unsegmented large addressing model.  If so, you have
another option, albeit an expensive one.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile