to much global data?

**d00-asu** · 08-29-2001

Hi,

I'm writing a rather large 16-bit app. but I have encountered some problems.

I need some constats in a class ( aprox. 24K ) so I have made them const and static. However the compiler gives me the message "To much global data".

How much static data am I allowed to use? I would think something like 64K?

I'm using the large (even tried the huge) model so SS != DS. There is some other const data in the code (such as string constants) but probably <2K so that shouldn't be a problem.
The realy strange part however is that if I remove some functions, even ones that doesn't contain data, the whole thing compiles fine.

Please, my hair is turning gray.. any ideas on how to fix this?

- Anders

**Salem** · 08-29-2001

I think you're limited to at most 64K in any single compilation unit (.c file). Splitting your code into separate files for compilation, then linking all the object files together should work.

Note that having a single .c file which #includes all the other .c files is not the right thing to do.

Which compiler?

**doubleanti** · 08-29-2001

i've never myself had that much data when i was using a 16-bit DOS application compiler... but it makes you wonder that even if you did split the global data into seperate modules, would the linker then report the error? one wouldn't think so... but check that as well... perhaps if you used a different memory module... ie, large or huge... maybe the compiler would allow for a larger amount of global data...

**d00-asu** · 08-30-2001

Hi again,

Thanx for the quick answers. I tried to break up the code in multiple files: one containing the class header and the data, and a bunch of others containing memberfunctions. This seemed to improve the situation to some extent. The compiler now allowed me to add a bit more code, but not all.

I'm a bit unsertain about what you mean by not using #include..?
Presently I #include the .CPP files containing memberfunctions at the bottom of my header file, is this the wrong way to do it? Should I include the .OBJ files instead of the .CPP files? Or should I compile the files separatly and then link them together using some external linker? ..

Btw, I'm using the Bordland 5.02 compiler.

- Anders

**doubleanti** · 08-30-2001

i believe we meant, yes, compile seperately then link...

**Salem** · 08-30-2001

> Presently I #include the .CPP files containing memberfunctions at the bottom of my header file, is this the wrong way to do it?
This is the wrong way

> Should I include the .OBJ files instead of the .CPP files?
No .CPP and .H files are the only things you're allowed to include with #include's

> Or should I compile the files separatly and then link them together using some external linker?
Yes.
You can drive the linker manually, but it's generally much easier to use the compiler front end

bcc file1.cpp file2.cpp file3.cpp

counts as separate compilation. The compiler will produce 3 object files, and pass all three of them to the linker.

> but it makes you wonder that even if you did split the global data into seperate modules, would the linker then report the error?
If the compiler is doing the right thing when compiling code in the large models, each file has a unique segment (max 64K). The linker will see all these different segments and create an executable with multiple code and data segments.

**d00-asu** · 08-31-2001

Ok, I think I've got it.. there is one problem though..

The file that I'm trying to break up is one class, that is: class definition and memberfunctions.. but when I try to compile the memberfunctions separatly the compiler can't relate them to the class.. I get "Qualifier 'classname' is not a class or namespace"..

Do I have to include the classheader in all my files containing memberfunctions (seem odd)?? or how do I get the compiler to understand that the functions belong to that class?

- Anders

**Salem** · 08-31-2001

> Do I have to include the classheader in all my files containing memberfunctions
Yes.

class.cpp (class2.cpp etc) should include class.h

And anything which needs to refer to the class also needs to include class.h.

**d00-asu** · 08-31-2001

Allright.. fair enough.. I'm still a bit puzzled by the whole header files / included files part.. perhaps you would like to clarify some things..

I have a class, separated in classheader (cassname.h) and a number of implementation files (classimp1..n.cpp), these all start by including the classname.h. I allso have an application file(containing main(), and #include classname.h )

app.cpp <- #include classname.h
classimp1.cpp <- #include classname.h

I need to include some libraries in all my implementation files, should I include them in the classheader or in all of my implementation files?

I've tried to compile the files separatly and then link them together.. but I just won't work... *arghh*.. this is what I did, how is it wrong?

1. Compile code, this step seems to work
\> bcc -c app classimp1 .. classimpn

2. Link the files, this is where I get a loooot of error msg's..
\> tlink app classimp1 .. classimpn

I allso tried (directly):
\> bcc app classimp1 .. classimpn

But for every member function and every data field in the class I get: "Err: [func./data] defined in module [app] is duplicated in module [classimpn]".....

What to do? any sugestions? ..

**Salem** · 08-31-2001

Driving the linker directly is hard work. The compiler typically passes a whole bunch of options to it, and unless you know what they are, then you're stuck.

Fortunately, you don't need to do this too often.

Try this

1. Simple brute force compile everything each time
  bcc app.cpp classimp1.cpp classimp2.cpp classimpn.cpp

2. Better, compile as necessary
  bcc -c app.c
  bcc -c classimp1.cpp
  bcc -c classimp2.cpp
  bcc -c classimpn.cpp
When you've done this, you'll have a number of object files. The compiler knows this, so you can do this
  bcc app.obj classimp1.obj classimp2.obj classimpn.obj
and the compiler will just pass them all onto the linker (along with all it's mysterious options), and you should get the executable as if you had done example 1.

**d00-asu** · 09-01-2001

Oki.. I know how it's suposed to work.. but I just can't get it to link.. so I decided to surender and rethink my design.. perhaps I don't _need_ that much static constants.. I think I can move a bunch of them in to functions ..

But I would like to thank you for helping me..

- Anders

**~~master5001~~** · 09-03-2001

This is a good lesson for everyone. Use globals sparingly! By the way, one thing that I have found when dealing with this sort of problem is that compilers tend to treat your situation differently. If re-making your program is more work than you up to dealing with try downloading a new compiler.

**alex** · 09-05-2001

Hi!

It's a long time ago... but I had the same problem once. I solved it by giving the large data stucture its own segment by using the "far" and "huge" keywords...

You can also download the free borland compiler (bcc32)... But then you have to run your program from Windows.

Hope this helps...
alex

Unregistered · 09-10-2001

Hi again..

I was a fool to think I could fix it..

I never learn.. Giving the constants a 'function' scope didn't do it.. I still get 'Too much global data'.. but I have almost no global data..

I have tried all the tricks I know but nothing works, in a last desperate atempt I'm posting the code.

The file I wan't to compile is the testaxgs.cpp
The zip file contains a bunch of files, classes that I use. But you don't realy need to know what they are.. I'm just interesting in geting the darn code to compile and link..

I am aware of that you probably have better things to do, but if you find yourself late one night with some time to spare, please download the code and see if you can compile and link it; I will be eternaly greatfull..

- Anders

**alex** · 09-10-2001

Hi!

You're still including your full "cpp" files... This means that in the preprocessing stage, the compiler builds one big file to compile. The idea of splitting the code is that each cpp file can be compiled independently... so as a general rule you shouldn't include cpp files. (sometimes it is convenient to do so anyway: eg. when part of your program is generated automatically)

For example:

types.cpp should be called types.h (or types.hpp in borland style), because it does not contain any code.

XBinImg.cpp should be split into two files... The first 24 lines (DECLARATIONS) should go into XBinImg.hpp the rest can stay in XBinImg.cpp (DEFINITIONS, ie. code and constants). XBinImg.cpp should then include XBinImg.hpp and in every other file the reference to XBinImg.cpp in the #include line should be made XBinImg.hpp

auto_ptr.cpp contains a template. this should be a hpp file.

DOSMem.cpp should be split: the function declarations in the hpp file and the rest in the cpp file.

I hope you get the idea...

If you did all this splitting, you should be able to compile every cpp file separately as explain by others. But you will probably find that some declatations are missing from your current code. You'll probably have to add '#include "??????.hpp"' lines and/or change hpp-files yourself to get this stage working.

If you're able to compile every single cpp file, then you can compile the whole lot by typing "bcc *.cpp".

This will take some time, I think.

Sorry...

alex

Thread: to much global data?

Thread Tools

Search Thread

Display

to much global data?

horrible header headake

Similar Threads

Lame null append cause buffer to crash

data structure design for data aggregation

Where's the EPIPE signal?

[question]Analyzing data in a two-dimensional array

C diamonds and perls :°)