On 6/28/2013 2:03 PM, Rainer Schuetze wrote:
> On 28.06.2013 22:29, Walter Bright wrote:
>>
>> On 6/28/2013 1:11 PM, Rainer Schuetze wrote:
>>> On 28.06.2013 21:50, Walter Bright wrote:
>>>> The main problem with this is the decay of a shared_ptr!C to a C. Once
>>>> that happens, all the memory safety goes out the window.
>>>
>>> By "decay", do mean the lowering or something else?
>>>
>>> There is no stray C reference in user code, it always gets lowered to
>>> shared_ptr!C. Only @trusted code in shared_ptr will have to deal with
>>> "raw" references. It is shared_ptr's responsibilty to maintain memory
>>> safety, just the same as for AddRef and Release.
>>>
>>
>> "Decay" means it is converted to type C in order to call functions that
>> take C as the 'this' pointer or C as a parameter. The problem is both
>> type C and type shared_ptr!C will exist.
>>
>
> Any parameter of type C is also lowered to shared_ptr!C.
I don't see how lowering C to shared_ptr!C and lowering share_ptr!C to C can
work?
> Calling a member function would go through opDot, which could also do
reference counting for safety. Treating every explicite or implicite usage of
"this" as a temporary shared_ptr!C might be overkill, so it could be restricted
to assigning "this" to another reference (this includes passing it as an
argument to another function or returning it from a function). My current adhoc
rule: if "this" is not followed by a '.', it has to be lowered to construct
shared_ptr!C(this).
>
> Assuming the reference count is updated by shared_ptr!C.opDot, there will
always be a thread local reference while inside a member function (it must have
been called through an external reference at least once). Other member functions
of the same object can always be called without ref-counting assuming that the
object never gets destroyed through changing other references.
>
