Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: Chris Hanson <email@hidden>
- Date: Sun, 08 Jun 2008 20:48:03 -0700
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -- is a sequence point. The compiler
can't know what side-effects [data self] might have, so it can't re-
order the invocation to elsewhere.
This is not necessarily true. If the const and pure GCC
__attribute(())s were extended to objc methods then the compiler
would be free to perform common subexpression and loop invariant
code movement optimizations.
They can't be, while preserving the existing semantics of the
language. In the existing semantics, a message send always results in
a dynamic dispatch.
The 'self' message would definitely fall under the domain of these
attributes, thus the original argument is apropos.
For source compatibility, you almost certainly could *not* suddenly
indicate that "[foo self]; [foo self];" results in only one invocation
of -self by the compiler, at least for subclasses of NSObject or
NSProxy.
After all, a subclass of NSObject may have overridden -self to do
something else, and the compilation unit containing the above two
invocations may have no idea what the class of "foo" is with which to
make that judgment.
Obvious candidates are immutable objects 'length', 'count', etc,
which would result in a pretty big win if these attributes were
available.
If I write
- (void)doSomething:(NSArray *)array {
NSUInteger count1 = [array count];
NSUInteger count2 = [array count];
NSLog(@"%u", count1);
NSLog(@"%u", count2);
}
the compiler can't collapse those into a single invocation of -count.
After all, it could be passed a subclass of NSArray for whom -count
has side-effects. Think about a "thread-safe array" (as bad as the
concept might be) for example.
Adding additional attributes to make any new API contracts stricter is
an interesting idea, but it's likely to result in breakage of existing
code either at runtime or during compilation.
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden