http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #8 from andrei@metalanguage.com  2008-02-25 19:24 -------
(In reply to comment #7)
> but that still doesn't solve the base issue: I want a function to return a pointer to a chunk of memory that is 4 ints in a row (or it is that as best the compiler can tell).
> 
> (Err. I hope that is understandable)

I don't understand. Doesn't this work?

int[4]* foo() {
    static int[4] x;
    return &x;
}

?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #9 from shro8822@vandals.uidaho.edu  2008-02-25 22:26 -------
I don't think so; that is a pointer to a pointer to a string of 4 ints (or a string of 4 pointers to ints, I can never parse those by eye) it has one too many levels of indirection.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #10 from andrei@metalanguage.com  2008-02-25 22:48 -------
(In reply to comment #9)
> I don't think so; that is a pointer to a pointer to a string of 4 ints (or a string of 4 pointers to ints, I can never parse those by eye) it has one too many levels of indirection.

I'm completely lost. float[4]* has exactly one level of indirection.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #11 from shro8822@vandals.uidaho.edu  2008-02-25 23:11 -------
traditionally arrays are worked by pointer math. While the array is a segment of memory, its manifestation in the code is as a pointer. So "i[2]" takes a pointer adds an offset of 2 and does the IO. From this "int[4]*" will be a pointer to something that can be used like a an array, e.i. it will be a pointer to a somewhat hidden pointer.

IIRC back in C, the compiler didn't make any distinction between an array name and a pointer. In fact they don't worry about what is the array and what is the index.

This actually works (or did at one point):

int i[10];
7[i] = 4;


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #12 from andrei@metalanguage.com  2008-02-26 01:12 -------
(In reply to comment #11)
> traditionally arrays are worked by pointer math. While the array is a segment of memory, its manifestation in the code is as a pointer. So "i[2]" takes a pointer adds an offset of 2 and does the IO. From this "int[4]*" will be a pointer to something that can be used like a an array, e.i. it will be a pointer to a somewhat hidden pointer.

That is incorrect. There is no hidden pointer and no extra indirection. There is a confusion somewhere along the way, so please let me give an example:

void main()
{
    int a[4];
    int[4]* b = &a;
    a[1] = 2;
    (*b)[1] = 3;
}

Say that the four ints in a start at address 1000. Then a is an immutable pointer with value 1000. Also, b is a rebindable pointer with value 1000. Dereferencing b takes you straight to the first element of a, not to some hidden pointer that in turn takes you to the first element of a.


-- 

On 26/02/2008, d-bugmail@puremagic.com <d-bugmail@puremagic.com> wrote:
>  but that still doesn't solve the base issue: I want a function to return a
>  pointer to a chunk of memory that is 4 ints in a row (or it is that as best the
>  compiler can tell).

    int[] f()
    {
        return [1,2,3,4].dup;
    }

or

    int[] f()
    {
        auto r = new int[4];
        /* assign r's elements */
        return r;
    }

If you need to prove that the array is exactly four bytes long, do

    int[] f()
    out(r)
    {
        assert(r.length == 4);
    }
    body
    {
        ...
    }

If you really, really need to return by value, do

    struct A(T, int N)
    {
        T[N] a;
    }

    A!(int,4) f()
    {
        A!(int,4) r;
        /* assign r.a */
        return r;
    }

Hopefully, one of these will suit your needs

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #14 from jason@spashett.com  2008-02-26 04:26 -------
Thanks for the comments, it's more or less as I suspected. The ways of returning an arrays pointed out by Janice Caron and others seem to feel like a 'workaround' to me.

I don't quite understand why the code below does not (or cannot work). The pass by reference semantics of arrays don't have to apply for function return do they? It might create a special case though I suppose.


int[4][4] f()
{
    int a[4][4];
    return a;
}


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #15 from andrei@metalanguage.com  2008-02-26 10:53 -------
(In reply to comment #14)
> Thanks for the comments, it's more or less as I suspected. The ways of returning an arrays pointed out by Janice Caron and others seem to feel like a 'workaround' to me.
> 
> I don't quite understand why the code below does not (or cannot work). The pass by reference semantics of arrays don't have to apply for function return do they? It might create a special case though I suppose.
> 
> 
> int[4][4] f()
> {
>     int a[4][4];
>     return a;
> }

This will work. We'll also pass arrays in by value, and will bind literals to dynamically-sized arrays.

In response to Derek: this is the "right thing" because every type in D has the same copy semantics whether it sits inside a struct or not. Every type... except statically-sized arrays.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1869





------- Comment #16 from jason@spashett.com  2008-02-26 11:08 -------
(In reply to comment #15)
...
> This will work. We'll also pass arrays in by value, and will bind literals to dynamically-sized arrays.
> 
> In response to Derek: this is the "right thing" because every type in D has the same copy semantics whether it sits inside a struct or not. Every type... except statically-sized arrays.
> 
Ok, I understand now. Seems good. This change will be in DMD 2.x at some future point.

I should of posted to digitalmars.d for this sort of thing instead of raising this as a bug shouldn't I?


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1869
> 
> 
> 
> 
> 
> ------- Comment #16 from jason@spashett.com  2008-02-26 11:08 -------
> (In reply to comment #15)
> ...
>> This will work. We'll also pass arrays in by value, and will bind literals to
>> dynamically-sized arrays.
>>
>> In response to Derek: this is the "right thing" because every type in D has the
>> same copy semantics whether it sits inside a struct or not. Every type...
>> except statically-sized arrays. 
>>
> Ok, I understand now. Seems good. This change will be in DMD 2.x at some future
> point. 
> 
> I should of posted to digitalmars.d for this sort of thing instead of raising
> this as a bug shouldn't I?

digitalmars.d.learn, in fact.
However, you wouldn't have gotten this useful feedback from Andrei over there, because he doesn't read (or at least reply to) the NG's.  So it's hard to say you did the wrong thing here.

--bb