waynet@tekred.CNA.TEK.COM (Wayne Turner) (01/08/91)
We are developing a commercial application under DOS using Turbo C++ Version 1.01 and are consistently running into "Out of memory", "Not enough memory" errors from the command-line versions of the compiler and linker. The application itself is not huge--the source consists of about 5-6K lines and the current .EXE takes up about 360K bytes when loaded. Typically "tcc" will give an out of memory error when the .c file is at least 200-500 lines in length and the amount of code loaded from header files is about 1000-2000 lines. It would be difficult (if not impossible) for us to reduce the amount of header code included since we are using C++ class hierarchies that are up to 5 or 6 levels deep, and also need to define enumerators, consts, structs and so on. The developments systems are Compaq 386/20e's with 640K base memory running DOS 3.31. One system has 2 Megs extended memory and the other has 4 Megs. The TDMEM utility recognizes the presence of the stated amount of extended memory. We are using the -Qx option with tcc and /yx with tlink yet both run out of memory in certain instances. The only thing Borland tech support could suggest was to (1) break down our source modules into smaller modules (2) to unload any TSRs or unnecessary drivers. (1) is not really a solution for reasons stated above. (2) is only a temporary workaround. Sometimes the out of memory errors occur when there are 520K bytes free (again as reported by TCC) but a compile succeeds when 540K bytes are free. We are still in the early to middle stages of development and are concerned that at some point even 540K bytes will not be enough. Also note that sometimes it is necessary not only to unload any memory-resident utilities but to use the -S option with "make" to cause make to swap itself out of memory. In other instances we must actually invoke tcc or tlink from the DOS command line instead of using make at all. As an alternative, we are currently evaluating Zortech's C++ development system and are finding that we must seriously hack up some medium-size source modules just to get a working executable for our application. We are using the version of the compiler that uses Rational Systems DOS Extender technology ("ztc -br -e ...") and with larger modules get an error from DOS 16/M complaining about "involuntary switch to real mode". Zortech tech support is currently looking into this for us and appears to be serious about finding a solution. Is anyone out there developing applications with TC++ or Zortech C++ that take full advantage of C++ classes and are as large or larger that our application? If so have you run into similar memory problems? We would be interested in hearing about your experiences and any possible solutions or workarounds. We are even considering cross-development systems (that run on Sun Workstations) , if any exist, so we can get on with development and stop fighting the development tools. Other pertinent info: Using large memory model Using debugging option for all modules (we don't know in advance what modules will need debugging :-) Please respond by email to waynet@kit.CNA.TEK.COM and I will summarize responses and post them to the net. Thanks, Wayne Turner Tektronix, Inc.
emigh@ncsugn.ncsu.edu (Ted H. Emigh) (01/09/91)
In article <6818@tekred.CNA.TEK.COM> waynet@tekred.CNA.TEK.COM (Wayne Turner) writes: >We are developing a commercial application under DOS using >Turbo C++ Version 1.01 and are consistently running into "Out >of memory", "Not enough memory" errors from the command-line >versions of the compiler and linker. The application itself is >not huge--the source consists of about 5-6K lines and the >current .EXE takes up about 360K bytes when loaded. .... >Other pertinent info: >Using large memory model >Using debugging option for all modules (we don't know in >advance what modules will need debugging :-) My comment has to do with his last statement. I have a large project which I maintain (sounds about the same size as his). I turn on debugging ONLY for the module which contains main{} and any others which I am currently debugging. A well-designed project should allow you to be able to turn on debugging for a couple of modules at a time. I have three makefiles -- one which turns on debugging info for ONLY the main{} module; one which turns on debugging info for ALL modules; and one which turns off debugging info for ALL modules. When I change the headers or want to rebuild the program, I use the first. When I want to turn on debugging for a module (test.c), I delete test.obj, then use the second makefile. When I want to turn off debugging for a module (test.c), I delete test.obj, then use the last makefile. (Note: all makefiles have link set up to include debugging information. I also have a "production" makefile which doesn't link debugging information.)
bourd@galaxy.cps.msu.edu (Robert Bourdeau) (01/10/91)
In article <6818@tekred.CNA.TEK.COM>, waynet@tekred.CNA.TEK.COM (Wayne Turner) writes: |> We are developing a commercial application under DOS using |> Turbo C++ Version 1.01 and are consistently running into "Out |> of memory", "Not enough memory" errors from the command-line |> versions of the compiler and linker. The application itself is |> not huge--the source consists of about 5-6K lines and the |> current .EXE takes up about 360K bytes when loaded. |> Following up on your problems with TurboC++, I too have had the same problems. The application which I have been involved in developing is currently about 10K lines of my own source code not considering the class library and include files. The class hierarchy which I have developed is approximately 7 levels deep at the greatest. I was using a lot of inline code in my low level class definitions to improve performance, and it was this that was causing me a great deal of memory problems. When I reduced the inline code to only the most minimal situations, the memory problems went away. Apparently, using inline code requires a significant amount of RAM to hang on to, and it does not take a whole lot of code to use up all available space. Hope this helps some. Robert Bourdeau bourd@buster.cps.msu.edu Michigan State University
keffert@jacobs.CS.ORST.EDU (Thomas Keffer) (01/11/91)
In article <1991Jan10.143902.23969@msuinfo.cl.msu.edu> bourd@galaxy.cps.msu.edu (Robert Bourdeau) writes: >In article <6818@tekred.CNA.TEK.COM>, waynet@tekred.CNA.TEK.COM (Wayne >Turner) writes: >|> We are developing a commercial application under DOS using >|> Turbo C++ Version 1.01 and are consistently running into "Out >|> of memory", "Not enough memory" errors from the command-line >|> versions of the compiler and linker. The application itself is >|> not huge--the source consists of about 5-6K lines and the >|> current .EXE takes up about 360K bytes when loaded. >|> > >Following up on your problems with TurboC++, I too have had the same problems. >The application which I have been involved in developing is currently >about 10K lines of my own source code not considering the class library >and include files. The class hierarchy which I have developed >is approximately 7 levels deep at the greatest. We encountered this problem while checking out Tools.h++ on Turbo C++. It's a bug being tickled by your code --- the memory limitation is not real. Try commenting out various parts of your code, looking for the offending statements. -tk