Article # 85, added by Geoworks, historical record
| first | previous | index | next | last |

Dgroup and static strings.




When developing for GEOS running on a desktop PC, you don't
need to worry too much about fixed size because most
contemporary PCs have several megs of RAM and lots of extra
space on the harddrive (and a fast CPU to swap blocks
around).

If you want your application to coexist with other
applications on a palmtop device, then you need to pay
attention to the fixed size.

Certain things, like the class table, must go into a fixed
resource, but this is generally not too large. The most
common reason for a growing dgroup (which is a fixed
resource) is global variables and static local variables.

Global variables are easy to recognize because they are
declared outside of a method or routine.

Static local variables can be recognized if you declare them
with the "static" keyword. They can also sneak in as static
strings. For example, if you do this:

  sprintf( someVar, "this is a static string\n" );

the string in quotes gets converted by the compiler into a
static string (and thus goes into the dgroup). Another
example:

  char * someString = "this is another static";

Although you might think the string is a local variable, it
is not. someString is local, but it points to the string
which is located in dgroup.

In cases where you are using static strings like the above
examples, it is best to declare them in a data resource and
then lock and dereference them. Example of how to do that:

@start MyDataResource;

@chunk char SomeStringChunk[] = "this string is in a chunk";

@end MyDataResource;

...

{
  char * someString;

  MemLock( OptrToHandle( @SomeStringChunk ) );
  someString = LMemDeref( @SomeStringChunk );

  /* use someString here */

  MemUnlock( OptrToHandle( @SomeStringChunk ) );
}