Using ref

On Jul 3, 6:55*am, Marc Gravell <marc.grav...@gmail.com> wrote:
> Please tell me you're kidding. You aren't passing a String; you are
> passing a StringBuilder. This does not prove *anything* relating to a
> string (which is what you claim). A StringBuilder is a mutable wrapper
> (which as an implementation detail, tortures a string internally).

OK, picky picky! StringBuilder is what I meant, which is similar in
some way to String (capital S), but not a 'string', which in C# is not
a recognized type outside of String (that is, 'string' is the same as
'String' in C#, apparently the first letter is not case sensitive,
i.e., the C# compiler developers overloaded this term).

> Again, what this comes down to is passing a reference to the object
> (StringBuilder). Try actually passing a *string* with/without "ref",
> changing it inside the method, and see how far you get...

I guess I would get the same as my demo program.

>
> I'm not sure the swap example proves anything that we didn't already
> know? The entire discussion of "new" is unrelated and purely
> misleading/distracting to the actual discussion; the key thing is that
> any *assignment* to the argument (be it to "new", to "null", or any
> other value) - i.e. something that changes *the reference* is only
> reflected to the caller with "ref". Which is the entire *point* of the
> distinction of pass-by-reference vs reference-type.

Yes, I'm sure your correct *in your mind's eye*. But from the prose
you type, it's confusing. The point I made with the demo program is
that 'changes' the reference implies something happens to the
reference--and that something is permanent outside the method/function
calling it and the object it points to. What I showed is that whether
you pass a reference to an object by value or by reference in C#, in a
method/function, you can still do something 'permanent' to the object,
even when the method/function goes out of scope. This was
demonstrated in my program--which is copyright by the way-- in the
line: x.Append("SB1"); The StringBuilder variable mainY is assigned,
permanently, the value "SB1" even though mainY was passed (or a
reference to the same, if you're pedantic) to the function/method 'by
value' rather than 'by reference'.

>
> Re MVP, the difference here is that it isn't the awardee who suddenly
> decides that they are an MVP...
>
> Marc

OK, OK, I'll stop using "N00b" then, if that's the problem. I'll put
a different disclaimer in.

Ray Lopez
[C# MVP] <--kinda, sorta, "in the mind's eye"

[walks away from the troll]

"What I showed is that whether
you pass a reference to an object by value or by reference in C#, in a
method/function, you can still do something 'permanent' to the object,
even when the method/function goes out of scope."


That is true, but not THE point. If your client lives, say, in Dallas, then,
when you want to reach it, you look where? in Dallas, no! if you are in
Seattle, you look at your cardfile holding your clients addresses. Now, if
one of your buddy (procedure), living in New York, ask to contact the said
client, you have two options: make a copy of your cardfile and 'pass' it to
him, that is 'by value', or you cant 'rent' him, for a while, your cardfile,
that will be 'passed by reference'. In both case, your New York buddy can
reach your client, in Dallas, and he can change your client to a not-client
anymore, quite permanently, sure, but, and there is a but, in the last case,
it can do much more, he can screw your cardfile too. And NEVER you ever
"passed" (ouch) the client it-self to your buddy.



Vanderghast, Access MVP

On Thu, 03 Jul 2008 03:33:13 -0700, Hilton <nospam@nospam.com> wrote:

> Peter Duniho wrote:
>> Hilton wrote:
>> What example is it that you are saying uses "ldloca.s"? Are you
>> comparing this to managed code? If not, how can that be "same as C"?
>>
>> In any case, the "ldloca.s" instruction is used when you pass by
>> reference, yes. But that's only when you use the "ref" or "out"
>> keyword.
>
> My point is that the C# call "method (ref x)" is defined by
> you/Jon/community as being pass by reference, yet the C call "method
> (&x)"
> is defined by you/Jon/community as being pass by value

That point is not supported by your assertion regarding the IL generated
for some hypothetical C# code (which you didn't post anyway, so who knows
what the hell you really meant).

In any case, the passing mechanism is defined by the declaration of the
method/function, not by the caller. The caller doesn't get to pick how
the method is called. It simply complies with whatever declaration was
made.

Since there's no such thing as passing "by reference" in C, I don't see
any inconsistency at all between the two examples you gave. The fact that
in C you can generate an arbitrary reference value to pass for a parameter
is irrelevant. You're still passing the reference by value, and the
function being called still cannot change the original value that was
passed.

> - they're doing EXACTLY the same thing.

They are _not_ "doing EXACTLY the same thing". The C# version is passing
the address of a variable that contains a reference to an object, while
the C version is passing the address of a variable that contains the
object itself.

> Both simply take the address of x and pass it along.
> Does a prettier syntax changes the entire concept?

It's not just about "prettier syntax". In fact, it's not at all about
prettier syntax. There are fundamental differences between the two
examples.

> And if
> Microsoft has used "&" instead of "ref" in its definition of the C#
> language, would that now mean that the C# call "method (&x)" was now
> pass by
> value???

See above. The syntax is irrelevant. The caller is irrelevant. The only
thing that matters is the declaration of the method.

> Pete, really, I don't want to spend more of your time or my time on this.

If that were true, you would stop arguing about it. Or if it's really a
true statement, then it seems that you're less concerned about my own
expenditure of time, and more concerned about how that reflects on you.

> In my mind (which I agree probably doesn't fit the pure definition of the
> pass-by definitions), if I pass a reference or pointer to my chunk of
> data,
> I'm passing by reference

You remind me of the people who continue to cling to the idea that Iraq
had something to do with the 9/11 attacks and that Hussein was hiding
weapons of mass destruction somewhere in his country, in spite of
absolutely no evidence in support of those ideas and in spite of volumes
of evidence to the contrary.

In other words, you've decided on your dogma and no amount of actual facts
will have any effect on your beliefs.

That's an unfortunate characteristic for any human being, but it's
especially problematic for someone in a field like programming. Computers
don't adjust themselves to accommodate your way of thinking. No matter
how much you wish for C to have pass by reference, and no matter how much
you wish for C#'s pass by value to be the same as C#'s pass by reference,
it simply will not be.

> (the focus being on the data, not the actual
> parameter). I think millions of other people think that way too since
> pass-by-reference has been taught for decades when discussing C, but
> apparently that capability never existed.

From K&R, section A7.3.2 "Function Calls":

In preparing for the call to a function, a copy is
made of each argument; ALL ARGUMENT-PASSING IS
STRICTLY BY VALUE

(emphasis mine)

I really don't see how it could be any clearer than that. If you continue
to insist that the simple act of passing any reference is the same as
passing "by reference", we can only conclude that you are simply guilty of
willful ignorance.

It's unfortunate that you would continue to refuse to change your view on
the matter, but the worst part is your insistence on continuing to
promulgate your view as the correct one. If you want to remain ignorant
yourself, that's fine. But please, stop trying to make everyone else
ignorant too.

Pete

"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
newsp.udpbo1i08jd0ej@petes-computer.local...
> The fact that the value you're passing is a reference does not make the
> parameter a "by reference" parameter, nor does it mean that the object is
> passed by reference.
>
> IMHO, Jon's article does in fact explain this.
>
> Pete

Yes it does, and some days I'm slower than others. It didn't sink in for me
until Jon put up the Swap example.

- Steve

Peter Duniho wrote:

> It's unfortunate that you would continue to refuse to change your view on
> the matter, but the worst part is your insistence on continuing to
> promulgate your view as the correct one.

I have no problem discussing things with people, but I don't like it (and I
think it shows your true colors - others have mentioned this too) when you
start trying to spread BS about people. I'm not trying to 'promulgate' my
view as the correct one, look what I said in my posts:

"I know that most of the literature out there agrees with your point of
view."
"Jon, I totally 'see' you view on this (which seems to be consistent with
many/most others - i.e. I acknowledge that I am in the minority here)."

Then you accuse me of not posting code. Without trying to sound sarcastic,
I assumed someone of your knowledge and experience (I mean this, I'm not
being sarcastic) would know how to write the following code, compile and run
ildasm and see the IL:

class Class1
{
[STAThread]
static void Main(string[] args)
{
new Class1 ().Go();
}

void Go ()
{
string s = "C#";

Method1 (s);
Method2 (ref s);

}

void Method1 (string s)
{}

void Method2 (ref string s)
{}
}


Hilton

On Thu, 03 Jul 2008 11:09:23 -0700, Hilton <nospam@nospam.com> wrote:

> I have no problem discussing things with people, but I don't like it
> (and I
> think it shows your true colors - others have mentioned this too) when
> you
> start trying to spread BS about people. I'm not trying to 'promulgate'
> my
> view as the correct one,

Of course you are. Every time you state your disagreement with the
correct view, you are promulgating the incorrect view.

> [...]
> Then you accuse me of not posting code. Without trying to sound
> sarcastic,
> I assumed someone of your knowledge and experience (I mean this, I'm not
> being sarcastic) would know how to write the following code, compile and
> run
> ildasm and see the IL: [snip]

I do know how to do that. I can even write it more concisely than you
did. So what?

The point is that YOU had some code in mind, but without seeing what code
you're talking about, there's no way to understand your statement. Given
the other errors you've made, there's no way I can make the assumption
that when you write about a particular IL instruction, you actually know
what code goes with that instruction.

Especially given that the only code preceding your statement that "It uses
ldloca.s" was this: "method (StringBuilder x)", it's difficult to see why
you'd say that the IL would use "ldloca".

There certainly is code that can generate that instruction, but you hadn't
mentioned any such code up to the point where you brought up that
instruction.

If I were going to give you the benefit of the doubt and assume that you
actually knew what you were talking about, I'd just ignore this whole
thread, figuring that when you write that passing an object's reference is
the same as passing the parameter "by reference", what you really mean is
that it's actually the same as passing the parameter "by value".

It's pretty obvious that making that assumption would be incorrect, and so
it's also pretty obvious that I can't make any other assumptions about
anything else you post. If you are going to state that some specific code
generates some specific IL instruction, you had darn well better post the
code that you claim generates that IL instruction. Otherwise, whatever
statement you make about the IL instruction doesn't add a single thing to
the discussion.

Pete

On Jul 3, 11:06*am, "Steve Harclerode" <Lizard.That....@hot.mail.com>
wrote:

>
> Yes it does, and some days I'm slower than others. It didn't sink in for me
> until Jon put up the Swap example.
>

Then you'll love my example even more. And Jon's Swap example had a
typo in it (that I corrected).

Remember the rules of Ray then: for optimal performance, use Ref.
For stuff that's primitive, use non-Ref (Swap by value). For objects
(including arrays, strings [all forms, including String,
StringBuilder], user defined classes), use ref only if "new" is
present in the function/method, or only if you are 'redirecting' the
object like with "Swap", otherwise it's OK to use pass-by-value.

RL

On Jul 3, 11:09*am, "Hilton" <nos...@nospam.com> wrote:

Hilton--FYI Peter is a bit dogmatic, been that way for years, but he
is a useful reference here. We see your point, but I say give it a
rest. But for Jon and Peter, we wouldn't have decent programmers
working for free.

RL

[C# "newbie" MVP]

On Thu, 03 Jul 2008 11:55:13 -0700, raylopez99 <raylopez99@yahoo.com>
wrote:

> [...]
> Remember the rules of Ray then: for optimal performance, use Ref.
> For stuff that's primitive, use non-Ref (Swap by value). For objects
> (including arrays, strings [all forms, including String,
> StringBuilder], user defined classes), use ref only if "new" is
> present in the function/method, or only if you are 'redirecting' the
> object like with "Swap", otherwise it's OK to use pass-by-value.

And to Steve: I _strongly_ recommend you use Google Groups to review
previous discussions and posts by Ray. You should take everything you
read on the Internet with a grain of salt anyway, but in this case you can
make a decision for yourself as to what advice is likely to be correct,
useful, etc. by examining previous contributions and seeing if they look
like they were written by someone you'd consider reliable.

And for what it's worth, the same thing is true for any of the rest of
us. You shouldn't accept any of our statements without at least some
critical consideration, and I'm not going to try to convince you that Jon,
I, or anyone else is more or less reliable than someone else. You can
make an informed decision yourself just by looking at past contributions
to the newsgroup.

As far as this particular question goes, it's my strongly-held opinion
that using "ref" as a performance tool is almost never going to be useful
in a real-world scenario. If it does help, then it's because there's
something more fundamentally wrong about your design or implementation.

'nuff said.

Pete