Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!hub.ucsb.edu!6600pete
From: 6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier])
Newsgroups: comp.sys.mac.programmer
Subject: Re: global data in Think C
Message-ID: <5137@hub.ucsb.edu>
Date: 7 May 90 17:33:45 GMT
References: <704@dimebox.cs.utexas.edu>
Sender: news@hub.ucsb.edu
Reply-To: 6600pete@ucsbuxa.ucsb.edu
Lines: 97

From article <704@dimebox.cs.utexas.edu>, by ted@cs.utexas.edu (Ted Woodward):
> Well, I just found out that string constants in Think C 4.0 get put into the
> global data segment...bad move, guys.  Because of this, I have 47K of 'global'
> data...

Standard practice is to use STR# resources, GetIndString, and StringHandle.
This won't help, of course, if you're porting a large chunk of someone
else's code, but it doesn't look like in this case that you are.

> So what do I try?  I try this:
> #define NUMELEMS 29
> Str32 *myArray;	/*yes, I did a #include <appletalk.h>*/
> 
> InitElms()
> {	myArray = (Str32 *) NewPtr(sizeof(Str32) * (long) NUMELMS);
> 	myArray[0] = "generic text here";
> }
> 
> and get 'illegal operation on array'.
>
> So I can't say:
> Str32 test;
> test = "stuff";

Looks to me like you are trying to declare a pointer to an array of Str32's,
which is fine, except you need to do something like this:

/****************************************************************************/
void pstrcat ( char *target, char *append ) {
	BlockMove ( &append [ 1 ], &target [ target [ 0 ] + 1 ], append [ 0 ] );
	target [ 0 ] = ( unsigned char ) target [ 0 ] + append [ 0 ];
}
 
#define NUMELEMS 29
 
typedef Str32 Str32Array [ 100 ]; /* arbitrary bounds */
Str32Array *myArray;
 
main ( ) {
	myArray = NewPtr ( sizeof ( Str32 ) * NUMELEMS );
	( * myArray ) [ 0 ] [ 0 ] = '\0';
	pstrcat ( ( char * ) & ( ( * myArray ) [ 0 ] ), "\pgeneric text here" );
	DebugStr ( ( char * ) & ( ( * myArray ) [ 0 ] ) );
}
/****************************************************************************/

pstrcat is necessary because you can't just assign a string constant to an
array of characters in C. The language is low-level enough that the designers
assumed people would be insulted if they couldn't optimize string operations
for their own architecture. (BlockMove happens to be VERY efficient.)
If you wrote a pstrcpy, you could omit one of the above lines, but I seldom
have need for a pstrcpy without a pstrcat.

Also, if you're going to be messing with Pascal data types, you should use
Pascal strings (note the "\p").

Finally, note that this particular solution does not help you, because it still
uses a string constant. But it might be instructive.

> I'd also like to be able to say something like this:
> myArray = {"generic1","genereic2",...}
> like in a declaration, so I can put the stuff in the heap instead of global
> space...

I'm not sure if I read you correctly. Here's what I interpret you to want:

/****************************************************************************/
main ( ) {
	char *myArray [ ] = { "\pa string", "\panother string" };
	DebugStr ( myArray [ 0 ] );
	DebugStr ( myArray [ 1 ] );
}
/****************************************************************************/

This is convenient, except that you're still stuck with string constants.

Here's how I'd do it in the heap:

/****************************************************************************/
main ( ) {
	Str255 s;
	StringHandle sh;
	GetIndString ( s, 128, 1 ); /* get first string out of 'STR#' ID 128 */
	sh = NewString ( s );
	DebugStr ( *sh );
}
/****************************************************************************/

This would be easy to expand to use an array of StringHandles. The strings are
easier to dereference then, but it's one more array you have to manage. It's
a trade-off. Also note that this fragment uses the Handle, which is a
relocatable heap object. They're not much fun in a big program, because
screwing one up inadvertently may take days to debug, but they make the Mac OS
possible, so you ought to use them as much as you can.
--
             Pete Gontier, Kiwi Software; Kiwi's opinions not presented here
InterNet 6600pete@ucsbuxa.ucsb.edu; BitNet 6600pete@ucsbuxa; AppleLink D0862