Forgot to add: As long as the returned type was the same. So
instead.. inputString = [inputString StringFromMyMethod];
On 6 Feb 2009, at 13:32, harry greenmonster wrote:
Yes, memory management is a weak point of mine, which I'm currently
trying to resolve. Last time I had any use for in-depth memory
management was 15 years ago. By posing these questions I'm hoping to
clear up grey areas, and they should not be taken as serious
proposals for addition to the Objective C language.
However, from a usability point of view, my points are still valid.
Code such as inputString = [inputString myMethod]; looks to me like
inputString data is no longer wanted, which in my case it wasn't.
The examples you put forward are fair arguments as to why not to
release objects in the manor I (somewhat unthinkingly) described.
But why can the compiler not replace the data at the memory location
pointed to by the old 'inputString' without making a second pointer
(with the same name). This would then pose no problems in the
scenarios you put forward.?
I presume there are valid reasons for not behaving in such a way also?
On 6 Feb 2009, at 12:07, Bryan Henry wrote:
It sounds to me like you want to use garbage collection, not manual
memory management.
Does C automatically free() memory when pointers get replaced? No,
obviously not. Doing so would be silly, and its even more silly to
want such behavior with Objective-C.
This:
inputString = [NSString string];
inputString = [inputString myMethod];
would crash once the local autorelease pool was emptied using the
behavior you described. You can't just willy nilly release objects.
If you reassign the pointer. Or, what about this:
inputString = [[NSString alloc] init];
someIvar = inputString;
inputString = [inputString myMethod];
Oops! someIvar now points to deallocated memory, and of course it
doesn't point to the "new" inputString.
The behavior you propose suggests a very narrow and underdeveloped
view on memory and memory management - there is no special
connection between an object and the variables that are pointers to
that object, and it seems to me that you think this on some level.
Manual memory management is just that - manual - you don't want to
compiler automatically releasing stuff for you.
Bryan
On Feb 6, 2009, at 5:24 AM, harry greenmonster wrote:
I cant help but think the preferable way Objective C should would
is to send a release automatically to the receiver of a product
of itself.
inputString = [inputString myMethod];
Its fairly clear in this situation that the original 'inputString'
is not wanted and needs to die, and would seem like a more
sensible way for the compiler to work as I struggle to think of a
situation where the old value serves any perpose, being that it is
now orphaned and useless.
Hence my confusion on the matter.
On 6 Feb 2009, at 03:17, Scott Ribe wrote:
So, how do I keep a copy hanging around AND kill the mysterious
new
copy then (which shares the same name as the old one presumably)?
2 pointer variables...
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/bryanhenry
%40mac.com
This email sent to bryanhe...@mac.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
