Board index » delphi » How can one avoid "Data Segment Too Large" "Too many Symbols"

How can one avoid "Data Segment Too Large" "Too many Symbols"

Data Segment too large / Too many symbols

I have been working on a graphics component, about 4000 lines. All of
a sudden
I get "Data Segment too Large", and that's the end of it. I delete
functions, etc,
nothing seems to help. I am using Delphi 16.

The help info as below gives some blurb, really, what is the developer

supposed to do? Too many functions, the program is now "just too big"
is it, at 4000 lines for a component?

Matt...@lottery.powernet.co.uk
Please email me I thankfully reply.
------------------------------

Compiler Error 49: Data Segment Too Large

The maximum size of a program's data segment is 65520 bytes, including
data declared by the units in
the program. Note that in Windows programs, both the stack and the
local heap "live" in the data
segment.
If you need more global data than this, declare larger structures as
pointers, and allocate them
dynamically using the New procedure.
Note that old model objects (as supported by Borland Pascal 7) store
their virtual method tables in the
data segment. The new model classes do not. Also, PChar string
constants are stored in the data
segment. Pascal string constants are not.
If you are using the old model objects, try using the new method
classes declaration to reduce the virtual
methods used in your program. In addition, try moving PChar string
constants into a string table resource.
For more information, see The New Model Objects.

 

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


On Tue, 06 Apr 1999 21:38:14 GMT,

Quote
PleaseSeeAddr...@TheBottom.OfMyMessage.co.uk (Hello) wrote:
>Data Segment too large / Too many symbols

>I have been working on a graphics component, about 4000 lines. All of
>a sudden
>I get "Data Segment too Large", and that's the end of it. I delete
<snip>
>Compiler Error 49: Data Segment Too Large

>The maximum size of a program's data segment is 65520 bytes, including
>data declared by the units in
>the program. Note that in Windows programs, both the stack and the

<snip>

You should have read the help text of that error more closely. Data
segment too large means that you have declared too many large
variables.

It's typical when doing things like this:

var
  a,b: array[1..10000] of Integer;

This tries to declare two 40kb arrays which is more than the 64kb
available. I would suggest you go through your pool of variables and
see if you can either shrink the size of some of them, or make them
dynamically allocated.
--
Lasse V?gs?ther Karlsen
Cintra Software Engineering AS
la...@cintra.no

All views in this posting is my own and does not reflect those of the company I work for.

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
Hello wrote in message <370aa...@news.power.net.uk>...
>Data Segment too large / Too many symbols

>I have been working on a graphics component, about 4000 lines. All of
>a sudden
>I get "Data Segment too Large", and that's the end of it. I delete
>functions, etc,
>nothing seems to help. I am using Delphi 16.

>The help info as below gives some blurb, really, what is the developer

>supposed to do? Too many functions, the program is now "just too big"
>is it, at 4000 lines for a component?

I thought that the help explanation was perfectly clear. It sounds like you
are defining a large number of, and/or very large variables. Use the help
suggestion of creating dynamic variables for your larger structures.

Deleting functions won't change the size of your Data Segment, it will
affect the unit's Code Segment size.

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
Hello wrote:

> Data Segment too large / Too many symbols

> I have been working on a graphics component, about 4000 lines. All of
> a sudden
> I get "Data Segment too Large", and that's the end of it. I delete
> functions, etc,
> nothing seems to help. I am using Delphi 16.

> The help info as below gives some blurb, really, what is the developer
> supposed to do? Too many functions, the program is now "just too big"
> is it, at 4000 lines for a component?

There are two types of segments:  code segments and data segments.  Both
are limited to 64K.  

The 64K code-segment limit only comes into play if you have too much
code in a single pascal Unit; more than one unit can fit into a segment
but a unit cannot occupy more than one segment.

The data-segment limit is a bigger problem, because you only have one
data segment for your stack, global variables, etc.  This is the limit
you are running into.

The solution is to put most of your variables into an object or into a
dynamically allocated record.  This gets the information out of the
stack/global data segment, and into the heap.  You can have as much heap
space as you want (within reason, and each chunk of heap-storage is
limited to somewhat less than 64K per chunk).

You do have to be certain that the program deallocates all of the
heap-space that it used.

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
Sundial Services wrote:
> The solution is to put most of your variables into an object or into a
> dynamically allocated record.  This gets the information out of the
> stack/global data segment, and into the heap.  You can have as much heap
> space as you want (within reason, and each chunk of heap-storage is
> limited to somewhat less than 64K per chunk).

> You do have to be certain that the program deallocates all of the
> heap-space that it used.

All good advice. Another thing that Sundial mentioned a while back was
to be careful with strings. In D1, strings that aren't given a length
specifier with the [] syntax will take up the full 255 bytes. You might
want to look at your declared strings and see if you can set a
pre-defined limit.

Dave
--
http://www.csd.net/~daves

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Im Artikel <370aa...@news.power.net.uk>,
PleaseSeeAddr...@TheBottom.OfMyMessage.co.uk (Hello) schreibt:

Quote
>I get "Data Segment too Large", and that's the end of it. I delete
>functions, etc, nothing seems to help.

Of course deleting code doesn't help against too much DATA!

Quote
>I am using Delphi 16.

That's what I supposed from your problem. 32 bit applications have segments of
more than 64KB, that don't overflow easily.

IMO your problem are bitmaps, arrays or other huge data structures, that don't
fit into a 64K segment. The cure are pointers or references to areas, that are
allocated at runtime, instead of fixed data areas.

Do you have records or classes with arrays, or array constants?

DoDi

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


In article <370B8F5F.C8D0A...@cfxc.com>, Dave Shapiro <da...@cfxc.com>
writes

Quote

>All good advice. Another thing that Sundial mentioned a while back was
>to be careful with strings. In D1, strings that aren't given a length
>specifier with the [] syntax will take up the full 255 bytes. You might
>want to look at your declared strings and see if you can set a
>pre-defined limit.

FWIW - If you have a lot of strings declared you may wish to move them
to a resource file, and then only load them when needed by calling
LoadStr. This is especially useful if your application requires to read
a lot of settings from an INI file or something similar.

HTH
--
Steve Turner
Leeds, England
(Remove NOSPAM from return address to reply)

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
VBDis wrote:

> Do you have records or classes with arrays, or array constants?

Classes tend not to be such a problem, since a Delphi class is only a 4
byte pointer, at least the bit thats statically allocated.

VBDis: Please remember that Delphi classes are not like C++ classes:
Delphi has an inbuilt level of indirection.

MH.

--
Martin Harvey.
http://www.harvey27.demon.co.uk/mch24/
Takeoff is optional.
Landing (sooner or later) is mandatory.

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Im Artikel <370D2148.85954...@aziraphale.demon.co.uk>, Martin Harvey
<mar...@aziraphale.demon.co.uk> schreibt:

Quote
>Classes tend not to be such a problem, since a Delphi class is only a 4
>byte pointer, at least the bit thats statically allocated.

Okay, memory for classes is allocated dynamically.

In fact dynamic allocation instead of static allocation of huge fixed data
structures is the key point.

Quote
>VBDis: Please remember that Delphi classes are not like C++ classes:
>Delphi has an inbuilt level of indirection.

Please understand that there is no special difference between Delphi and C++
and any other OO language classes. Every implementation consists of dynamic
instance data, referred to by the 'this' or 'self' pointer, and one or more
static method tables. Static fields in classes can be substituted by static
variables at module level, therefore no need for such syntactical elements
exists.

DoDi

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
>. . . Static fields in classes can be substituted by static
>variables at module level, therefore no need for such syntactical elements
>exists.

????????????????????????????????

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
VBDis wrote:

> >VBDis: Please remember that Delphi classes are not like C++ classes:
> >Delphi has an inbuilt level of indirection.

> Please understand that there is no special difference between Delphi and C++
> and any other OO language classes.

I beg to differ. Although you can do many similar things with all of
them, there are still subtle differences in programming model which
dictate a different approach to various problems.

Quote
> Every implementation consists of dynamic
> instance data, referred to by the 'this' or 'self' pointer, and one or more
> static method tables.

Don't you mean virtual method tables?

Your use of the word "static" here is not at all clear. C++ "static"
methods are more akin to Delphi's "class functions".  Please make
yourself clearer about how static "static" is .... does it require a
class instance of example?

Quote
> Static fields in classes can be substituted by static
> variables at module level, therefore no need for such syntactical elements
> exists.

That's why delphi doesn't have them.

--
Martin Harvey.
http://www.harvey27.demon.co.uk/mch24/
Takeoff is optional.
Landing (sooner or later) is mandatory.

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Im Artikel <#lyKsfvg#GA.257@upnetnews03>, "Bruce Roberts" <b...@attcanada.net>
schreibt:

Quote
>????????????????????????????????

What do you mean?

Static variables are common to all instances, and therefore are not stored in
any instance.

DoDi

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


On 12 Apr 1999 01:34:22 GMT, vb...@aol.com (VBDis) wrote:

Quote
>Im Artikel <#lyKsfvg#GA.257@upnetnews03>, "Bruce Roberts" <b...@attcanada.net>
>schreibt:

>>????????????????????????????????

>What do you mean?

>Static variables are common to all instances, and therefore are not stored in
>any instance.

Roughly translated, "????????" means "There ain't no such thang in
Delphi." You must be confusing Delphi with one of them other languages,
such as C++ or Java.
--
Ray Lischner  (http://www.bardware.com)
co-author (with John Doyle) of Shakespeare for Dummies

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
VBDis wrote:
> Static variables are common to all instances, and therefore are not stored in
> any instance.

Yes, but unlike implementation (module)-level variables, class-level
variables are inherited. This subtle but important difference is why I'm
surprised we haven't seen them in Delphi OP yet.

Dave
--
http://www.csd.net/~daves

Re:How can one avoid "Data Segment Too Large" "Too many Symbols"


Quote
VBDis wrote:
> That's correct, but can be circumvented by properties, that implement access to
> any module level variables in the declaring module.

I'm not sure I get what you mean here. Can you give an example?

Quote
> BTW, can somebody explain the handling of properties in Delphi, when both the
> Read and Write clauses refer to a field? Is there a penalty, when code refers
> to the properties, instead of directly addressing the fields? (I do not mean
> inheritance, where the properties might be redeclared)

No penalty whatsoever, except for a one-nanosecond delay at compile-time
while the compiler has to resolve the property invocation to the field
name.

For proof that properties = direct access to fields, check out this
"feature":

type
  TMyClass = class(TObject)
  private
    FProp: Integer;
  public
    // This property is read-only, but...
    property Prop: Integer read FProp;
  end;

// consider a variable C of type TMyClass:
var
  C: TMyClass;

// This is legal, and in fact changes the value of FProp. Yikes.
  PInteger(C.Prop)^ := 5;

In other words, Addr(C.Prop) = Addr(C.FProp).

Dave
--
http://www.csd.net/~daves

Go to page: [1] [2]

Other Threads