Debate? ByRef/ByVal

[Mr.Mac]

Well I read and re-read
http://www.vbforums.com/showthread.p...ighlight=Byref
http://www.developerfusion.co.uk/show/51/6/
and stuff like

It is more efficient to code 
     SUB WriteLine(ByVal L AS STRING)
than to code
     SUB WriteLine(L AS STRING)
and it is never necessary to code
     SUB WriteLine(ByRef L AS STRING)
since that is the default.

But efficiency is seldom a problem (never so far for me) on modern computers. If a case arose, I would probably opt for avoiding the SUB entirely to omit all overhead.

Maybe one could use ByVal to use the fact that you are guaranteed that your input variable is not changed.
y = F1(x) + F2(x)
for example. If F1 modified x, then F2 would return an unexpected result.

But if one were so careful as to do that, one could simply not modify x.

However, if the default were reversed so that all SUBs are "efficient" and passed variables never get changed, then I can imagine a case where one would need to know about ByRef in the case that one actually wanted to return multiple values.

That not being the case, I think the answer to the question "Why ever use ByVal or ByRef?" is "There is seldom or never a good reason. Forget you ever heard the terms."

Mac

[RhinoBull]

It is not about "efficiency" - it's all about whether or not original value needs to be preserved. If so you'd use ByVal - that's all.

[RobDog888]

Moved

[Shaggy Hiker]

This is a VB6 issue. By the time you get to .NET, the rules for default have changed, and you really should know the meaning and purpose of ByRef vs. ByVal.

[RhinoBull]

How is it an issue? Also, environment isn't matter - the "meaning and purpose" are still the same.
It was not created for VB6 nor it was for VB.Net.

[penagate]

That not being the case, I think the answer to the question "Why ever use ByVal or ByRef?" is "There is seldom or never a good reason. Forget you ever heard the terms."

I am not sure how you arrived at that conclusion.
Passing by value and by reference each have their own purpose, and, like any other language facility, should be used as appropriate.

In most languages, passing by value is the default argument mode, and the expected behaviour. If passing by reference is required, it must be denoted as such, to avoid surprises.
In languages such as VB6, the opposite is true, but the principle is equally applicable.

If you care about efficiency, then you need to care about what platform you're using, and the specifics of the calling convention employed. Generally, passing value types (primitives) by value is more efficient, since they're internally stored as values; passing reference types by value is less efficient than passing them by reference, since they're stored as references.


You should note, though, that all passing a reference type by value will do is make a copy of the reference; it won't actually clone the object. The function you pass the reference to will still be able to modify the object's state, but it won't be able to modify your original reference.

But if one were so careful as to do that, one could simply not modify x.

Noble. However, it's just as much what you should and shouldn't do as what you can and can't do. "Simply not modifying x" falls over when you have more than one person coding. Plus, self-documenting code is good.

[Ellis Dee]

ByRef is the preferred method for passing strings. It's much faster than passing by value if they are large.

[Mr.Mac]

It's much faster

I'd like to see a program where it makes a difference.

True, 0.0000034 is much faster than 0.0000009. But the human cannot see to that level of detail.

If I enter a word to be translated to Danish

w$=D2E("mulig")

No one can detect the ByThis/ByThat nonsense. Whether it figures it out instantly or takes 2 hours, the ByThis/ByThat nonsense will not be a factor.

IMHO

(w$="possible")

Mac

[BramVandenbon]

Why would you add the ByVal keyword? To protect the original object, right?
... The String class is immutable! So, there's no need to protect it.

[BramVandenbon]

I'd like to see a program where it makes a difference.

True, 0.0000034 is much faster than 0.0000009. But the human cannot see to that level of detail.

If I enter a word to be translated to Danish

w$=D2E("mulig")

No one can detect the ByThis/ByThat nonsense. Whether it figures it out instantly or takes 2 hours, the ByThis/ByThat nonsense will not be a factor.

IMHO

(w$="possible")

Mac

It's a matter of principle.

That string instance could be a 4MB XML file. If you are going to pass that from one method to the other. Then, it's really a shame to do it ByVal.

[Shaggy Hiker]

In general, when you pass an object by value, you are pushing the entire object onto the stack. When you pass by ref, you are pushing the memory address only.

While it is true that you can do one or the other, or both, and it generally doesn't make a noticeable difference in speed, speed shouldn't be the reason you are deciding which to do. You can pass things ByRef to use as callbacks, or return results (lots of API calls do this, as well as several TCP/IP operations, TryParse, and many more). This isn't done for speed, it's done because ByVal simply wouldn't work. Alternatively, you can pass ByVal if you will be altering the value, and don't want side effects.

Simply choose the one that is correct.

As for speed, perhaps all your programs work in the blink of an eye. I have a deeply iterative program that takes about three days to complete a calculation on a fairly small data set. I don't know how slow it would be on a large dataset, but a week or two would be likely. For something like that, anything that sped up a single interation would have a HUGE impact on total run time.

[penagate]

Why would you add the ByVal keyword? To protect the original object, right?
... The String class is immutable! So, there's no need to protect it.

It's a matter of principle.

That string instance could be a 4MB XML file. If you are going to pass that from one method to the other. Then, it's really a shame to do it ByVal.

I assume you are referring to .NET strings, which are actually reference types and not value types.

You should note, though, that all passing a reference type by value will do is make a copy of the reference; it won't actually clone the object.