Subj : Re: Error: Too much global data defined in file
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Tue Mar 01 2005 12:11 pm

I have received the email.

I now know why it was discarded by the filters.  You used a subject of 
"Re:" which duplicates that which is the subject of a lot of spam. 
Emails with such subjects are set to be rejected by my filter as I 
have no use for ordering illegal drugs and both my wife and I are 
content with my current breast size.

There are many issues with what you sent.

At first glance it appears that the error reporting an excessive 
amount of global data may be wrong.  It appears that the error more 
relates to the massive amount of stack usage for large arrays and 
class instances containing large arrays declared as automatic 
variables within functions.  As the default stack size is 4K, the 
program as written guarantees the stack will overflow.  You need to 
use the help which came with the compiler.  In it you will find the 
way to alter the stack size of a DOS program is with a single extern 
declaration in one source file of this type:

  extern unsigned _stklen = 32768U;

where the number assigned must be less than 64K-256 (the operating 
system may use as much as 256 extra bytes of the segment) and the U at 
the end of the number indicates the number is an unsigned.

That program is quite difficult to analyze because of the way it is 
structured.

The bulk of the code is in the header files, both in non-inline class 
member function code and in a greater amount of code for standalone, 
global functions.  Non-inline code should be placed into source files. 
Only the function prototypes or associated class definitions should be 
in header files.

Storage for all of the global data is declared in the header files. 
Declarations allocatiing storage for global data should be placed into 
one of the source files and extern declarations for that data placed 
into header files.

C++ functions which take no calling parameters use () and not (void) 
in their calling argument list.

C++ functions which return int are prototyped and written with a 
return type of int and not with no return type.  This also applies to 
class member functions.

Unlike C, C++ will not convert pointer types.  An unsigned int* cannot 
be automatically assigned or converted to a char*.  The only quiet 
automatic conversion for pointer types is to a void*.   This call to 
complete_ptr specifies a calling argument which is an array name for 
unsigned int*.

  complete_ptr(ptrtitre[kk][i],' ',*ptrlarg[kk][i]);

Similarly there is an array of errors related to the conversion of a 
char near* to unsigned int* starting with this:

  ptrflag[0][i]=&flag_s[i]

And a complaint that the type of the parameter 'rslt' is wrong in this 
call

  get_field_str("comptcfg.fil",dumy1,caisse_cpt[i],EXIT);

I suggest that you start by doing these things:

Copy the global data declarations out of the compta.h header file to a 
new source file.  Then alter the header file declarations to all have 
the keyword 'extern' at the left and remove the initializations.

Move all functions and their associated code from the header files to 
new source files.  Keep the class definitions and function prototypes 
in the header files.

Add a copy of the current include list found in the compta.cpp file to 
the top of each of the new source files.

Create a make file which will be used to build the program.  This will 
allow you to receive errors from only one source file, correct it, and 
then never have to recompile it as you work on what errors are found 
in the next file and so on.

Using made-up names for the newly created files the make file might 
look like this:

-----------------------------------------
..autodepend

OBJS=compta.obj storage.obj code1.obj code2.obj code3.obj \
  code4.obj code5.obj code6.obj

compta.exe : $(OBJS)
      tlink /Tpe/v/c @&&|
c0l $(OBJS),compta,,emu cl
|

..cpp.obj :
      bcc -v -c -4 -ff -N -ml $<
-----------------------------------------

Note the indenting.  While the amount of indenting is not sensitive to 
the number of spaces used, the fact that something begins in column 1 
versus if it is indented is vital to proper operation of the make 
file.  Also do not overlook the periods that appear in column 1 for 
the '.autodepend' and '.cpp.obj :' lines.  They are required.

I have retained the -ff which you used in the compiler command line 
but note that it is the default so is not needed.  I have added '-c' 
to tell it to compile but not link and -v to tell it to include debug 
information as the program clearly will need debugging.  The text of 
the file above duplicates what I used after I reconfigured your code 
as discussed above.  However I did not troubleshoot everything so the 
linker command has not yet been executed.

If the file were saved with the default name MAKEFILE then a command 
to compile and link to create the program would be:

  make

If the file were saved with the name SOMENAME.MAK then the command 
would be:

  make -f somename.mak

where the space after the -f and the extension .mak are optional.

..  Ed

> Morosh wrote in message
> news:422471cb@newsgroups.borland.com...
>
> done at 13:44 GMT
> thanks

.