🚀 go-pugleaf

In article <15mfliINNj9a@darkstar.UCSC.EDU> isbell@cats.ucsc.edu (Art Isbell)  
writes:
> const char *aStringPtr = "string";
> const char aString[] = "string";

The first declaration defines a NON-CONSTANT pointer var which INITIALLY
points to a constant string.  Total storage is 4 bytes more than for the
second case which defines a constant array.

On the NeXT, both the constant string and the constant array are stored in
memory which is actually write protected (and also shared if multiple copies
of the same program are executed simultaneously on the same machine).



> I've assumed that the memory referenced by aStringPtr is in some read-only
> heap area.  When aStringPtr is no longer needed, can this memory be freed
> with free(aStringPtr)?

NO!  The constant string is not allocated from a heap.  You can't free it,
and you can't ever change its contents.  (It really is a CONSTANT.)



> I've assumed that aString is a character array that's allocated on the stack 
> if aString is a local variable, so its memory is freed once the block in
> which it's defined is exited.

ALMOST true.  If aString is an "automatic" variable (i.e., not global or
static), then it is allocated on the stack.  But the NeXT compiler also creates
a static string, and initializes the array by COPYING the static string into it 
each time the function is called.



> If I say
> 	NXAtom anAtom = NXUniqueString("string");
> 	NXAtom anotherAtom = NXUniqueStringNoCopy("string");
> does "anAtom" point to a hashed copy of "string" so that memory is allocated  
> in 2 different places for "string"[?]

YES.


> [does] "anotherAtom" point to a hashed pointer to the heap memory 
> where "string" is found?

Well, that depends.  anotherAtom will *NEVER* point to "heap" memory (i.e.,
memory you can "free()"), but whether or not it points to the original string
or a copy of it depends on whether a copy of it already existed in the hash
table.  When you call NXWhateverNoCopy(foo), you are promising that you will
never change or free() the thing that foo points to.  The library may OR MAY 
NOT act more efficiently because of your promise.


> Should unique strings be used only for strings that are repeated throughout
> an app?

*THE* reason for using "unique strings" is that you can test them for equality
by comparing POINTERS instead of comparing byte-by-byte a la strcmp().  Several 
AppKit facilities (e.g., named image-reps and named sounds) make use of
this feature. 


> Storage's "free" does not free the type encoding string, so does this show up
> as a memory leak in MallocDebug?

Maybe you should try it for yourself and see what happens. :-)

HINT:  The Storage object remembers the pointer you give it, but it 
doesn't ever copy the string.

----------------+------------------+------------------------------------
     |\ /|      |  Jim Large       |  Visual Understanding Systems, Inc.
     | V |      |  jml@visus.com   |  2100 Wharton St.                  
   \_|   |__    |  (412)488-3600   |  Pittsburgh, PA  15203