I have a function setFoo, that autoreleases the current instance and then
set it to the new one coming in and retains it.

However I think there is a flaw in doing it this way that occurs if the
value incoming is the same as the one that already exists because if the
autorelease actually occurs before the retain in the next statement then it
will fail.

i.e.

- (void) setFoo:(id)inValue
{
[foo autorelease];
foo = [inValue retain];
}

If inValue is the same object as foo then if the autorelease occurs before
the following retain then we would be trying to retain an invalid object at
that point assuming that it is released because the reference count went to
zero.

The following should be safer in the situation where inValue is the same
object as foo!?

- (void) setFoo:(id)inValue
{
[inValue retain];
[foo autorelease];
foo = inValue;
}

Any comments appreciated - Arthur Lewis

From:	Samuel Hornus
Subject:	Re: Setting an instance variable
Date:	Thu, 18 Nov 2004 16:39:17 +0100

On Thu, 04 Nov 2004 20:07:43 GMT, David Stes wrote:

>
> It's just more people who will investigate autorelease pools, and see that
> it is poor technology.

Hi!
What would you advise to me, as an alternative to autorelease ?

Thanks !
--
Samuel Hornus

From:	Christian Brunschen
Subject:	Re: Setting an instance variable
Date:	18 Nov 2004 19:03:47 GMT

In article <20041118163917.567ff59d.SamueldotHornusatinriadotfr@nospam.com>,
Samuel Hornus wrote:
>On Thu, 04 Nov 2004 20:07:43 GMT, David Stes wrote:
>
>> It's just more people who will investigate autorelease pools, and see that
>> it is poor technology.
>
>Hi!
>What would you advise to me, as an alternative to autorelease ?

The options for memory management in Objective-C are essentially these:

1) Completely manual - aka '+new / -free'
This approach follows the standard C memory management (malloc()/free()),
and means that the lifecycle of any object has to be managed entirely by
the developer. This can lead to many interesting problems,
difficult-to-track bugs, and so on, and is generally the option that
requires most work for the developer.

2) Automatic Garbage Collection (gc)
This is the approach that is used in languages like Smalltalk, Java, etc.
This approach requires that the underlying C system use garbage collection
as well. Essentially, the garbage collector keeps track of which memory is
still in use, and deallocates any other unused memory as needed. But gc is
not a magic solution, even Java programs have memory leaks, and many
developers who use gc get out of the habit of thinking about memory usage,
which can come back to bite them. This approach generally requires the
least work from the developer, but instead demands that a gc system be in
place, which is not usually the case in C-based languages.

3) Manual Reference Counting - 'retain / release'
A system, such as the one used by Apple's Cocoa, where the number of
references to each object is counted, where the reference counts are
updated manually by the developer, and where objects are deallocated when
their reference count goes to 0. In Apple's Cocoa, incrementing an
object's retain count is known as 'retaining' the object and decrementing
the count is known as 'releasing' it (from the messages 'retain' and
'release', respectively). Such a system can be implemented entirely in the
class library, and requires no extra support such as a garbage collector
does.

3a) Manual Reference Counting with delayed release - 'autorelease'
A system that uses reference counting, but in addition offers a facility
for delayed releasing - where the developer can say 'release this object,
but not immediately; *I* don't need this object, but someone else may
assert ownership before the object gets deallocated'. This allows, for
instance, a method to create an object and delayed-release it; if the
caller of the method wishes to claim the object, they can retain it, but
if not, then the object will be actually released and deallocated at some
later time. In Apple's Cocoa, the delayed-release facility is known as an
'autorelease pool', implemented by the NSAutoreleasePool class, and
offered on object through their 'autorelease' method. Again, this can be
implemented entirely in the class library.

[ David Stes' POC also offers a compiler-managed reference counting
option; that, however, has significant problems and is only offered by
POC, not by any modern or serious compiler, and is not really an option
for most uses. ]

I hope this explains some of the issues.

>Thanks !

Best wishes,

>Samuel Hornus

// Christian Brunschen

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 11:13:09 -0500

Arthur J. Lewis wrote:

> I have a function setFoo, that autoreleases the current instance and then
> set it to the new one coming in and retains it.
>
> However I think there is a flaw in doing it this way that occurs if the
> value incoming is the same as the one that already exists because if the
> autorelease actually occurs before the retain in the next statement then it
> will fail.

This is really a library issue, so it probably should have been sent to
a Cocoa- or Mac-oriented list. Having said that...

This isn't Java. Garbage collection doesn't happen behind your back at
random times. Autorelease pools' behavior is predictable and documented.
The autorelease pools that Cocoa automatically creates as part of its
event loop are created at the beginning and released at the end of each
iteration through the loop.

If you're creating your own autorelease pool for whatever reason, that's
obviously only released when you release it - no mysteries there either.

So, you *can* create the problem you're describing, but you'd have to do
it yourself, by releasing the current pool before you call retain.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 17:22:10 GMT

Sherm Pendley wrote:
>
> This is really a library issue, so it probably should have been sent to
> a Cocoa- or Mac-oriented list. Having said that...
>
> This isn't Java.

This is an absurd argument.

First you say that it is a library issue.
Next, you compare with a language.

This is a wrong comparison; you don't have to compare Apple Objective-C
with Java.

You have to compare the Apple variant of Objective-C with regular Objective-C.

Real Objective-C doesn't use this silly NSObject class, it uses Object, and
normal regular standard Objective-C doesn't use the brain-dead autorelease
stuff.

From:	Michael Ash
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 11:35:53 -0600

David Stes wrote:
> Sherm Pendley wrote:
>>
>> This is really a library issue, so it probably should have been sent to
>> a Cocoa- or Mac-oriented list. Having said that...
>>
>> This isn't Java.
>
> This is an absurd argument.
>
> First you say that it is a library issue.
> Next, you compare with a language.

"Java" refers to a language, a set of standard libraries, a virtual
machine, and probably some other stuff I forgot. Unlike Objective-C, Java
has an official standard which covers all of these aspects.

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 19:25:58 GMT

Michael Ash wrote:
>
> Unlike Objective-C, Java
> has an official standard which covers all of these aspects.

Objective-C has specification sheets as well.

In the specification sheet of Object you can find for example that there
is a selector +poseAs: that an Object implementation should implement.

Unfortunately some people seem to have reading problems, as they call their
selector +poseAsClass: instead of +poseAs:

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 14:31:50 -0500

David Stes wrote:

> In the specification sheet of Object you can find

.... a history lesson. After you dust it off, that is - it hasn't been
used in ten years.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 19:53:14 GMT

Sherm Pendley wrote:
>
> ... a history lesson. After you dust it off, that is - it hasn't been
> used in ten years.

If you didn't read the specification sheets, then I'm sorry for you,
you then obviously do not know what the standard selectors should be like.

For a user, I can imagine that you are not sufficiently specialized in the
matter anyway, so it is normal and reasonable that you didn't read about the
subject in detail.

For somebody who implements an Objective-C runtime and attempts to write a
memory management, of course, such a person should have some qualification
on reading skills, basic literacy, some basic knowledge on the literature
in this area.

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 15:27:10 -0500

David Stes wrote:

> obviously do not know what the standard selectors should be like.

I don't know COBOL, Sather, PL/1, SNOBOL, BCPL or FORTRAN either, and
I've pretty much forgotten the 370 Assembly and JCL I once knew.

I'm not losing any sleep over it.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Fri, 05 Nov 2004 05:57:11 GMT

Sherm Pendley wrote:

> I've pretty much forgotten the 370 Assembly and JCL I once knew.

Apple's autorelease pool crap is the kind of spaghetti code you can also
safely forget.

Apple's medieval and backward technology belongs on the pile of unused
languages just like their spaghetti assembly language code.

From:	J.F.Costa
Subject:	Please, please give up (was Re: Setting an instance variable)
Date:	23 Nov 2004 04:56:15 -0800

David Stes wrote in message news:...
> Sherm Pendley wrote:
>
> > I've pretty much forgotten the 370 Assembly and JCL I once knew.
>
> Apple's autorelease pool crap is the kind of spaghetti code you can also
> safely forget.
>
> Apple's medieval and backward technology belongs on the pile of unused
> languages just like their spaghetti assembly language code.

Don't you get tired of ignoring the facts and using the same
delusional poor arguments over and over again? Why don't you go ahead
and buy yourself a Mac and actually use XCode to see if Apple's
libraries and implementation of Objective-C are really as bad as you
think, practically? Two things might come from that: either you'll be
jolted back to reality or you'll be taken outright by denial, finish
your path to complete insanity and end up in the loony-bin, where
hopefully you won't be allowed near a computer and thus won't be able
to litter this newsgroup with your useless messages any longer.
Overall, humanity will profit from both outcomes. Be sympathetic,
think of the greater good. Do us all this favour.

J.F.Costa

From:	Gregory Weston
Subject:	Re: Please, please give up (was Re: Setting an instance variable)
Date:	Wed, 24 Nov 2004 00:48:26 GMT

In article <2cc5f345.0411230456.5615f4f6@posting.google.com>,
jfaac@bol.com.br (J.F.Costa) wrote:

> David Stes wrote in message
> news:...
> > Sherm Pendley wrote:
> >
> > > I've pretty much forgotten the 370 Assembly and JCL I once knew.
> >
> > Apple's autorelease pool crap is the kind of spaghetti code you can also
> > safely forget.
> >
> > Apple's medieval and backward technology belongs on the pile of unused
> > languages just like their spaghetti assembly language code.
>
> Don't you get tired of ignoring the facts and using the same
> delusional poor arguments over and over again? Why don't you go ahead
> and buy yourself a Mac and actually use XCode to see if Apple's
> libraries and implementation of Objective-C are really as bad as you
> think, practically?

Because he doesn't "think." He "knows." If you know something you don't
have to prove it. If you haven't been following Stes Wars very long,
stay tuned. You'll notice that he won't even spend the time it takes to
read, so there's no way he's going to spend actual money finding out
what's real.

G

--
Change account to gw when responding by mail.

From:	J.F.Costa
Subject:	Re: Please, please give up (was Re: Setting an instance variable)
Date:	25 Nov 2004 05:36:57 -0800

Gregory Weston wrote in message news:...
> In article <2cc5f345.0411230456.5615f4f6@posting.google.com>,
> jfaac@bol.com.br (J.F.Costa) wrote:
>
> > David Stes wrote in message
> > news:...
> > > Sherm Pendley wrote:
> > >
> > > > I've pretty much forgotten the 370 Assembly and JCL I once knew.
> > >
> > > Apple's autorelease pool crap is the kind of spaghetti code you can also
> > > safely forget.
> > >
> > > Apple's medieval and backward technology belongs on the pile of unused
> > > languages just like their spaghetti assembly language code.
> >
> > Don't you get tired of ignoring the facts and using the same
> > delusional poor arguments over and over again? Why don't you go ahead
> > and buy yourself a Mac and actually use XCode to see if Apple's
> > libraries and implementation of Objective-C are really as bad as you
> > think, practically?
>
> Because he doesn't "think." He "knows." If you know something you don't
> have to prove it. If you haven't been following Stes Wars very long,
> stay tuned. You'll notice that he won't even spend the time it takes to
> read, so there's no way he's going to spend actual money finding out
> what's real.
>
> G

Faith is the opposite of reason.

J.F.Costa

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 12:43:00 -0500

David Stes wrote:

> Sherm Pendley wrote:
>
>>This isn't Java.
>
>
> This is an absurd argument.

The point of the comparison is that autorelease pools are released at
well-defined points. Unlike the automatic garbage collection provided by
Java, autorelease pools are neither invisible nor unpredictable. They
would have to be both for the concerns expressed in the original message
to be valid.

The question of whether Java's GC is implemented as part of the
language, the class library, or the VM is irrelevant. It's the behavior
that I'm comparing, not the implementation details.

> Real Objective-C

.... is defined by Apple, not you. Get over it.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	Christian Brunschen
Subject:	Re: Setting an instance variable
Date:	4 Nov 2004 17:29:23 GMT

In article <6ztid.11393$qg2.603190@phobos.telenet-ops.be>,
David Stes wrote:
>Sherm Pendley wrote:
>>
>> This is really a library issue, so it probably should have been sent to
>> a Cocoa- or Mac-oriented list. Having said that...
>>
>> This isn't Java.
>
>This is an absurd argument.

Actually, it's not.

>First you say that it is a library issue.

It is.

>Next, you compare with a language.

Not really. Java is a complete platform - containing both a language, a
runtime system, and a standard class library. In this case, 'This' -
meaning the Objective-C language combined with the Cocoa class lbiraries -
is indeed not Java.

>This is a wrong comparison; you don't have to compare Apple Objective-C
>with Java.
>
>You have to compare the Apple variant of Objective-C with regular Objective-C.

Except, of course, since Apple are the providers of the Objective-C
language (through documentation and theough the most widely spread
implementation, as well as owning the trademark etc), Apple's Objective-C
*is* regular Objective-C.

>Real Objective-C doesn't use this silly NSObject class, it uses Object, and
>normal regular standard Objective-C doesn't use the brain-dead autorelease
>stuff.

Suffice it to say that David Stes' views of the Objective-C language and
the classes that are available for it do not quite match reality.

Best wishes,

// Christian Brunschen

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 19:22:29 GMT

Christian Brunschen wrote:
>
> Not really. Java is a complete platform - containing both a language, a
> runtime system, and a standard class library.

If this is your definition of "complete platform" then I do not see why
that title applies to Objective-C.

Objective-C is syntax, runtime system and the standard Object class.

It is not because some particular commercial low-quality OS makes the
mistake of not using the standard runtime system and standard Object class,
that this changes that Objective-C on its own is a complete platform.

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 14:55:22 -0500

David Stes wrote:

> It is not because some particular commercial low-quality OS makes the
> mistake of not using the standard runtime system and standard Object class,

Apple shipped 836,000 Macs in the quarter (three months) ending in Sept.
2004. They made $106 million in net profit on revenues of $2.35 billion.

Let us know when POC catches up with Apple's "mistake".

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	David Stes
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 20:07:43 GMT

Sherm Pendley wrote:
>
> Apple shipped 836,000 Macs in the quarter (three months) ending in Sept.
> 2004. They made $106 million in net profit on revenues of $2.35 billion.

Fine by me.

It's just more people who will investigate autorelease pools, and see that
it is poor technology.

From:	Sherm Pendley
Subject:	Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 15:36:14 -0500

David Stes wrote:

> Fine by me.
>
> It's just more people who will investigate autorelease pools, and see that
> it is poor technology.

A hungry fox noticed a juicy bunch of grapes growing high on a
grapevine. He leaped. He snapped. Drooling, he jumped to reach them, but
try as he might, he could not obtain the tasty prize.

Disappointed by the fruitless efforts he'd made to get the grapes that
day, he said, with a shrug, to comfort himself, "Oh, they were probably
sour anyway!"

-- Aesop's Fables

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	Sherm Pendley
Subject:	[OT] Re: Setting an instance variable
Date:	Thu, 04 Nov 2004 15:38:18 -0500

Sherm Pendley wrote:

> Disappointed by the fruitless efforts

You know, I first read that over thirty years ago, and I hadn't noticed
that pun until today. "Fruitless" efforts? :-)

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

From:	Christian Brunschen
Subject:	Re: Setting an instance variable
Date:	4 Nov 2004 16:18:01 GMT

In article ,
Arthur J. Lewis wrote:
>I have a function setFoo, that autoreleases the current instance and then
>set it to the new one coming in and retains it.
>
>However I think there is a flaw in doing it this way that occurs if the
>value incoming is the same as the one that already exists because if the
>autorelease actually occurs before the retain in the next statement then it
>will fail.
>
>i.e.
>
>- (void) setFoo:(id)inValue
>{
> [foo autorelease];
> foo = [inValue retain];
>}
>
>If inValue is the same object as foo then if the autorelease occurs before
>the following retain then we would be trying to retain an invalid object at
>that point assuming that it is released because the reference count went to
>zero.

No. Remember, 'autorelease' will only actually release the objects in its
pool, when the pool itself is deallocated. Is is 'release' which
decrements the object's retain count immediately, but you're not using
that here.

Assume that you're using the same object as the 'foo' value. It will have
a retain count of (x) as the method is entered. '[foo autorelease]' does
*not* change its retain count, but simply marks it in the current
autorelease pool as 'this needs releasing later'. 'foo = [inValue retain]'
then increments foo's retainCount by one. So at the end of the method, foo
has a retain count of (x+1), and will be released once by the current
autoreleasepool when that is deallcoated, reducing the retain cound to (x)
again in the process. At no time does the retain count go below (x) in
this sequence of events.

>The following should be safer in the situation where inValue is the same
>object as foo!?
>
>- (void) setFoo:(id)inValue
>{
> [inValue retain];
> [foo autorelease];
> foo = inValue;
>}

This is exactly as safe, but no safer.

>Any comments appreciated - Arthur Lewis

Best wishes,

// Christian

From:	screetch
Subject:	Re: Setting an instance variable
Date:	5 Nov 2004 00:51:31 -0800

cb@df.lth.se (Christian Brunschen) wrote in message news:...
> >The following should be safer in the situation where inValue is the same
> >object as foo!?
> >
> >- (void) setFoo:(id)inValue
> >{
> > [inValue retain];
> > [foo autorelease];
> > foo = inValue;
> >}
>
> This is exactly as safe, but no safer.
>

Right. If you wanted to release it though then this would be incorrect :
- (void) setFoo:(id)inValue
{
[foo release];
foo = [inValue retain];
/* if inValue=foo then inValue may have been dealloc'ed previously :-( */
}

and, you're right, this would be correct :

- (void) setFoo:(id)inValue
{
[inValue retain];
[foo release];
foo = inValue
}

except that, Christian is right, there is no such problem with autorelease pools

> Best wishes,

Thanx for the clear answer with no pending debate to come :-)
>
> // Christian

From:	Glenn Andreas
Subject:	Re: Setting an instance variable
Date:	Fri, 05 Nov 2004 08:46:20 -0600

In article ,
screetch@gmail.com (screetch) wrote:

> cb@df.lth.se (Christian Brunschen) wrote in message
> news:...
> > >The following should be safer in the situation where inValue is the same
> > >object as foo!?
> > >
> > >- (void) setFoo:(id)inValue
> > >{
> > > [inValue retain];
> > > [foo autorelease];
> > > foo = inValue;
> > >}
> >
> > This is exactly as safe, but no safer.
> >
>
> Right. If you wanted to release it though then this would be incorrect :
> - (void) setFoo:(id)inValue
> {
> [foo release];
> foo = [inValue retain];
> /* if inValue=foo then inValue may have been dealloc'ed previously :-( */
> }
>
> and, you're right, this would be correct :
>
> - (void) setFoo:(id)inValue
> {
> [inValue retain];
> [foo release];
> foo = inValue
> }
>

Actually, something could return something other value as a result of
"retain" and so this should be:

inValue = [inValue retain];

From:	Christian Brunschen
Subject:	Re: Setting an instance variable
Date:	5 Nov 2004 15:05:28 GMT

In article ,
Glenn Andreas wrote:
>Actually, something could return something other value as a result of
>"retain"

Actually, no - that would be contrary to the documentation of the 'retain'
method in the NSObject protocol.

retain

- (id)retain
Increments the receiver's reference count. You send an object a retain
message when you want to prevent it from being deallocated without your
express permission.

An object is deallocated automatically when its reference count reaches 0.
retain messages increment the reference count, and release messages
decrement it. For more information on this mechanism, see Memory
Management.

As a convenience, retain returns self because it is often used in nested
expressions:

NSString *systemApps= [[NSString stringWithCString:"/Applications"] retain];

You would implement this method only if you were defining your own
reference-counting scheme. Such implementations must return self and
should not invoke the inherited method by sending a retain message to
super.

See Also: - autorelease, - release, - retainCount

In particular: "Such implementations must return self [ ... ]". In other
words, only the object that is the receiver of the 'retain' method is a
valid return value from that method. If anything else is returned, that is
in breach of the NSObject protocol.

Best wishes,

// Christian Brunschen

From:	Glenn Andreas
Subject:	Re: Setting an instance variable
Date:	Fri, 05 Nov 2004 16:03:26 -0600

In article ,
cb@df.lth.se (Christian Brunschen) wrote:

> In article ,
> Glenn Andreas wrote:
> >Actually, something could return something other value as a result of
> >"retain"
>
> In particular: "Such implementations must return self [ ... ]". In other
> words, only the object that is the receiver of the 'retain' method is a
> valid return value from that method. If anything else is returned, that is
> in breach of the NSObject protocol.
>
> Best wishes,
>
> // Christian Brunschen

I stand corrected (well, actually, I'm sitting).

It's "init" and its ilk that can (and often does) return something else
(and so one should always write "self = [super init];" and not just
"[super init];")