On 6/27/2013 1:15 PM, Michel Fortin wrote:
> Le 27-juin-2013 à 15:32, Walter Bright a écrit :
>
>> On 6/27/2013 11:38 AM, Michel Fortin wrote:
>>>> 14. RC objects will still be allocated on the GC heap - this means that a
normal
>>>> GC run will reap RC objects that are in a cycle, and RC objects will get
automatically
>>>> scanned for heap references with no additional action required by the user.
>>> If you allocate the object from the GC heap, the GC will collect it
regardless of its reference count. That's fine as long as all the retaining
pointers are visible to the GC. But if you're defining a COM object, likely
that's because you'll pass a pointer to an external API, and this API might
store the pointer somewhere not scanned by the GC. This API will call AddRef to
make sure the object is retained, but if the GC doesn't see that pointer on its
heap it'll deallocate and next time external code uses the object everything
goes boom! So that doesn't work.
>> We already require that if you're going to pass a pointer to any GC
allocated data to external code, that you retain a pointer. I see no additional
issue with requiring this for COM objects created on the GC heap.
>
> Perhaps it's just me, but I'd say if you need to anticipate the duration for
which you need to keep the object alive when you pass it to some external code
it completely defeats the purpose of said external code calling AddRef and Release.
>
> With the scheme you propose, reference counting would be useful inside D code
as a way to deallocate some classes of objects early without waiting a GC scan.
The GC can collect cycles for those objects.
>
> People passing COM objects to external code however should allocate those
objects outside of the GC if they intend to pass the object to external code.
They should also add member pointers as GC roots. Also, no cycle detection for
those objects. If done right it could be made memory safe, but cycles will leak.
>
> Maybe that could work.
>
Nothing about the proposal acts to prevent one from constructing COM objects any
way they wish, including using malloc/free and managing it all themselves. All
COM objects require is an implementation of the COM interface, which says
nothing at all beyond having a pointer to an AddRef() and Release().
If you are building a COM object that is to be fired and forgotten into the void
of unknown external code, I don't think there's any automated replacement for
thinking carefully about it and constructing it accordingly. D's memory safety
guarantees cannot, of course, cover unknown and unknowable external code.
What I'm trying to accomplish with this proposal is:
1. A way to do ref-counted memory allocation for specific objects
2. Do it in a guaranteed memory safe manner (at least for the user of those
objects)
3. Do it in a way that does not interfere with people who want to use the GC or
do manual memory management
4. Not impose penalties on non-refcounted code
5. Do it in a way that offers a similar performance and overhead profile to
C++'s shared_ptr<T>
6. Do it in a way that makes it usable to construct COM objects, and work with
NSObject's
7. Not require pointer annotations
8. Address the most common "why I can't use D" complaint
What I'm not trying to accomplish is:
1. Replacing all memory allocation in D with ref counting
