For this member function:

	float[4][4] toFloatArray4x4()
	{
		float f[4][4];
		return f;
	}

I get:
Error: functions cannot return static array float[4u][4u]

Is it the case that you can't return static arrays? Thinking about this it may make some sense. Should I therefore return a float[][] (which will always be a float [4]4]. I intend to assign it to a static float[4][4] in most cases.

Or rather, should I use an out/ref parameter like so:

toFloatArray4x4(ref float f[4][4])


I was also hoping to define a operator "overload" cast operator, but if I can't 'return' static arrays then this will not work.

I can return a struct from a function, why not a static array? I can sort of see why this might not work since D objects and types are more dynamic oriented than in C and C++ but it seems unnecessary to construct an object on the heap ( a float[][] ) just to return it and assign it to a static array.

Using:

Digital Mars D Compiler v1.026
Copyright (c) 1999-2008 by Digital Mars written by Walter Bright

Spacen Jasset wrote:

> For this member function:
> 
> float[4][4] toFloatArray4x4()
> {
> float f[4][4];
> return f;
> }

This looks like doing the following in C++:
C toC(){
  C c;
  return c;
}

Which is an error (regardless of what the compiler says).  c is allocated on the heap and is deallocated when the function exits.  It may be that the same effect is happening here.  I'm sure this kind of thing could get fixed in a similar way to how full closures were fixed...

Jason House wrote:

> Spacen Jasset wrote:
> 
>> For this member function:
>> 
>> float[4][4] toFloatArray4x4()
>> {
>> float f[4][4];
>> return f;
>> }
> 
> This looks like doing the following in C++:
> C toC(){
>   C c;
>   return c;
> }
> 
> Which is an error (regardless of what the compiler says).  c is allocated
> on
> the heap and is deallocated when the function exits.  It may be that the
> same effect is happening here.  I'm sure this kind of thing could get
> fixed in a similar way to how full closures were fixed...

I don't know why I said heap instead of stack, but I should have said stack.

"Jason House" <jason.james.house@gmail.com> wrote in message news:fpl0tk$hco$1@digitalmars.com...
>
> This looks like doing the following in C++:
> C toC(){
>  C c;
>  return c;
> }
>
> Which is an error (regardless of what the compiler says).  c is allocated
> on
> the heap and is deallocated when the function exits.  It may be that the
> same effect is happening here.  I'm sure this kind of thing could get
> fixed
> in a similar way to how full closures were fixed...

Not at all.. that declaration of 'c' has nothing to do with the heap, it's allocated on the stack, and when you return it, you're returning it by value.  This is valid C++ code AFAIK.

I think you're thinking of _this_:

char* something()
{
    char foo[10];
    return foo;
}

Which _is_ illegal, because foo is allocated on the stack and you can't return arrays by value in C/C++.

Which, coincidentally, is why you can't return statically-sized arrays in D, since they're supposed to be "C-like" in many ways.

"Jason House" <jason.james.house@gmail.com> wrote in message news:fpl144$hco$2@digitalmars.com...

> I don't know why I said heap instead of stack, but I should have said stack.

Fair enough :) but your snippet is still valid as the class/struct C is returned by value.

Jarrett Billingsley wrote:

> "Jason House" <jason.james.house@gmail.com> wrote in message news:fpl144$hco$2@digitalmars.com...
> 
>> I don't know why I said heap instead of stack, but I should have said stack.
> 
> Fair enough :) but your snippet is still valid as the class/struct C is returned by value.

you're totally right.  I had way too many errors in one post.  Thankfully this is a D newsgroup and nobody will notice ;)  I should have made the return type C&.  This is common practice in C++ to avoid copying the class.

On Thu, 21 Feb 2008 23:00:51 +0000, Spacen Jasset wrote:

> For this member function:
> 
> 	float[4][4] toFloatArray4x4()
> 	{
> 		float f[4][4];
> 		return f;
> 	}
> 
> I get:
> Error: functions cannot return static array float[4u][4u]

On a related note, why can't D handle 'ref' and 'out' static arrays either? In other words, this below won't compile...

  void toFloatArray4x4(ref float[4][4] p) ...

So what is the rationale for that?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 10:48:36 AM

Jason House wrote:
> Jason House wrote:
> 
>> Spacen Jasset wrote:
>>
>>> For this member function:
>>>
>>> float[4][4] toFloatArray4x4()
>>> {
>>> float f[4][4];
>>> return f;
>>> }
>> This looks like doing the following in C++:
>> C toC(){
>>   C c;
>>   return c;
>> }
>>
>> Which is an error (regardless of what the compiler says).  c is allocated
>> on
>> the heap and is deallocated when the function exits.  It may be that the
>> same effect is happening here.  I'm sure this kind of thing could get
>> fixed in a similar way to how full closures were fixed...
> 
> I don't know why I said heap instead of stack, but I should have said stack.
Hmm. That's legal in both C and C++ and works so long as 'C' isn't a pointer or array (otherwise you get a leak). I suppose then, that you could argue it's the same in D given that I was trying to return an array.

On the other hand I observe that D arrays do not decompose into pointers like the do in C and C++ and so I guess I was expecting that returning an array would be possible since its more or less a proper 'object' unlike in C or C++. Returning a static array could then work in exactly the same way as returning a struct in D since they are fixed size and static in nature.

Anyway, it seems it's not possible, and so I wonder what (in general) would be the way to go, return a float[][] object, or use a ( ref float[][] ) to pass the value back out, any suggestions?

Spacen Jasset wrote:
> Jason House wrote:
>> Jason House wrote:
>>
>>> Spacen Jasset wrote:
>>>
>>>> For this member function:
>>>>
>>>> float[4][4] toFloatArray4x4()
>>>> {
>>>> float f[4][4];
>>>> return f;
>>>> }
>>> This looks like doing the following in C++:
>>> C toC(){
>>>   C c;
>>>   return c;
>>> }
>>>
>>> Which is an error (regardless of what the compiler says).  c is allocated
>>> on
>>> the heap and is deallocated when the function exits.  It may be that the
>>> same effect is happening here.  I'm sure this kind of thing could get
>>> fixed in a similar way to how full closures were fixed...
>>
>> I don't know why I said heap instead of stack, but I should have said stack.
> Hmm. That's legal in both C and C++ and works so long as 'C' isn't a pointer or array (otherwise you get a leak). I suppose then, that you could argue it's the same in D given that I was trying to return an array.
> 
> On the other hand I observe that D arrays do not decompose into pointers like the do in C and C++ and so I guess I was expecting that returning an array would be possible since its more or less a proper 'object' unlike in C or C++. Returning a static array could then work in exactly the same way as returning a struct in D since they are fixed size and static in nature.
> 
> Anyway, it seems it's not possible, and so I wonder what (in general) would be the way to go, return a float[][] object, or use a ( ref float[][] ) to pass the value back out, any suggestions?
I have just realized that arrays are symantically pass by reference always whereas structs are value types, and so that is why you cannot return a static array.

Another solution to my problem is of course to use a Boxer for a float[16] and return that I guess.

Derek Parnell wrote:
> On Thu, 21 Feb 2008 23:00:51 +0000, Spacen Jasset wrote:
> 
>> For this member function:
>>
>> 	float[4][4] toFloatArray4x4()
>> 	{
>> 		float f[4][4];
>> 		return f;
>> 	}
>>
>> I get:
>> Error: functions cannot return static array float[4u][4u]
> 
> On a related note, why can't D handle 'ref' and 'out' static arrays either?
> In other words, this below won't compile...
> 
>   void toFloatArray4x4(ref float[4][4] p) ...
> 
> So what is the rationale for that?
> 
See my post above yours. arrays have pass by reference semantics unlike stucts, ints and other basic types.