RFC: naming for FrontTransversal and Transversal ranges

Robert Jacques sandford at jhu.edu
Sat May 2 21:02:09 PDT 2009

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

> Robert Jacques wrote:
>> On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke <rainerd at 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  

More information about the Digitalmars-d mailing list