"Richard Krehbiel" <rich@kastle.com> wrote in message news:anhbkc$iah$1@digitaldaemon.com...
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > Consider passing a value as "inout" parameter to a function.
> > Then both the caller and the called functions continue to use the same
> > value, by multithreading.
> > Now when will the changes of the inout parameter be incorporated into
the
> > original variable?
>
> Um, no.  The caller and called function do not both execute concurrently
by
> multithreading.  It's just a function call.  (If you like, the caller is "suspended" until the called function returns - but it's definitely not as formal as that.)

I know how function call works. And I mean, if you are, actually,
explicitely, deliberately using *multithreading*.
Or let me put in an other example:

int global_var;

void fn(inout int a, inout int b)
{
  a = 3;
  printf("a = %d\n", a);
  printf("b = %d\n", b);
  printf("global_var = %d\n", global_var);
}

int main()
{
  global_var = 2;
  fn(global_var, global_var);
  return 0;
}


> > Immediately, or when the called function returns?
> > The specification does not tell. (Walter: please put it in)
> > The "inout" name suggests the later, but the first happens (i hope).
> > Therefore the name "inout" is not really intuitive. I would rather
suggest
> > "ref", because what is happening is passing a parameter by reference.
>
> It's enough to say that the adjusted value of any "inout" parameters are visible when the function returns.

It is not enough. The same variable can be seen through other inout parameters, pointers, global variables, function return values, etc.

"Walter" <walter@digitalmars.com> wrote in message news:anh2vv$9jb$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > Consider passing a value as "inout" parameter to a function.
> > Then both the caller and the called functions continue to use the same
> > value, by multithreading.
> > Now when will the changes of the inout parameter be incorporated into
the
> > original variable?
> > Immediately, or when the called function returns?
>
> When the called function sets it to a value. I'm not sure why it matters.

int global_var;

void fn(inout int a, inout int b)
{
  a = 3;
  printf("a = %d\n", a);
  printf("b = %d\n", b);
  printf("global_var = %d\n", global_var);
}

int main()
{
  global_var = 2;
  fn(global_var, global_var);
  return 0;
}

A "real" inout parameter passing would print:
a = 3
b = 2
global_var = 2

So it is not "inout" but "ref"

> > The specification does not tell. (Walter: please put it in)
> > The "inout" name suggests the later, but the first happens (i hope).
> > Therefore the name "inout" is not really intuitive. I would rather
suggest
> > "ref", because what is happening is passing a parameter by reference.
>
> True, but I like the consistency with "in" and "out" parameters.

The name is consistant, but the behaviour is not.

Sandor Hojtsy wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:anh2vv$9jb$1@digitaldaemon.com...
> 
>>"Sandor Hojtsy" <hojtsy@index.hu> wrote in message
>>news:angu34$4ba$1@digitaldaemon.com...
>>
>>>Consider passing a value as "inout" parameter to a function.
>>>Then both the caller and the called functions continue to use the same
>>>value, by multithreading.
>>>Now when will the changes of the inout parameter be incorporated into
>>
> the
> 
>>>original variable?
>>>Immediately, or when the called function returns?
>>
>>When the called function sets it to a value. I'm not sure why it matters.
> 
> 
> int global_var;
> 
> void fn(inout int a, inout int b)
> {
>   a = 3;
>   printf("a = %d\n", a);
>   printf("b = %d\n", b);
>   printf("global_var = %d\n", global_var);
> }
> 
> int main()
> {
>   global_var = 2;
>   fn(global_var, global_var);
>   return 0;
> }
> 
> A "real" inout parameter passing would print:
> a = 3
> b = 2
> global_var = 2

I don't think that I know what you mean.  Semantically, inout should be something that expects a value in, but can still change it in the function.  So I would expect inout to do what I imagine that it does:
a = 3
b = 3
global_var = 3

> So it is not "inout" but "ref"

This is something of a pathological case, perhaps even an error, since both inouts end up pointing to the same place.  Yeah, inout might be a ref, but I imagine that it would be extremely hard for the compiler to do compile time checking that the inout parameters are all different for each function.  In fact, I can't really see a case where it would be proper or useful to do this, nor a way to pass it back in a reasonable manner in any case.  I think that the keyword is clear enough, and that if possible what you're doing in the above code should be classed as an error, or at least proscribed in the documentation.

Evan

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anrhrf$8v9$1@digitaldaemon.com...
>
> "Richard Krehbiel" <rich@kastle.com> wrote in message news:anhbkc$iah$1@digitaldaemon.com...
> > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > > Consider passing a value as "inout" parameter to a function.
> > > Then both the caller and the called functions continue to use the same
> > > value, by multithreading.
> > > Now when will the changes of the inout parameter be incorporated into
> the
> > > original variable?
> >
> > Um, no.  The caller and called function do not both execute concurrently
> by
> > multithreading.  It's just a function call.  (If you like, the caller is "suspended" until the called function returns - but it's definitely not
as
> > formal as that.)
>
> I know how function call works. And I mean, if you are, actually, explicitely, deliberately using *multithreading*.

When explicitly using multithreading, the time(s) that the value get changes are indeterminite, unless you protect access to the resource using synchronization.

One reason ( I suspect) it's called "inout" and not "ref" is that this is the terminology used by RPC (Remote Procedure Call) interfaces.  In this case, the parameter is physically copied to some other machine, and when the function returns, the adjusted value is copied back.  Proper use of "in", "out", and "inout" let you control the amount of data copied over the network.  In this case, the values of "inout" parameters remain the same in the caller until they are unmarshalled when the call returns.  By indicating that the value is "inout" it implies RPC semantics.  "Ref" doesn't mean the same thing.

> Or let me put in an other example:
>
> int global_var;
>
> void fn(inout int a, inout int b)
> {
>   a = 3;
>   printf("a = %d\n", a);
>   printf("b = %d\n", b);
>   printf("global_var = %d\n", global_var);
> }
>
> int main()
> {
>   global_var = 2;
>   fn(global_var, global_var);
>   return 0;
> }

In the absence of actual RPC, I'd expect "inout" to have "ref" semantics, which makes this a "simple" example of aliasing.  And, BTW, I notice that this example isn't using multithreading.

But I wonder if this is an important enough issue to make "ref" distinct from "inout."

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

In article <aniq73$2522$1@digitaldaemon.com>, Walter says...
>
>
>"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
>> Consider passing a value as "inout" parameter to a function.
>> Then both the caller and the called functions continue to use the same
>> value, by multithreading.
>> Now when will the changes of the inout parameter be incorporated into the
>> original variable?
>> Immediately, or when the called function returns?
>> The specification does not tell. (Walter: please put it in)
>> The "inout" name suggests the later, but the first happens (i hope).
>> Therefore the name "inout" is not really intuitive. I would rather suggest
>> "ref", because what is happening is passing a parameter by reference.
>
>inout is also used by IDL, and so is familiar to many C/C++ programmers.
>
>

Sorry I'm kinda late on this -- didn't get to read Friday afternoon or over weekend.

As a not of interest, inout in the IDL context is more precise.  Since IDL is used for interfaces that may be used on RPC or network marshalled function calls, copy/copyback is a very reasonable implementation.  Even if you are on the same machine (COM instead of DCOM or CORBA), the interface may belong to an out-of-process server, which means you can't (easily) just hand a reference across the interface boundary.

Not a huge deal for normal D programming, or even for DLL programming in D, but if you start looking at full COM/DCOM/CORBA/.NET support, then the differences between copy/copyback and reference-passing will become more obvious.

Mac

Ok, I see what you're talking about. -Walter

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:annk04$1q6b$1@digitaldaemon.com...
> It means the compiler can safely decide whether to pass by reference or by value based only upon performance considerations (for in parameters) since the callee is "guaranteed" not to alter it.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:ann6h0$1c57$2@digitaldaemon.com...
> > If the parameter is call by reference, like a class object, then even if
> the
> > function copies the parameter to a local so he can modify it, he still
> will
> > be modifying the referred to type. I don't understand the advantage
here.
> >
> > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anm3km$2g7p$1@digitaldaemon.com...
> > > Maybe parameters should never be writable, unless you explicitly say
it
> > > should be.  Disallow writes to in parameters even inside the function.
> > Then
> > > by default it's reference, except for small types.  And if the callee
> > wants
> > > to modify it he must do the copy (or cast) client-side.  And callers
can
> > > rest assured the parameters they're sending are sort of guaranteed
> > (barring
> > > casts) not to allow callees to alter their "in" parameters.  Certainly
> > this
> > > would be a great boon to compiler optimization.
> > >
> > > in other words I want to make this illegal:
> > >
> > > uint strlen(char* s)
> > > {
> > >     // uint len=0; while (*s++) ++len; return len;  // error... can't
> > modify
> > > parameter "s"
> > >     uint len=0; char* scan = s; while (*scan++) ++len; return len; }
//
> ok
> > > }
> > >
> > > void zero(char* s)
> > > {
> > >     *s = 0;  // this is ok, writing thru pointer parameter.
> > > }
> > >
> > > Writing to out parameters should be ok.
> > >
> > > Sean
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:ankrnc$18pl$2@digitaldaemon.com...
> > > > Don't worry, I won't do that <g>. Requiring it would mean that 'in's
> > would
> > > > become as ubiquitous as 'const' in C++ parameter lists, and would be
> > just
> > > as
> > > > distracting (to me, anyway).
> > > >
> > > > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ankih8$uhi$1@digitaldaemon.com...
> > > > > I just don't want 'in' becoming mandatory.  ;)
> > > > >
> > > > > Sean
> > > > >
> > > > > "Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...
> > > > >
> > > > > > 6) Sure the 'in' is redundant - but some redundancy is good for
> > > reducing
> > > > > > typo errors. 'in' is there for the (many) programmers who like
to
> > use
> > > > > /*in*/
> > > > > > and would like some language support for their style. 'in' is
> > optional
> > > > (I
> > > > > > don't use it myself), and is harmless enough if you don't want
to
> > use
> > > > it.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Richard Krehbiel" <rich@kastle.com> wrote in message news:ans2fd$qaj$1@digitaldaemon.com...
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anrhrf$8v9$1@digitaldaemon.com...
> >
> > "Richard Krehbiel" <rich@kastle.com> wrote in message news:anhbkc$iah$1@digitaldaemon.com...
> > > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > > > Consider passing a value as "inout" parameter to a function. Then both the caller and the called functions continue to use the
same
> > > > value, by multithreading.
> > > > Now when will the changes of the inout parameter be incorporated
into
> > the
> > > > original variable?
> > >
> > > Um, no.  The caller and called function do not both execute
concurrently
> > by
> > > multithreading.  It's just a function call.  (If you like, the caller
is
> > > "suspended" until the called function returns - but it's definitely
not
> as
> > > formal as that.)
> >
> > I know how function call works. And I mean, if you are, actually, explicitely, deliberately using *multithreading*.
>
> When explicitly using multithreading, the time(s) that the value get
changes
> are indeterminite, unless you protect access to the resource using synchronization.
>
> One reason ( I suspect) it's called "inout" and not "ref" is that this is the terminology used by RPC (Remote Procedure Call) interfaces.  In this case, the parameter is physically copied to some other machine, and when
the
> function returns, the adjusted value is copied back.  Proper use of "in", "out", and "inout" let you control the amount of data copied over the network.  In this case, the values of "inout" parameters remain the same
in
> the caller until they are unmarshalled when the call returns.  By
indicating
> that the value is "inout" it implies RPC semantics.  "Ref" doesn't mean
the
> same thing.

Exactlty. "ref" doesn't mean the same thing.
And currently "inout" is doing what you should call "ref".
Hmm, in some situations real "inout" could be useful, but I can live
withouth it.

> > Or let me put in an other example:
> >
> > int global_var;
> >
> > void fn(inout int a, inout int b)
> > {
> >   a = 3;
> >   printf("a = %d\n", a);
> >   printf("b = %d\n", b);
> >   printf("global_var = %d\n", global_var);
> > }
> >
> > int main()
> > {
> >   global_var = 2;
> >   fn(global_var, global_var);
> >   return 0;
> > }
>
> In the absence of actual RPC, I'd expect "inout" to have "ref" semantics, which makes this a "simple" example of aliasing.

I would not expect it. The name tells just the opposite.

> And, BTW, I notice that
> this example isn't using multithreading.

Yes. I considered multithreading to be too complex example for this. And wanted to show, that you don't need multithreading to find out when the original parameter value is modified.

> But I wonder if this is an important enough issue to make "ref" distinct from "inout."

Don't make them distinct, rename the "inout" keyword!


Sandor

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:ans5h2$trt$1@digitaldaemon.com...
> In article <aniq73$2522$1@digitaldaemon.com>, Walter says...
> >
> >
> >"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> >> Consider passing a value as "inout" parameter to a function.
> >> Then both the caller and the called functions continue to use the same
> >> value, by multithreading.
> >> Now when will the changes of the inout parameter be incorporated into
the
> >> original variable?
> >> Immediately, or when the called function returns?
> >> The specification does not tell. (Walter: please put it in)
> >> The "inout" name suggests the later, but the first happens (i hope).
> >> Therefore the name "inout" is not really intuitive. I would rather
suggest
> >> "ref", because what is happening is passing a parameter by reference.
> >
> >inout is also used by IDL, and so is familiar to many C/C++ programmers.
> >
> >
>
> As a not of interest, inout in the IDL context is more precise.  Since IDL
is
> used for interfaces that may be used on RPC or network marshalled function calls, copy/copyback is a very reasonable implementation.

So you adopted the keyword, with a different meaning. Do you think guys with
IDL knowledge will be happy?
I find "inout" a good name for copy/copyback, but not for call by reference.

Sandor

"Evan McClanahan" <evan@dontSPAMaltarinteractive.com> wrote in message news:anrqs3$ic5$1@digitaldaemon.com...
> Sandor Hojtsy wrote:
> > "Walter" <walter@digitalmars.com> wrote in message news:anh2vv$9jb$1@digitaldaemon.com...
> >
> >>"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> >>
> >>>Consider passing a value as "inout" parameter to a function.
> >>>Then both the caller and the called functions continue to use the same
> >>>value, by multithreading.
> >>>Now when will the changes of the inout parameter be incorporated into
> >>
> > the
> >
> >>>original variable?
> >>>Immediately, or when the called function returns?
> >>
> >>When the called function sets it to a value. I'm not sure why it
matters.
> >
> >
> > int global_var;
> >
> > void fn(inout int a, inout int b)
> > {
> >   a = 3;
> >   printf("a = %d\n", a);
> >   printf("b = %d\n", b);
> >   printf("global_var = %d\n", global_var);
> > }
> >
> > int main()
> > {
> >   global_var = 2;
> >   fn(global_var, global_var);
> >   return 0;
> > }
> >
> > A "real" inout parameter passing would print:
> > a = 3
> > b = 2
> > global_var = 2
>
> I don't think that I know what you mean.  Semantically, inout should be
> something that expects a value in, but can still change it in the
> function.  So I would expect inout to do what I imagine that it does:
> a = 3
> b = 3
> global_var = 3
>
> > So it is not "inout" but "ref"
>
> This is something of a pathological case, perhaps even an error, since both inouts end up pointing to the same place.

Both parameters and the global_var too.

>  Yeah, inout might be a
> ref, but I imagine that it would be extremely hard for the compiler to
> do compile time checking that the inout parameters are all different for
> each function.

I am not requesting a compile time check to enforce copy/copyback semantics. I propose to rename the keyword to "ref" to indicate that there is no copy/copyback semantics.

> In fact, I can't really see a case where it would be
> proper or useful to do this, nor a way to pass it back in a reasonable
> manner in any case.  I think that the keyword is clear enough, and that
> if possible what you're doing in the above code should be classed as an
> error,

Which violates the rule of ... ??

> or at least proscribed in the documentation.
>
> Evan
>

"Walter" <walter@digitalmars.com> wrote in message news:anh2vv$9jb$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > Consider passing a value as "inout" parameter to a function.
> > Then both the caller and the called functions continue to use the same
> > value, by multithreading.
> > Now when will the changes of the inout parameter be incorporated into
the
> > original variable?
> > Immediately, or when the called function returns?
>
> When the called function sets it to a value. I'm not sure why it matters.
>
> > The specification does not tell. (Walter: please put it in)
> > The "inout" name suggests the later, but the first happens (i hope).
> > Therefore the name "inout" is not really intuitive. I would rather
suggest
> > "ref", because what is happening is passing a parameter by reference.
>
> True, but I like the consistency with "in" and "out" parameters.


Lets consider you are passing a 1000 byte structure to a function. You don't wan't to change it, but you don't wan't to make a copy of it either, because that is slow. Passing by pointer is complex, and unnecessary. You specify "inout" to enable pass by reference. But conceptually this is not an "inout" parameter 'cause it is never changed. It is a constant reference, as in C++. You still have to use the keyword "inout" ruining the whole concept of *self documentation*.

struct large {
  int f[1000];
}

void fn(inout large a, int i)
{
  printf("%d", a.f[i]);  // "a" is never changed
}

Sandor