May 03, 2009
On Sat, 02 May 2009 22:14:59 -0400, Rainer Deyke <rainerd@eldwood.com> wrote:

> Robert Jacques wrote:
>> On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke <rainerd@eldwood.com>
>> wrote:
>>> Given a value type 'T', you have the guarantee that no two variables of
>>> type 'T' can alias each other.  This guarantee is preserved when the
>>> type 'T' is non-copyable.
>>>
>>> An argument of type 'ref T' can obviously alias a variable of type 'T'.
>>
>> Okay, if T is not copyable, then I _must_ pass it as ref T, everywhere.
>> Which is reference semantics.
>
> When passing arguments, (possibly const) ref is a reasonable default.  I
> don't care about how arguments are passed.  I care about aliasing
> between variables, especially member variables.
>
> With reference semantics, two variables of type T can reference each
> other.  With non-copyable types, they cannot.
>
>>>>>   - RAII.
>>>>
>>>> Can be done with structs or classes. Also see point 1. So, this isn't a
>>>> pro/con either way.
>>>
>>> The D1 dynamic array type does not support RAII.
>>
>> There are two parts to D's arrays. One a struct 2 words long, the other
>> is a chunk of ram. The first part is RAII, the second part is not
>> possible, since D doesn't allow dynamically sized memory allocation on
>> the stack.
>
> It's meaningless to talk about RAII in the context of the "struct" part
> of a D1 dynamic array, since it doesn't manage any resources.  If I
> place a variable of a RAII type in a D1 dynamic array, it is not
> properly destroyed when the array goes out of scope.  Therefore D1
> dynamic arrays do not support RAII.
>
> Stack versus heap allocation is an orthogonal issue.

RAII is all about stack allocation over heap allocation (or so I thought). Ah, wikipedia has set me straight. Anyways, now for the simple answer: you can't create D1 arrays with RAII types, I think. (Anyone tried scope Foo[] foo?) Anyways, in D2, if I remember correctly there's a bug where struct finilizers don't run if they're allocated on the heap. But if you're using classes for RAII like you should, the GC will run their finalizers just fine after the array dies. But this is an seems to be an issue about the elements/values inside the containers, not the container itself. So I'm lost.
May 03, 2009
Robert Jacques wrote:
> RAII is all about stack allocation over heap allocation (or so I thought). Ah, wikipedia has set me straight. Anyways, now for the simple answer: you can't create D1 arrays with RAII types, I think. (Anyone tried scope Foo[] foo?) Anyways, in D2, if I remember correctly there's a bug where struct finilizers don't run if they're allocated on the heap. But if you're using classes for RAII like you should, the GC will run their finalizers just fine after the array dies. But this is an seems to be an issue about the elements/values inside the containers, not the container itself. So I'm lost.

A RAII variable is "destroyed" when it goes out of scope, where "destroyed" means that a destructor is called.  RAII is a transitive feature.  When a RAII variable is destroyed, its members are also destroyed.  When a RAII container is destroyed, all of its contents are destroyed.

References in D are not RAII types, because when a reference goes out of scope, the "contents" of that reference are not destroyed until the garbage decides to collect them, at which point it is too late to perform clean-up.

When an array dies, its contents are destroyed.  The issue is when the array dies.

If the array is a value type, the array dies when it goes out of scope, so RAII is possible.

If the array is a reference type, the array dies when the garbage collector decides to run sometime after all live references to the array have died, so RAII is not possible.


-- 
Rainer Deyke - rainerd@eldwood.com
May 03, 2009
Rainer Deyke wrote:
> Robert Jacques wrote:
>> RAII is all about stack allocation over heap allocation (or so I
>> thought). Ah, wikipedia has set me straight. Anyways, now for the simple
>> answer: you can't create D1 arrays with RAII types, I think. (Anyone
>> tried scope Foo[] foo?) Anyways, in D2, if I remember correctly there's
>> a bug where struct finilizers don't run if they're allocated on the
>> heap. But if you're using classes for RAII like you should, the GC will
>> run their finalizers just fine after the array dies. But this is an
>> seems to be an issue about the elements/values inside the containers,
>> not the container itself. So I'm lost.
> 
> A RAII variable is "destroyed" when it goes out of scope, where
> "destroyed" means that a destructor is called.  RAII is a transitive
> feature.  When a RAII variable is destroyed, its members are also
> destroyed.  When a RAII container is destroyed, all of its contents are
> destroyed.
> 
> References in D are not RAII types, because when a reference goes out of
> scope, the "contents" of that reference are not destroyed until the
> garbage decides to collect them, at which point it is too late to
> perform clean-up.
> 
> When an array dies, its contents are destroyed.  The issue is when the
> array dies.
> 
> If the array is a value type, the array dies when it goes out of scope,
> so RAII is possible.
> 
> If the array is a reference type, the array dies when the garbage
> collector decides to run sometime after all live references to the array
> have died, so RAII is not possible.

RAII can be implemented even with reference semantics. The mechanics would involve reference counting.

Andrei
May 04, 2009
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> If the array is a reference type, the array dies when the garbage collector decides to run sometime after all live references to the array have died, so RAII is not possible.
> 
> RAII can be implemented even with reference semantics. The mechanics would involve reference counting.

Granted, although reference counting comes with its own set of issues.


-- 
Rainer Deyke - rainerd@eldwood.com
May 04, 2009
Andrei Alexandrescu, el  3 de mayo a las 11:55 me escribiste:
> >If the array is a reference type, the array dies when the garbage collector decides to run sometime after all live references to the array have died, so RAII is not possible.
> 
> RAII can be implemented even with reference semantics. The mechanics would involve reference counting.

I was not following this discussion, so I might be speaking out of ignorance, but I thing you are underestimating the problems of reference counting again.

Circular references break it, and when comes to RAII, you probably loose the ordering guarantees it needs if you implement some kind of algorithm to deal with cycles.

Another option is trust the program be smart enough not to create cycles (weark references can help a lot here), but if the RC is hidden in the language it can be a little hard to remember this restriction.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
1 2 3 4 5 6 7 8 9 10
Next ›   Last »