btw,

short a,b,c;

a = b + c; //error: cannot implicitly convert expression of type 'int' to 'short'

Guys!! Tell me that I have an old slutty version of the compiler...

On Tuesday, 29 April 2014 at 06:13:52 UTC, Andrey wrote:
> Ok, thanks a lot..
>
> About dynamic arrays: I haven't found any information about internal representation of the D structures. E.g. do dynamic arrays have reference counter?
>
> Nevermind, I'm gonna use Type2[0] syntax.

D dynamic arrays (better referred to as slices) can be thought of as implmented like

struct Array(T)
{
    T* ptr;
    size_t length;
}

They do not track ownership or have any reference counting. If they've been allocated with "new" then the GC will take care of them once there are no remaining references to them.

On Tuesday, 29 April 2014 at 07:43:55 UTC, Andrey wrote:
> btw,
>
> short a,b,c;
>
> a = b + c; //error: cannot implicitly convert expression of type 'int' to 'short'
>
> Guys!! Tell me that I have an old slutty version of the compiler...

No, it's correct. `b + c` is not guaranteed to fit into `a`, therefore you have to cast it explicitly.

On Tue, 29 Apr 2014 03:43:54 -0400, Andrey <none@none.no> wrote:

> btw,
>
> short a,b,c;
>
> a = b + c; //error: cannot implicitly convert expression of type 'int' to 'short'
>
> Guys!! Tell me that I have an old slutty version of the compiler...

No. It's due to integer promotion. All operations are done at the int level, so the expression b + c is actually an int. C allows this transgression because it's convenient. D makes you acknowledge that you are throwing away bits the compiler generated for you.

Note, += does work:

a = b;
a += c;

-Steve

On 04/29/2014 01:36 AM, John Colvin wrote:

> D dynamic arrays (better referred to as slices) can be thought of as
> implmented like
>
> struct Array(T)
> {
>      T* ptr;
>      size_t length;
> }
>
> They do not track ownership or have any reference counting. If they've
> been allocated with "new" then the GC will take care of them once there
> are no remaining references to them.

That may be misleading because there is no need to allocate with an explicit new. For example, the slice below is owned by the GC as well:

int[] foo()
{
    int[] a;
    a ~= 42;    // on memory owned by the GC
    return a;
}

Ali

On Tuesday, 29 April 2014 at 16:52:27 UTC, Ali Çehreli wrote:
> That may be misleading because there is no need to allocate with an explicit new. For example, the slice below is owned by the GC as well:
>
> int[] foo()
> {
>     int[] a;
>     a ~= 42;    // on memory owned by the GC
>     return a;
> }

I didn't realize this was possible... I figured it was equivalent to
`null ~= 42` which I realize now is not correct, because a is not entirely a reference type. I'm not sure how I feel about this.

On 04/29/2014 10:01 AM, Meta wrote:

> On Tuesday, 29 April 2014 at 16:52:27 UTC, Ali Çehreli wrote:
>> That may be misleading because there is no need to allocate with an
>> explicit new. For example, the slice below is owned by the GC as well:
>>
>> int[] foo()
>> {
>>     int[] a;

a is an empty slice, ready for use.

>>     a ~= 42;    // on memory owned by the GC

Since there is no room for the new element, an area large enough for the new element and for some more is allocated from the GC. Now a is a handle to that one element.

Adding the following line reveals that the memory that has just been allocate has room for more elements:

    writeln(a.capacity);    // printed 3 for me

>>     return a;
>> }

Yes, a's life ends but the slice that is being returned from the function is still alive. So, the GC does not free the memory yet.

Ali

On 4/29/2014 10:01 AM, Meta wrote:
> On Tuesday, 29 April 2014 at 16:52:27 UTC, Ali Çehreli wrote:
>> [...]
>> int[] foo()
>> {
>>     int[] a;
>>     a ~= 42;    // on memory owned by the GC
>>     return a;
>> }
>
> I didn't realize this was possible... I figured it was equivalent to
> `null ~= 42` which I realize now is not correct, because a is not
> entirely a reference type. I'm not sure how I feel about this.

Yeah, arrays and AAs sit in a no-man's-land between reference types and value types. :(  I don't know that I've seen this precedent in any other language...

Dave