alright what's the deal?

void main () {
    alias int[3][4] fooz;
    int[3][4]* i = new fooz;
}


wiz.d(6): Error: new can only create structs, dynamic arrays or class objects, not int[3LU][4LU]'s

Ellery Newcomer:

> alright what's the deal?

This is one of the "clean" ways to do it:

void main () {
    static struct Mat {
        int[3][4] m;
        alias m this;
    }
    Mat* fooz = new Mat;
    fooz[1][3] = 5;
}


Bye,
bearophile

On 09/08/2012 04:19 AM, bearophile wrote:
> Ellery Newcomer:
>
>> alright what's the deal?
>
> This is one of the "clean" ways to do it:
>
> void main () {
>      static struct Mat {
>          int[3][4] m;
>          alias m this;
>      }
>      Mat* fooz = new Mat;
>      fooz[1][3] = 5;

This may corrupt your heap.

> }
>
>
> Bye,
> bearophile

I prefer this:

void main(){
    alias int[3][4] fooz;
    int[3][4]* i = (new fooz[1]).ptr;
}

But I think the original example should just work.

Timon Gehr:

> This may corrupt your heap.

I usually don't put the alis this...


> I prefer this:
>
> void main(){
>     alias int[3][4] fooz;
>     int[3][4]* i = (new fooz[1]).ptr;
> }

This allocates past the size of the array, the information to append to the array of fooz. It's a very little amount of memory.

Since some weeks, if you allocate a single struct that contains a single fixed size array, that memory is not allocated.

Bye,
bearophile

On 09/08/12 05:27, Timon Gehr wrote:
> On 09/08/2012 04:19 AM, bearophile wrote:
>> Ellery Newcomer:
>>
>>> alright what's the deal?
>>
>> This is one of the "clean" ways to do it:
>>
>> void main () {
>>      static struct Mat {
>>          int[3][4] m;
>>          alias m this;
>>      }
>>      Mat* fooz = new Mat;
>>      fooz[1][3] = 5;
> 
> This may corrupt your heap.

Yeah, this would be (the) one reason for introducing reference variables to the language; it's too easy right now to introduce such bugs (and if the code happens to compile it will just silently return bogus results).

It's a bit late for such a change (and making it more backwards compatible
by having refs that implicitly convert to pointers would be even more
confusing while not solving the problem).
Restricting certain operations on pointers-to-custom-types might work, but
also carries a cost (eg indexing pointers to such types wouldn't be possible
unless via a (temp) slice) as there probably already is code out there that
accesses arrays of indexable-structs via pointers...

artur

On 09/08/2012 01:21 PM, bearophile wrote:
> Timon Gehr:
>
>> This may corrupt your heap.
>
> I usually don't put the alis this...
>
>
>> I prefer this:
>>
>> void main(){
>>     alias int[3][4] fooz;
>>     int[3][4]* i = (new fooz[1]).ptr;
>> }
>
> This allocates past the size of the array, the information to append to
> the array of fooz. It's a very little amount of memory.
>
> Since some weeks, if you allocate a single struct that contains a single
> fixed size array, that memory is not allocated.
>
> Bye,
> bearophile

Wasn't aware that this got fixed. Thanks!