ByRef vs. ByVal

[ChrisGreaves]

ByVal	Optional. Indicates that the argument is passed by value.
ByRef	Optional. Indicates that the argument is passed by reference. ByRef is the default in Visual Basic.

According the the (2003) Visual Basic for Applications help files, ByRef is the default in VBA.
I generally use neither ByVal nor ByRef.

I most commonly use ByVal when I am testing an argument and returning a status. For example “Return TRUE if this string contains this sub-string”. I understand that
I could as easily enclose the argument in parentheses to force an interim value to be passed to the procedure.

For the life of me I can think of only one reason for using ByRef, and that is for purposes of documentation. Declaring an argument as ByRef seems to emphasize to the reader that I may well be modifying the argument for the sake of the calling procedure.

Thus a procedure FindNextString(strSourceString, ByRef lngFoundPointer) makes it quite clear that the calling procedure plans to make use of a possibly-changed value in the Long argument.

Can anyone suggest a mechanical/programming reason for declaring ByRef?

Thanks
Chris

[rory]

Given that it is the default (except for property procedures) there is no reason to specify it other than for clarity. I rarely do, except in the odd case where there's a mix of ByVal and ByRef, simply to overtly distinguish between the two.

[Doc.AElstein]

Hi Chris,
I see you asked specifically for a reason for declaring.
Rory has said there isn’t, - I suspect he probably knows, so that answers that.

I would just chirp in, if I may, as a non programming professional , and say I find it really annoying when such things are left out. Text is incredibly cheap, and as far as I know adding stuff like that does not slow a program down??, and I personally find it a lot easier to understand later when I include all the default stuff.
But that is just my opinion.. and maybe I should not dabble in computer stuff if I don’t understand most of it or don#t really know any of it so well, Lol.. :)

As for ByRef vs. ByVal
A couple of things I have found very useful with ByRef
_1) It is a nice way to use a Sub Routine as a pseudo Function to return multiple values - I do not know what the limit is to the number of arguments that you are allowed to use??, but I think it is a lot.
_2) I find it very useful to use in recursive Functions, especially if there may be lots of recursions and you can easily loose track of how many copies of ByVal things are hanging around,

Alan

[HansV]

A procedure can have at most 60 arguments. If you need to pass more values, you can do so in the form of an array argument (or a ParamArray). I cannot think of a real-life situation where you'd want to pass 60 different arguments to a procedure - if you need that many it's time to rethink the design.

[Doc.AElstein]

Thanks for the extra info., Hans
I think I dabbled once with the paramArray and I certainly thought about and fought about with the Array as argument – a few quirks there with the Array as argument.. different opinions on whether it can be passed ByVal or not . I am not discussing that again though… I think it can, many professionals don’t. There you go, I don’t know what I’m talking about :)
I did not know of the 60 limit either.. , thanks … I expect then I will probably use at least that many argumants one day as well lol, :)
Alan

[HansV]

S1958.png

[Jay Freedman]

"Array argument must be ByRef" -- that makes sense, because the variable name MyArray is just a pointer to the array's storage location. If ByVal could be allowed, then a space of unknown size would have to be allocated on the stack to accommodate the (unknown number of) values being passed.

[Doc.AElstein]

S1958.png

If you "house" that Array in a Variant variable then that can be passed as ByVal
Some will say that the Array can then be passed ByVal, some will disagree with that...
i know that things held in a Variant variable do not always behave the same as when they are used "purely", and may be considered as different things..

[Doc.AElstein]

"Array argument must be ByRef" -- that makes sense, because the variable name MyArray is just a pointer to the array's storage location. If ByVal could be allowed, then a space of unknown size would have to be allocated on the stack to accommodate the (unknown number of) values being passed.

Hi Jay,
I had not heard that particular argument before, its good to know, thanks. ( I did not know that you cannot have a space of unknown size on the stack . ... I will bear that in mind when I go back to try and sort out a few unsolved problems of mine... I am not really too clued up on what the stack is, I have one "housed" in the garden, but there are not many limitations on its size, apart from when one neighbour complains to the local authorities about the smell )
But I will stick to my opinion about the Array, some agree with it, some don't. ( https://www.excelforum.com/development- ... ost4381420" onclick="window.open(this.href);return false; )
I have discussed this to death with "Computer Experts" who themselves can't agree amoungst themselves on whether you can pass an Array ByVal or not
Alan

[HansV]

If you "house" that Array in a Variant variable then that can be passed as ByVal
Some will say it can then be passed ByVal, some will disagree with that...

Yes, as far as I can tell the array is passed ByVal in that situation.

[rory]

A Variant doesn't actually contain an array, just a pointer to it, so no, the array is not passed ByVal. ;)

[ChrisGreaves]

Given that it is the default (except for property procedures) there is no reason to specify it other than for clarity. I rarely do, except in the odd case where there's a mix of ByVal and ByRef, simply to overtly distinguish between the two.

Thanks Rory.
I liked the idea of declaring explicitly when ByVal is in use.
Clarity is everything, right?
Cheers
chris
P.S. I wish i hadn't left it so late to respond. Look at all the opinions I now have to disagree with ....