inout/out static array parameter

Tom Tom_member at pathlink.com
Wed Feb 22 03:42:15 PST 2006


In article <ops5dcznaa23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 22 Feb 2006 16:09:47 +1100, Derek Parnell <derek at psych.ward> wrote:
>> On Wed, 22 Feb 2006 17:16:30 +1300, Regan Heath wrote:
>>
>>> On Wed, 22 Feb 2006 14:15:32 +1100, Derek Parnell <derek at psych.ward>  
>>> wrote:
>>>> On Wed, 22 Feb 2006 03:02:22 +0000 (UTC), Tom wrote:
>>>>
>>>>> Why is this illegal? Where does the documentation states this?
>>>>> Does it have something to do with the matter that int[10] is allocated
>>>>> onto the
>>>>> stack? Sometimes I think D losses its abstraction capability when one
>>>>> has to be
>>>>> concerned about this kind of differences.
>>>>>
>>>>> 5# void f(inout int[10] x)
>>>>> 6# {
>>>>> 7# 	x[0..$] = 99;
>>>>> 8# }
>>>>>
>>>>> test.d(5): cannot have out or inout parameter of type int[10]
>>>>
>>>> I cannot see why D should be upset with this. The implementation would  
>>>> be
>>>> just be passing the address of the int[10] array, just as it does for
>>>> 'in' parameters.
>>>
>>> Not quite, when you pass something as 'in' you always get a copy of it,
>>> this is true even for arrays.

This isn't true:

void f(in int[10] x) 
{ 
x[0] = 99; 
}

int[10] i;
f(i);
printf("%d\n", i[0]); // prints '99'

So you get a copy of the pointer to the first element. That's plain useless for
everyone. I dream 'in' could protect content of the array someday.

This is far from abstract a programmer from what's really happening. If I code
something like:

void f(in int[10] x); 

Common sense will tell me that the 10 positions of my array are well protected
and they shouldn't be touched by 'f' and in return this isn't the behavior.
Walter with all respect, this sucks! When will we have real protection
attributes?

So the 'in' keyword for static arrays are perfectly useless and introduces
nothing (while in the background it is really "protecting" the pointer to the
first element -that doesn't need any protection-).

Regards,

Tom;



More information about the Digitalmars-d mailing list