On 2013-02-02 22:33, Steven Schveighoffer wrote:
> Heap block sizes start at 16.  One byte overhead is used to store the array
> length, so the minimum size of ANY array allocation is 15 bytes.

How is the length stored because I see only strange numbers in that byte.

    foreach (end; 2..31) {
        ubyte[] x;
        foreach (i; 0..end) {
            x ~= cast(ubyte)i;
        }
        writeln(x.length, " ", x.capacity, " ", x.ptr[end]);
    }

That code outputs following length/capacity/extra_byte:

2 15 69
3 15 0
4 15 100
5 15 26
6 15 36
7 15 0
8 15 0
9 15 0
10 15 0
11 15 0
12 15 0
13 15 0
14 15 0
15 15 15
16 31 0
17 31 0
18 31 0
19 31 0
20 31 0
21 31 0
22 31 0
23 31 0
24 31 0
25 31 0
26 31 0
27 31 0
28 31 0
29 31 0
30 31 0

Last byte's value for length == 2 is quite random on each execution.
In a smaller way also for length == 6. Other values seem constant.

My real question was: will we ever have fixed size arrays at runtime?

On 2013-02-02 22:57, FG wrote:
> On 2013-02-02 22:33, Steven Schveighoffer wrote:
>> Heap block sizes start at 16.  One byte overhead is used to store the array
>> length, so the minimum size of ANY array allocation is 15 bytes.
>
> How is the length stored because I see only strange numbers in that byte.
>
>      foreach (end; 2..31) {
>          ubyte[] x;
>          foreach (i; 0..end) {
>              x ~= cast(ubyte)i;
>          }
>          writeln(x.length, " ", x.capacity, " ", x.ptr[end]);
>      }
>

Ah, sorry. Silly me.
I have figured out that the length byte would have to be aligned to the end
of the block, so that is where I should look. The updated code:

    // size_t ends = [1,2,7,15,31]; // crashes DMD
    foreach (end; 2..31) {
        ubyte[] x;
        foreach (i; 0..end) {
            x ~= cast(ubyte)i;
        }
        writeln(x.length, " ", x.capacity, " ", x.ptr[x.capacity]);
    }
    return;

shows that indeed, there's length written at the end. :)
Output:

2 15 2
3 15 3
4 15 4
5 15 5
6 15 6
7 15 7
8 15 8
9 15 9
10 15 10
11 15 11
12 15 12
13 15 13
14 15 14
15 15 15
16 31 16
17 31 17
18 31 18
19 31 19
20 31 20
21 31 21
22 31 22
23 31 23
24 31 24
25 31 25
26 31 26
27 31 27
28 31 28
29 31 29
30 31 30

On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
> My real question was: will we ever have fixed size arrays at runtime?

I see no reason why we couldn't, the only problem is a syntax one. If you beat the syntax (by wrapping it in a struct) then you can do it no problem:

//----
T[N]* makeFixed(size_t N, T)()
{
    static struct Fixed
    {
        T[N] a;
    }
    auto p = new Fixed();
    return &((*p).a);
}

void main()
{
   int[4]* p4 = makeFixed!(4, int)();
}
//----

And there, a dynamically allocated fixed size array. I know it's not pretty, but it proves the point.

On 2013-02-02 22:47, monarch_dodra wrote:
> I suggest you read this:
> http://dlang.org/d-array-article.html
> It is a very interesting read, especially for those of us with C++ background.

Thank you for pointing me to that article.
I have read it months ago and forgotten the important parts.
Now it (slices & arrays) finally started making sense again. :)

On Saturday, 2 February 2013 at 22:39:58 UTC, monarch_dodra wrote:
> On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
>> My real question was: will we ever have fixed size arrays at runtime?
>
> I see no reason why we couldn't, the only problem is a syntax one. If you beat the syntax (by wrapping it in a struct) then you can do it no problem:
>
> //----
> T[N]* makeFixed(size_t N, T)()
> {
>     static struct Fixed
>     {
>         T[N] a;
>     }
>     auto p = new Fixed();
>     return &((*p).a);
> }
>
> void main()
> {
>    int[4]* p4 = makeFixed!(4, int)();
> }
> //----
>
> And there, a dynamically allocated fixed size array. I know it's not pretty, but it proves the point.

Sure and as I said: something like that I'm using currently. It is very ugly and because of that I asked for a built in solution, like new ubyte[size].
C have also runtime fixed size arrays.
But as far as I can see all your are fine with the wrapped struct solution.

> But as far as I can see all your are fine with the wrapped struct solution.

->
But as far as I can see, all of you are happy with the current wrapped struct solution.
----
We need an 'edit' button.

On Sunday, 3 February 2013 at 00:34:48 UTC, Namespace wrote:

> C have also runtime fixed size arrays.

They were added in C99 (variable length arrays, they're called). C++, on the other hand, still doesn't have them.

On Sunday, 3 February 2013 at 00:34:48 UTC, Namespace wrote:
> On Saturday, 2 February 2013 at 22:39:58 UTC, monarch_dodra wrote:
>> On Saturday, 2 February 2013 at 22:15:56 UTC, Namespace wrote:
>>> My real question was: will we ever have fixed size arrays at runtime?
>>
>> I see no reason why we couldn't, the only problem is a syntax one. If you beat the syntax (by wrapping it in a struct) then you can do it no problem:
>>
>> //----
>> T[N]* makeFixed(size_t N, T)()
>> {
>>    static struct Fixed
>>    {
>>        T[N] a;
>>    }
>>    auto p = new Fixed();
>>    return &((*p).a);
>> }
>>
>> void main()
>> {
>>   int[4]* p4 = makeFixed!(4, int)();
>> }
>> //----
>>
>> And there, a dynamically allocated fixed size array. I know it's not pretty, but it proves the point.
>
> Sure and as I said: something like that I'm using currently. It is very ugly and because of that I asked for a built in solution, like new ubyte[size].
> [SNIP]
> But as far as I can see all your are fine with the wrapped struct solution.

I never said I was happy with this solution! The problem is that the old "new int[4]" syntax is already taken and means "allocate a dynamic array of size 4".

> C have also runtime fixed size arrays.

C has "variable length arrays". That's not exactly the same same thing as allocating a fixed size array at runtime (apologies if I was confused by your requirement).

If you want variable length arrays, you should be able to do it with the low level "alloca".

Sure, but alloca has the same ugly interface as malloc. :/