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 ) ); }