Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Compiler Error C3049 - String Space Exhausted

Status
Not open for further replies.

mbinfo

Programmer
Aug 21, 2002
27
0
0
BR
I´m using 5.2e and did not find the description for the message on subject in the manual nor in the Norton Guides.
Google did not find any reference!
A search here in Tek-tips also returned 0 occurrences.

The problem: A big program, part of a big application, was used to compile with no errors till some days ago. I have included a new routine of some 20 lines of code, just to change the files to be used. Now the compilation is beeing interrupted with this error pointing to a line that is about the middle of the source code. The code has 3390 lines and I tried to reduce the size of some string constants in order to see what happpens: the error remains, but pointing 3 or 4 lines below. I am sure I have other programs with much more strings used, and they are compiling with no problems.

How can I overcome this? Any Help?

Thank you all,

Ulisses
MBINFO
 
Split the file in 2 or more separate sources, and add the extra ones to the executable with the link script. This should go fine, except if you are using source-global variables.
 
Ton Hu is correct,that is a very large program to be compiled as a single unit.

It is important to understand this is a compiler error, not a run time error,and it is the compiler that is running out of string space, not your program, so removing or reducing strings won't have any direct relation to where the error appears in the compile.

It may be difficult to segment such a large program if isn't modular to start with. If most variables are global that makes it even harder. Maybe you can split the initializations into a separate module and save the initialized variables into a .mem file and then load them back in the main program to save code, literals and constants in there. Also reducing the number of unique variable names will reduce the symbol table, so arrays are preferable to unique variables.

Jock
 
I´m going to do this. This source code acomplishes two reports of the main application. I´ll have each one in a separate .PRG and I think global variables won´t be a great stuff to manage.

The issue will be to tell the customer he´ll have to wait till tuesday to get the program running. :)

Thank you (both)

Ulisses
mbinfo

 
By the way, does anyone have a NG file with the description of this message? I have both 5.2 and 5.3 NG files but no one contains it. The same with some rare messages I get sometimes that are undocumented in these files.

Thanks

Ulisses
mbinfo
 
Hm, I'm afraid that's one of those errors that is forever undocumented in the history of Clipper :-(
Possibly Harbour-Project or xHarbour have an updated list of compiler errors laying around, but I'd guess this one isn't on their list either, because these compilers are much more capable and robust.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top