[Openmcl-devel] Is this a feature?

Gary Byers gb at clozure.com
Fri Feb 15 17:06:30 PST 2008

It makes a little bit of sense if the string is a constant, e.g.,
turning "foo" into #@"foo" for you.  The #@"" syntax creates something
called an NSConstantCString, which can be allocated anywhere in memory
and is never freed.  (NSConstantCStrings are intended to be used
as compile-time literal strings in ObjC; they can be created at 
compile-time by the ObjC compiler (or in our case, at read time.)
We -could- do this as a compiler transform, at least in theory.
(If we did that, then for every case that we catch we could also
warn "hey, you forgot the #@ !")

It's a more complicated issue if the string is not a compile-time
constant.  We could continue to call ... um, whatever it's called ...
to map lisp strings to NSStrings, but that raises memory management
questions: shoould we map the lisp string to an NSConstantString
(possibly gradually filling memory with unique NSConstantStrings
that were intended to be short-lived), or should we create 
dynamic NSStrings?  In the latter case, who frees them, and when ?
It becomes less obvious that doing this is the right thing.

One compromise would be to say "ok,we'll create the NSString for
you at rumtime, but we'll autorelease it (essentially, arrange
that #/release is called on the next iteration of the event loop.)
If whatever you're calling expects the string to persist longer
than that, it needs to #/retain the string in order to ensure that."

I remember that Matt and I discussed this in email a few months agoand
I seem to remember that we concluded that the best thing would be to
deprecate the automatic coercion and gradually phase it out.  It's
fairly easy to DWIM far enough to say "oh, you meant to use an
NSString instead of a lisp string here" but harder to know how that
NSString should be constructed to satisfy the expectations of whatever
you're calling."

As it's currently implemented, we create an NSString every time you
pass a lisp string to an ObjC method, and never release that NSString.
If you do this often enough in a loop, you'll eventually notice that
memory's filling up with these things.  If you do it occasionally.
you might find that the convenience outweighs concerns about leaking
a few dozen bytes here and there ...

On Fri, 15 Feb 2008, Ron Garret wrote:

> Today I accidentally passed a Lisp string into an Objective C function
> that expected an ns-string, and to my pleasant surprise it did the
> Right Thing.  A cursory exploration indicates that this behavior is
> general.  Is this a feature?  Can I safely rely on this behavior?  (Is
> this why the ns-lisp-string function is so carefully hidden away?  :-)
> rg
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list