On 2010-11-04 16:09:26 -0400, "Steven Schveighoffer"
<[email protected]> said:
I just was saying that I prefer solutions where we don't bend the
entire language to cater to reference counting, if we can help it.
I'd rather bend the reference counting implementation to fit the
language. Something in the middle might be good too.
I just want to drop a note at this. I know it's not exactly the same
issue, but...
If you've read my plans for D/Objective-C, you'll have seen there's
automatic reference counting for Objective-C objects on the list.
There's obviously no plan to implement that for other things than
Objective-C objects in that document, but once it's implemented for one
type it'll trivial to allow it for other types.
I've thought throughly about the issue before choosing that direction.
There are two reasons to implement it in the compiler: easy of use and
efficiency of the generated code.
Cocoa traditionally has used explicit calls to retain/release (with
some help from autorelease). This is tedious and error-prone and looks
out of place in D. The D way would be to create a ref-counting struct
that wraps Objective-C objects and calls retain/release for you. But
the problem with that is you'd have to use this struct for each and
every Objective-C object reference and never forget to use it. We could
make the compiler forbid not wrapping Objective-C objects in this
struct, but at this point, why not make the compiler wrap the reference
in that struct transparently for you?
And if it comes to this, it's probably easier to just skip that
struct-wrapping scheme entirely and just issue calls to the relevant
function upon assignment and destruction of Objective-C object
reference. And this will probably open the door to optimization
opportunities. Changing an atomic reference count is expensive, but by
noting that any paired call to retain and release on the same object
has no effect you can avoid a lot of these calls. How many can be
avoided? Well, in theory, if the reference count when the object enters
the function is the same as the reference count when the object leaves
the function's code, then you don't have to touch the reference counter
at all. Any function that doesn't leak an object received as an
argument doesn't have to touch the reference count. That's a lot of
functions!
So in the end, I think that if reference-counting is going to be used,
even just moderately, it'd better be in the compiler for efficiency
reasons. That's only an advantage if you use atomic reference counting,
but it's the kind of thing that prevent ridiculous "optimizations" like
making function parameters 'ref' just to avoid touching the reference
counter... see:
<http://stackoverflow.com/questions/2502394/the-cost-of-passing-by-shared-ptr>
--
Michel Fortin
[email protected]
http://michelf.com/
