inout/out static array parameter

Tom Tom_member at pathlink.com
Wed Feb 22 06:30:34 PST 2006


In article <ops5dii4gc23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 22 Feb 2006 11:42:15 +0000 (UTC), Tom <Tom_member at pathlink.com>  
>wrote:
>> 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:
>
>Yes, it is. The key is realising what it is you're actually passing, in  
>this case an array reference. You're not passing the data which is in the  
>array, just the reference to it.

I know, I thought you meant that 'in' makes a copy of the whole array, not the
pointer to it. There's no copy of the array itself.

>> 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.
>
>See my last reply. The thing you get a copy of is the array reference, not  
>the data to which it refers. 

Think my post declares clearly that I KNOW THAT.

>The array reference is a pointer which points  
>to the location in memory where the array data is stored, this address is  
>also the location of the first array element, much like:
>
>char *p = strdup("this is a test");
>
>the address to which p points is the location of the character 't' from  
>the word 'this'. A fixed-length array is very similar to a plain old  
>pointer, except it also has array bounds checking and a hard coded length  
>available, plus useful array operations.

Agree.

>See the docs Derek posted in his last reply, 'in' does not promise to  
>protect the data to which the array reference refers, only the array  
>reference itself.

Sorry, I didn't understand Derek copied that from docs -in fact I can't find
that in the docs [please guide me with a link if you do]-, but rather I think
that is his own version of what he think the docs should state (or what has to
be added to the docs).

>
>> 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.
>
>I think everyone (including Walter) wants us to be able to do this sort of  
>thing. Whether it's a good idea isn't really in doubt, what is, is how it  
>can be implemented.

I thought I heared that Walter doesn't like the idea of const (that is
definitely what in last instance we're talking about), because it can be
circumvented with some black magic (or hackish coding). I didn't know he was up
to implement that sort of thing (real 'in' parameters). Are you sure?

>> Walter with all respect, this sucks! When will we have real protection
>> attributes?
>
>I suspect we'll have them as soon as Walter devises a way to implement  
>them to his satisfaction.

Hope so.

>> 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-).
>
>The 'in' keyword behaves the same way for arrays, classes and any other  
>reference type, it protects the reference itself, not the data to which  
>the reference refers.

Now that you've say it about a 100 times :-D, I ask: When would we have REAL
PROTECION ATTRIBUTES FOR REFERENCED DATA RATHER THAN FOR REFERENCES ITSELF
(readonly)? 

Regards,

Tom;



More information about the Digitalmars-d mailing list