Re: ByVal vs. ByRef



To simplify:

When you pass a reference type (any class instance) byval:
A copy of the passed *pointer* to the reference is made.
When you pass a reference type byref:
A reference to the passed pointer is made.
When you pass a value type (double, date, boolean, integers, decimals, etc.)
byval:
A copy of the passed *value* is made.
When yo upass a value type byref:
A reference to the passed value is made.

With reference types, it is generally more efficient to pass them byval,
which is the default in .NET.
With value types, it is generally safer to pass them byval, again the
default.

-Scott


"Phill W." <p-.-a-.-w-a-r-d-@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:he0sv3$lq8$1@xxxxxxxxxxxxxxxxxxxx
eBob.com wrote:

I guess I have fallen into the habit of generally passing values ByRef,
unless I am certain that the method will never need to alter the value.

"the Value" - is the important part of that statement.
Q: What is "the Value" of a reference variable?
A: A "pointer" to the object.

Also I have never been quite sure what it means to pass a reference type
ByVal.

When you pass reference objects around, you're passing a "pointer" to that
object, not the object itself. (NB: I'm putting the "P" word in quotes
here because, strictly speaking, it's a .Net Object Reference, which is
underpinned (somewhere) by a real (memory) Pointer; the difference between
/these/ two is fundamental to how Garbage Collection works, but that's
another story).

So, if you pass an object ByVal, you're passing that "pointer" ByVal, so
you can access (and /change/ properties on) the object in question but you
/can't/ create a new instance of that object and "return" it.
For that, you have to pass the object ByRef.


And my basic understanding of ByRef is that that is the way to pass
something which the subroutine/function might change.

The definition of "change" is the problem here.

It's not so much "alter the parameter I'm passed"

but more like "create a new [instance] value for this parameter that my
Caller needs to know about".

So, passing a TreeNode ByVal you can add as many child Nodes to it as you
like; it's still the /same/ TreeNode that was passed in.

Also, since my searches have only confirmed that I am not the only person
confused by this, what does it mean to pass a reference type ByVal? Some
Internet posts say that the only difference is that you are passing a
copy
of the pointer rather than the pointer itself. But I tried this dirt
simple
little experiment ...

<snip string-sample-code />
Ah.

Strings are Immutable, which in the current context is to say,
(a) they're a bit odd, and
(b) once you've put a value in one, you can't change that value without
implicitly creating a whole new String object.

If it's any consolation, any /other/ reference type /would/ have worked as
you expect.


With regards your supplied code, I would make a couple of suggestions:

(1) Have a look at System.IO.Path; it has a bunch of really useful Path
manipulation functions, like GetFileName(path); saves all that mucking
about with Substring().

(2) I would suggest only expanding a single directory at a time; if you're
working a big tree, it can take a long time to load lots (and lots) of
Nodes that your user may never look at; just give them the ones they ask
for (a "dummy" TreeNode class and the TreeView's BeforeExpand event are
your friends here).
If you are going to load the whole tree in one go, think carefully about
expanding it as you go along; again, with a large tree, this can get quite
slow.

HTH,
Phill W.


.