I have a function defined as:

some_function(int[] array) { ... };  //this function does not ever modify values of array

When I call this function (once every program cycle) from an object using an array of type short:

//member variable in an object
short[] x = new short[4];

//object calls this
some_function([ x[0], x[1], x[2], x[3] ]);

After a few seconds of the program running, x[0] and x[1] values are set to 0 and a couple values of another array in the object are modified as well.

I have found that this bug is corrected by calling delete at the end of some_function of the variable array.  This tells me that the garbage collector is acting funny if I do not call delete on the array.  (I have watched the memory usage of the program and it doesn't fluctuate or pause or anything to signal the freeing/allocating of memory....)

Any Idea what is going on?

wolftousen wrote:
> I have a function defined as:
> 
> some_function(int[] array) { ... };  //this function does not ever modify values of array
> 
> When I call this function (once every program cycle) from an object using an array of type short:
> 
> //member variable in an object
> short[] x = new short[4];
> 
> //object calls this
> some_function([ x[0], x[1], x[2], x[3] ]);
> 
> After a few seconds of the program running, x[0] and x[1] values are set to 0 and a couple values of another array in the object are modified as well.
> 
> I have found that this bug is corrected by calling delete at the end of some_function of the variable array.  This tells me that the garbage collector is acting funny if I do not call delete on the array.  (I have watched the memory usage of the program and it doesn't fluctuate or pause or anything to signal the freeing/allocating of memory....)
> 
> Any Idea what is going on?

This sounds like something else is going on, although what I'm not sure.
  Maybe it's because I just woke up, but I can't see how that code could
compile anyway, since you can't pass a short[] to a function expecting
an int[].  Do you have a minimal, reproducible test case we can look at?

  -- Daniel

On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

>  Maybe it's because I just woke up, but I can't see how that code could compile anyway, since you can't pass a short[] to a function expecting an int[].

You missed the array literal.

Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 6:45 PM, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
> 
>>  Maybe it's because I just woke up, but I can't see how that code could
>> compile anyway, since you can't pass a short[] to a function expecting
>> an int[].
> 
> You missed the array literal.

I saw that, but thought that it would be a short[] literal since it's usually the type of the first argument.

  -- Daniel

On Tue, Feb 24, 2009 at 10:42 PM, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
>>
>> You missed the array literal.
>
> I saw that, but thought that it would be a short[] literal since it's usually the type of the first argument.

Odd, it works.  And properly too.

I give up on trying to figure out what the compiler does to figure out the type of array literals :P

Jarrett Billingsley wrote:
> On Tue, Feb 24, 2009 at 10:42 PM, Daniel Keep
> <daniel.keep.lists@gmail.com> wrote:
>>> You missed the array literal.
>> I saw that, but thought that it would be a short[] literal since it's
>> usually the type of the first argument.
> 
> Odd, it works.  And properly too.

Could it be because of integer promotion rules?

> I give up on trying to figure out what the compiler does to figure out
> the type of array literals :P

wolftousen wrote:
> I have a function defined as:
> 
> some_function(int[] array) { ... };  //this function does not ever modify values of array
> 
> When I call this function (once every program cycle) from an object using an array of type short:
> 
> //member variable in an object
> short[] x = new short[4];
> 
> //object calls this
> some_function([ x[0], x[1], x[2], x[3] ]);
> 
> After a few seconds of the program running, x[0] and x[1] values are set to 0 and a couple values of another array in the object are modified as well.
> 
> I have found that this bug is corrected by calling delete at the end of some_function of the variable array.  This tells me that the garbage collector is acting funny if I do not call delete on the array.  (I have watched the memory usage of the program and it doesn't fluctuate or pause or anything to signal the freeing/allocating of memory....)
> 
> Any Idea what is going on?

Can you use obj2asm and post the assembly of both functions? I'm guessing DMD is doing some kind of weird optimization with the array literal allocation.

wolftousen wrote:
> some_function([ x[0], x[1], x[2], x[3] ]);

That may also be written:
some_function(x[0 .. 4]);

Bye,
bearophile

On Thu, Mar 12, 2009 at 8:09 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> wolftousen wrote:
>> some_function([ x[0], x[1], x[2], x[3] ]);
>
> That may also be written:
> some_function(x[0 .. 4]);

Wrong types.

Jarrett Billingsley:
> Wrong types.

Right, I am sorry, thank you for spotting it.
There's the moderate need for a different kind of cast, for collections (arrays).
At the moment you can do:

import d.func: map, putr, array, xcast;
import std.conv: toInt;
import d.templates: ArrayType1;

void some_function(int[] x) {
    putr(typeid(typeof(x)), " ", x);
}

void main() {
    short[] x = [cast(short)10_000, 5_000, 100, 6_000, 50, 950];

    some_function(map((ArrayType1!(typeof(x)) s){return cast(int)s;}, x[0 .. 4]));

    // or less DRY:
    some_function(map((short s){return cast(int)s;}, x[0 .. 4]));

    // better:
    some_function(array(xcast!(int)(x[0 .. 4])));
}

The last version with array and xcast may be acceptable. The advantage of using it is that the ranges 0..4 can be variables.
Built-in types aren't constructors-functions, so you can't do something like this:

some_function(map(&int, x[0 .. 4]));

Bye,
bearophile