[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC Distributed Object behavior for pointers
From: |
Willem Rein Oudshoorn |
Subject: |
Re: RFC Distributed Object behavior for pointers |
Date: |
13 Apr 2003 10:32:08 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Richard Frith-Macdonald <address@hidden> writes:
> DO supports return of pointer values and passing of them as arguments.
[text SNIPPED]
> in NeXTstep, the memory holding the returned data was owned by the
> *caller*, so you had to do -
>
> char *ptr = [obj methodReturningACString];
> // Use ptr
> if ([obj isProxy]) free(ptr);
>
> I don't know how OPENSTEP does this ...
> Does it work like NeXTstep or does it return a pointer to autoreleased
> memory?
I hope I can check coming week.
>
> How should GNUstep do it?
> Do we want to make the calling code check to see if it is calling a
> method via DO, and free the memory explicity, or do we want to use
> autoreleased memory for consistency with the way objects are returned,
> and have the caller copy the contents of the memory if it wants to
> keep it?
> The second form seems better to me, but I don't know what OPENSTEP does.
What about a third alternative?
- tie the lifespan of the returned memory to the lifespan of the proxy
object.
This seems more consistent, for example:
------ Ordinary situation ------------------------
const void *ptr = [anNSDataObject bytes];
// ptr is valid as long as NSData is valid.
------ Proxy situation ---------------------------
const void *ptr = [aProxyForNSData bytes];
// ptr is valid as long as the proxy is valid.
--------------------------------------------------
This is slightly different from the autorelease case,
for example when:
-----
CREATE AUTORELEASE POOL
proxy = get proxy object
CREATE INNER AUTORELEASE POOL
void *ptr = [proxy bytes];
DESTROY INNER AUTORELEASE POOL
ptr valid ?????????????
----
This just occured to me after reading your question and I
have not spent much time thinking about the pros and cons.
Wim Oudshoorn.