I thought I'd make this it's own little thread..

I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...

struct foo {
  int a;
  int b;
  int c;
}

int foobar(foo _a) {
  foo a = _a;
}

I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Regan Heath wrote:

> I thought I'd make this it's own little thread..
>
> I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
>
> struct foo {
>   int a;
>   int b;
>   int c;
> }
>
> int foobar(foo _a) {
>   foo a = _a;
> }
>
> I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.
>

If your worried about efficiency, the compiler will optimise the code for the best case.  If you want to change the struct, pass it in as inout.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c96se7$ifr$2@digitaldaemon.com>, J Anderson says...
>
>Regan Heath wrote:
>
>> I thought I'd make this it's own little thread..
>>
>> I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
>>
>> struct foo {
>>   int a;
>>   int b;
>>   int c;
>> }
>>
>> int foobar(foo _a) {
>>   foo a = _a;
>> }
>>
>> I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.
>>
>
>If your worried about efficiency, the compiler will optimise the code for the best case.  If you want to change the struct, pass it in as inout.
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

I disagree JA. As I said in the other thread on this topic, if you have an exported function that takes a struct param, how can the caller of that function know wether it takes a ref or value, unless its in the prototype? D really needs to nail this one, and I wish Walter would comment on it.

imr1984 wrote:

>In article <c96se7$ifr$2@digitaldaemon.com>, J Anderson says...
>  
>
>>Regan Heath wrote:
>>
>>    
>>
>>>I thought I'd make this it's own little thread..
>>>
>>>I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
>>>
>>>struct foo {
>>>  int a;
>>>  int b;
>>>  int c;
>>>}
>>>
>>>int foobar(foo _a) {
>>>  foo a = _a;
>>>}
>>>
>>>I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.
>>>
>>>      
>>>
>>If your worried about efficiency, the compiler will optimise the code for the best case.  If you want to change the struct, pass it in as inout.
>>
>>-- 
>>-Anderson: http://badmama.com.au/~anderson/
>>    
>>
>
>I disagree JA. As I said in the other thread on this topic, if you have an
>exported function that takes a struct param, how can the caller of that function
>know wether it takes a ref or value, unless its in the prototype? D really needs
>to nail this one, and I wish Walter would comment on it.
>  
>
When the function is exported it can be labelled with what type of struct it requires.  Of course if its a C function then you have no choice.

-- 
-Anderson: http://badmama.com.au/~anderson/

What about a simple, intuitive a logical "refin" keyword?

imr1984 wrote:

> In article <c96se7$ifr$2@digitaldaemon.com>, J Anderson says...

> I disagree JA. As I said in the other thread on this topic, if you have an exported function that takes a struct param, how can the caller of that function know wether it takes a ref or value, unless its in the prototype? D really needs to nail this one, and I wish Walter would comment on it.

Regan Heath wrote:
> I thought I'd make this it's own little thread..
> 
> I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
> 
> struct foo {
>   int a;
>   int b;
>   int c;
> }
> 
> int foobar(foo _a) {
>   foo a = _a;
> }
> 
> I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.

In the case of extern(D), I agree.  In the case of very small structs, the compiler is presumably smart enough to be able to automatically create a copy on the stack, thereby mitigating any speed loss due to an extra dereference.

 -- andy

only c is that dump that it doesn't export the way you have to pass parameters, and what parameters... even c++ does export the whole info..

"imr1984" <imr1984_member@pathlink.com> schrieb im Newsbeitrag news:c97691$10vd$1@digitaldaemon.com...
> In article <c96se7$ifr$2@digitaldaemon.com>, J Anderson says...
> >
> >Regan Heath wrote:
> >
> >> I thought I'd make this it's own little thread..
> >>
> >> I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
> >>
> >> struct foo {
> >>   int a;
> >>   int b;
> >>   int c;
> >> }
> >>
> >> int foobar(foo _a) {
> >>   foo a = _a;
> >> }
> >>
> >> I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.
> >>
> >
> >If your worried about efficiency, the compiler will optimise the code for the best case.  If you want to change the struct, pass it in as
inout.
> >
> >-- 
> >-Anderson: http://badmama.com.au/~anderson/
>
> I disagree JA. As I said in the other thread on this topic, if you have an exported function that takes a struct param, how can the caller of that
function
> know wether it takes a ref or value, unless its in the prototype? D really
needs
> to nail this one, and I wish Walter would comment on it.
>
>

In article <c9801q$27d1$1@digitaldaemon.com>, davepermen says...
>
>only c is that dump that it doesn't export the way you have to pass parameters, and what parameters... even c++ does export the whole info..

C has a well documented policy: all arguments are always "in".  If the parameter is a pointer, you can modify what it points to, but the argument, the pointer itself, is copied.  Another example of the C language philosophy: the programmer understands what the code does but the language just copies bytes.  C provides just enough abstraction to hide differences in assembler languages.  Whether you passing the data in or out or just preventing optimization of that variable, is not the language's concern (in C).

Kevin

On Fri, 28 May 2004 16:15:06 +0800, J Anderson <REMOVEanderson@badmama.com.au> wrote:
> Regan Heath wrote:
>
>> I thought I'd make this it's own little thread..
>>
>> I think that structs should be passed by reference, not value, if you want to copy-in a struct you can by simply saying...
>>
>> struct foo {
>>   int a;
>>   int b;
>>   int c;
>> }
>>
>> int foobar(foo _a) {
>>   foo a = _a;
>> }
>>
>> I work as a C programmer, so I don't use classes etc, only structs, and I pretty much *always* pass a pointer to a struct not a struct itself.
>>
>
> If your worried about efficiency, the compiler will optimise the code for the best case. If you want to change the struct, pass it in as inout.

I was worried about efficiency, but also ... so you're saying D will pass my large structs by reference, not value?

Ok, next question.

If I pass a struct (it gets passed as an 'in' parameter by default) can the function modify it, what happens if it does? From what you say above it can have 2 different effects depending on whether the compiler optimized it or not.

I think this is bad.

I think 'in' should mean pass by reference AND cannot be modified. The latter causing a compile time error.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

but the caller doesn't KNOW what to pass in, and get back, actually.. (in
linking stage)

"Kevin Bealer" <Kevin_member@pathlink.com> schrieb im Newsbeitrag news:c9c2qf$1vl6$1@digitaldaemon.com...
> In article <c9801q$27d1$1@digitaldaemon.com>, davepermen says...
> >
> >only c is that dump that it doesn't export the way you have to pass parameters, and what parameters... even c++ does export the whole info..
>
> C has a well documented policy: all arguments are always "in".  If the
parameter
> is a pointer, you can modify what it points to, but the argument, the
pointer
> itself, is copied.  Another example of the C language philosophy: the
programmer
> understands what the code does but the language just copies bytes.  C
provides
> just enough abstraction to hide differences in assembler languages.
Whether you
> passing the data in or out or just preventing optimization of that
variable, is
> not the language's concern (in C).
>
> Kevin
>
>
>