On 6/26/2013 6:33 PM, Michel Fortin wrote:
> Le 26-juin-2013 à 19:48, Walter Bright a écrit :
>
>> D (like C and C++) loves to manipulate pointers. Having to call a function
every time this is done would be a disaster. It means that people would be
motivated to drop down to C to do the fast code, and we might as well throw in
the towel.
> But at the same time, having a GC that stops the world at irregular interval
is worse for certain kind of things, games notably. It's been stated often on
the forum that game developers prefer increasing the overhead if it prevents
those hiccups. Making everything in D reference-counted would undoubtedly
increase the general overhead, but it'd allow game developers to leverage the
whole language and its libraries instead of restricting themselves to a custom
subset of the class hierarchy derived from a reference counted class.
>
> And about pointer manipulation: for cases where you know for certain that the
pointer still points to the same memory block before and after the assignment
(when you call popFront on an array for instance), you have no reference count
to update and can elide the call.
I've never seen a scheme for "knows for certain" that did not involve extensive
and intrusive pointer annotations, something we very much want to avoid. Pointer
annotations work great in theory, but in practice no successful language I know
of uses them (we'll see if Rust will become an exception).
>
> The downside of optional support for language-wide reference counting is that
it requires two incompatible codegen (or rather one incompatible with RC). We
could have only one if it's the one that calls the retain/release functions on
pointer assignment, with those functions replaced with empty stubs in druntime
when reference counting is disabled, but some overhead would remain for the
function call.
>
> I'm not claiming this is the right solution. It's just an idea I wanted to
mention as an aside because it has some common points. It is however a mostly
separate matter from your initial goal of supporting custom reference counting
schemes for some object hierarchies. I decided to write about it mostly because
you talked about reimplementing arrays using classes and that got me thinking.
But perhaps I shouldn't have mentioned it because it seems to be side-tracking
the discussion.
>
This proposal is modeled after C++'s shared_ptr<T> in that it should have
equivalent performance and capabilities. Since it has been well accepted into
the C++ "best practices", I think we're on solid ground with it.
