RFC: naming for FrontTransversal and Transversal ranges
rainerd at eldwood.com
Sat May 2 19:14:59 PDT 2009
Robert Jacques wrote:
> On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke <rainerd at eldwood.com>
>> 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.
Rainer Deyke - rainerd at eldwood.com
More information about the Digitalmars-d