ok i asked about this before and i was told that if you pass a large struct parameter by value, the compiler will optomize it to pass by ref if it finds that the function doesnt change the function param. Is this absolutely certain? I often find myself worrying if thats actually the case and just pass a pointer to the struct like i did when using C.

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c8inrv$13jl$1@digitaldaemon.com...
> ok i asked about this before and i was told that if you pass a large
struct
> parameter by value, the compiler will optomize it to pass by ref if it
finds
> that the function doesnt change the function param. Is this absolutely
certain?
> I often find myself worrying if thats actually the case and just pass a
pointer
> to the struct like i did when using C.
>
>

I think you better pass it with a pointer. I don't think it is possible for a compiler to fully understand how things are used...it may be the case that the struct is implicitely modified in a set of deeply nested functions.

I think the variable passing semantics of D are weird: it is a mixture of C (not C++!) and Java: from one hand, we have pointers and structures and the C world, from the other hand, we have Java with references.

I wish it as simpler, as in C++: pass by reference, pass by value, independently of the data type.

yeah i agree with you. Walter would you like to comment on this ? This really needs to be more clearly documented in the spec.

In article <c8nldq$slf$1@digitaldaemon.com>, Achilleas Margaritis says...
>
>
>"imr1984" <imr1984_member@pathlink.com> wrote in message news:c8inrv$13jl$1@digitaldaemon.com...
>> ok i asked about this before and i was told that if you pass a large
>struct
>> parameter by value, the compiler will optomize it to pass by ref if it
>finds
>> that the function doesnt change the function param. Is this absolutely
>certain?
>> I often find myself worrying if thats actually the case and just pass a
>pointer
>> to the struct like i did when using C.
>>
>>
>
>I think you better pass it with a pointer. I don't think it is possible for a compiler to fully understand how things are used...it may be the case that the struct is implicitely modified in a set of deeply nested functions.
>
>I think the variable passing semantics of D are weird: it is a mixture of C (not C++!) and Java: from one hand, we have pointers and structures and the C world, from the other hand, we have Java with references.
>
>I wish it as simpler, as in C++: pass by reference, pass by value, independently of the data type.
>
>
>

Achilleas Margaritis wrote:

<snip>
> I think you better pass it with a pointer. I don't think it is possible for a compiler to fully understand how things are used...it may be the case that the struct is implicitely modified in a set of deeply nested functions.
<snip>

D is supposed to minimise the need for explicit pointer uses.

Mabye we could implement copy on write here.  Structs passed by reference, but if the function changes the value, it would make a copy of it and use that instead.

The only thing is that all modules would need to be compiled with the same convention for it to work.  (Hence upgrading/changing your compiler and/or its options would necessitate a clean and rebuild.)  And when you get into libs, it opens a whole new can of worms....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

I think D needs a 'ref' keyword like C# has. This way large structs can be passed by reference without nasty pointers. The way i see it, this is the only way to support this because as Stewart says if you have a function exported from a library, and it takes a struct, the only way for the compiler to know that the exported func takes the struct by Ref is if its indicated in the prototype with the ref keyword.

In article <c8sgn9$1ocs$1@digitaldaemon.com>, Stewart Gordon says...
>
>Achilleas Margaritis wrote:
>
><snip>
>> I think you better pass it with a pointer. I don't think it is possible for a compiler to fully understand how things are used...it may be the case that the struct is implicitely modified in a set of deeply nested functions.
><snip>
>
>D is supposed to minimise the need for explicit pointer uses.
>
>Mabye we could implement copy on write here.  Structs passed by reference, but if the function changes the value, it would make a copy of it and use that instead.
>
>The only thing is that all modules would need to be compiled with the same convention for it to work.  (Hence upgrading/changing your compiler and/or its options would necessitate a clean and rebuild.)  And when you get into libs, it opens a whole new can of worms....
>
>Stewart.
>
>-- 
>My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

I ran into a similar problem over here: news:c66dlu$1mt7$1@digitaldaemon.com

- Kris

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c8tbvq$fm$1@digitaldaemon.com...
> I think D needs a 'ref' keyword like C# has. This way large structs can be passed by reference without nasty pointers. The way i see it, this is the
only
> way to support this because as Stewart says if you have a function
exported from
> a library, and it takes a struct, the only way for the compiler to know
that the
> exported func takes the struct by Ref is if its indicated in the prototype
with
> the ref keyword.
>
> In article <c8sgn9$1ocs$1@digitaldaemon.com>, Stewart Gordon says...
> >
> >Achilleas Margaritis wrote:
> >
> ><snip>
> >> I think you better pass it with a pointer. I don't think it is possible for a compiler to fully understand how things are used...it may be the case that the struct is implicitely modified in a set of deeply nested functions.
> ><snip>
> >
> >D is supposed to minimise the need for explicit pointer uses.
> >
> >Mabye we could implement copy on write here.  Structs passed by reference, but if the function changes the value, it would make a copy of it and use that instead.
> >
> >The only thing is that all modules would need to be compiled with the same convention for it to work.  (Hence upgrading/changing your compiler and/or its options would necessitate a clean and rebuild.)  And when you get into libs, it opens a whole new can of worms....
> >
> >Stewart.
> >
> >--
> >My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
>
>

"imr1984" <imr1984_member@pathlink.com> escribió en el mensaje
news:c8tbvq$fm$1@digitaldaemon.com
| I think D needs a 'ref' keyword like C# has. This way large structs can be
| passed by reference without nasty pointers. The way i see it, this is the
only
| way to support this because as Stewart says if you have a function
exported from
| a library, and it takes a struct, the only way for the compiler to know
that the
| exported func takes the struct by Ref is if its indicated in the prototype
with
| the ref keyword.
|

What's wrong with inout?

-----------------------
Carlos Santander Bernal

One cannot use 'inout' with a const struct, since by definition it's read-only.

- Kris

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:c8udnv$205u$1@digitaldaemon.com...
> "imr1984" <imr1984_member@pathlink.com> escribió en el mensaje
> news:c8tbvq$fm$1@digitaldaemon.com
> | I think D needs a 'ref' keyword like C# has. This way large structs can
be
> | passed by reference without nasty pointers. The way i see it, this is
the
> only
> | way to support this because as Stewart says if you have a function
> exported from
> | a library, and it takes a struct, the only way for the compiler to know
> that the
> | exported func takes the struct by Ref is if its indicated in the
prototype
> with
> | the ref keyword.
> |
>
> What's wrong with inout?
>
> -----------------------
> Carlos Santander Bernal
>
>

You can't do this:

float3 vecA=float3(0,0,0);
float3 vecB=add(vecA,float3(0,0,1));


Carlos Santander B. wrote:
> "imr1984" <imr1984_member@pathlink.com> escribió en el mensaje
> news:c8tbvq$fm$1@digitaldaemon.com
> | I think D needs a 'ref' keyword like C# has. This way large structs can be
> | passed by reference without nasty pointers. The way i see it, this is the
> only
> | way to support this because as Stewart says if you have a function
> exported from
> | a library, and it takes a struct, the only way for the compiler to know
> that the
> | exported func takes the struct by Ref is if its indicated in the prototype
> with
> | the ref keyword.
> |
> 
> What's wrong with inout?
> 
> -----------------------
> Carlos Santander Bernal
> 
> 

Then this boils down to the good old war about "const". Walter decided to make "const" a storage class, not a type modifier. This means, we have const objects, you can take a pointer from them, but then the compiler does not help you in tracking that they were const.

Introducing "ref" in addition to "inout" would just hide this fact in a very obscure way. "inout mytype arg" would be "mytype &arg" in C++, while "ref mytype arg" would be "const mytype &arg".

I believe that whole business of "in", "out" and "inout" arguments is flawed. My first expectation, when I saw these was, that that they are "copy-in/copy-out" arguments. The specs are not very precise when they talk about this question. Somehow, I have the feeling, that D tries to hide the complexity of reference/value arguments from the user, but, at the same time, obscures and cripples the concept completely.

My opinion: neither the C++ nor the D way are the solution. I don't know the solution, but it has to be out there somewhere.



Kris wrote:

> One cannot use 'inout' with a const struct, since by definition it's read-only.
> 
> - Kris
> 
> "Carlos Santander B." <carlos8294@msn.com> wrote in message news:c8udnv$205u$1@digitaldaemon.com...
>> "imr1984" <imr1984_member@pathlink.com> escribió en el mensaje
>> news:c8tbvq$fm$1@digitaldaemon.com
>> | I think D needs a 'ref' keyword like C# has. This way large structs can
> be
>> | passed by reference without nasty pointers. The way i see it, this is
> the
>> only
>> | way to support this because as Stewart says if you have a function
>> exported from
>> | a library, and it takes a struct, the only way for the compiler to know
>> that the
>> | exported func takes the struct by Ref is if its indicated in the
> prototype
>> with
>> | the ref keyword.
>> |
>>
>> What's wrong with inout?
>>
>> -----------------------
>> Carlos Santander Bernal
>>
>>