Discuss: The Evil VB Equivalent to C's const
Author |
Message |
Adrian #1 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Michael, What's wrong with VBs Const statement? If you don't want to passed in parameter changed why not pass it ByVal? ...not sure I'm following you here... ;-) Cool Hasta Luego Adrian Maull, MCSD
I just found out that you can force a ByRef Parameter to pass ByVal by enclosing the argument in parentheses. At first I thought this would be great, because it would act like C's const keyword. Here's an example MyObject.MyMethod((Arg1),Arg2) But then a co-worker pointed out that it was evil because the person that wrote the sub or function you are calling thinks they are getting a ByRef and might try to change it but you have forced it to emulate ByVal. Is there a better way to simulate C's const?
|
Sat, 22 Sep 2001 03:00:00 GMT |
|
 |
Myrna Lars #2 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Quote: >I just found out that you can force a ByRef Parameter to pass ByVal by enclosing the argument in parentheses. At first I thought this would be great, because it would act like C's const keyword. >Here's an example >MyObject.MyMethod((Arg1),Arg2) >But then a co-worker pointed out that it was evil because the person that wrote the sub or function you are calling thinks they are getting a ByRef and might try to change it but you have forced it to emulate ByVal. Is there a better way to simulate C's const?
Evil??? Since when do morals enter the picture? Enclosing it in parentheses does NOT cause it to be passed by value. It's passed "by copy". VB creates a new, temporary variable "behind the scenes", copies the data to the temp, and it ByRef to the sub. But any changes the sub may make to the variable are NOT copied back to the original variable when execution returns from the sub. The temp is destroyed. As far as whether this is "right" or "wrong", in my book, the variable that's passed as an argument to the sub "belongs" to the caller, not to the sub, and the caller (not the sub) controls when and how its value is changed. If you are forced to work with a sub that's been written to require the arguments passed By Ref, you MUST pass them that way, and the only way to prevent the caller's variable from being changed is to create a copy yourself and pass that copy, or use the parentheses, which gets VB to do the extra work for you. BTW, if you pass a constant (declared with a Const statement) to a routine that's expecting a variable By Ref, the same thing happens. VB creates a temporary variable, initializes it with the value of your constant, and passes the address of that temporary variable to the sub. But what do the assumptions made by the person who wrote the Sub have to do with anything? If this variable is supposed to contain one of the outputs, enclosing the variable in parentheses is equivalent to ignoring the output value, which the caller certainly has the option of doing. --
|
Sat, 22 Sep 2001 03:00:00 GMT |
|
 |
Michael Kelse #3 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Hey, I appreciate the responses. It's nice to know that there are developers out there listening. I guess my problem is that I wasn't clear in what I was saying. Take #2: Q: Why would you ever want to pass by reference anyway? A: When you are calling functions that use large arrays or, better yet, large UserDefinedTypes into a function you don't want all the overhead of making a copy. I'm working on a middleware piece that translates client information and packages it to be sent off to a legacy server. The client sends 10k to 20k in a nested structure. Processing has to be done to some of the fields in this structure and passing by value is inefficient here. Q: Well in your case why don't you just pass by reference and quit your whining? A: I am only one worker bee on this large team project. No offense to my co-workers, but many of them are boneheads. When they are passed a reference to an object they assume that means they have license to{*filter*} with my data! Now I could utilize the mammoth office leviathan known as office politics and many meeting with upper-middle management to resolve this. Or I could insist that the functions involved pass a Const ByRef as a parameter. That way the bozo's I work with know that they are getting a Reference for the efficiency, but they are not to mess with my structures. If they want them changed, they have to negotiate with me. They can't just manipulate them in their functions. I hope that is clearer. Q: Why do you put up with that kind of behavior? A: Eh, it's a living. P.S. Sorry if I offended anyone by feigning morality. ;)
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Adrian #4 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Quote:
>Hey, I appreciate the responses. It's nice to know that there are >developers out there listening. I guess my problem is that I wasn't clear >in what I was saying. >Take #2: >Q: Why would you ever want to pass by reference anyway? >A: When you are calling functions that use large arrays or, better yet, >large UserDefinedTypes into a function you don't want all the overhead of >making a copy.
Don't worry...VB passes UDTs by reference anyway. Quote: > I'm working on a middleware piece that translates client >information and packages it to be sent off to a legacy server. The client >sends 10k to 20k in a nested structure. Processing has to be done to some >of the fields in this structure and passing by value is inefficient here.
If you are passing a structure again, no need to worry about parm passing inefficiency, because VB passes UDTs by reference anyway. Quote: >Q: Well in your case why don't you just pass by reference and quit your >whining? >A: I am only one worker bee on this large team project. No offense to my >co-workers, but many of them are boneheads. When they are passed a >reference to an object they assume that means they have license to{*filter*} >with my data! Now I could utilize the mammoth office leviathan known as >office politics and many meeting with upper-middle management to resolve >this. Or I could insist that the functions involved pass a Const ByRef as a >parameter. That way the bozo's I work with know that they are getting a >Reference for the efficiency, but they are not to mess with my structures. >If they want them changed, they have to negotiate with me. They can't just >manipulate them in their functions. I hope that is clearer.
...I don't know what to tell you here... Quote: >P.S. Sorry if I offended anyone by feigning morality. ;)
No offense taken here...morality is a good thing. ;-) Cool Hasta Luego Adrian Maull, MCSD
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Bertie Wooste #5 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Quote:
>Q: Why would you ever want to pass by reference anyway? >A: When you are calling functions that use large arrays or, better yet, >large UserDefinedTypes into a function you don't want all the overhead of >making a copy. I'm working on a middleware piece that translates client >information and packages it to be sent off to a legacy server. The client >sends 10k to 20k in a nested structure. Processing has to be done to some >of the fields in this structure and passing by value is inefficient here.
I believe that when you reference a function in an out-of-process component as you appear to be doing, Michael, it will *always* be done behind the scenes by copying. In these cases, using ByVal is actually more efficient than ByRef because in the latter case VB assumes it needs to copy the results back as well. Bertie
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Dan Barcl #6 / 13
|
 Discuss: The Evil VB Equivalent to C's const
On Tue, 6 Apr 1999 16:06:30 -0500, "Michael Kelsey" Quote:
>I just found out that you can force a ByRef Parameter to pass ByVal by enclosing the argument in parentheses. At first I thought this would be great, because it would act like C's const keyword. >Here's an example >MyObject.MyMethod((Arg1),Arg2) >But then a co-worker pointed out that it was evil because the person that wrote the sub or function you are calling thinks they are getting a ByRef and might try to change it but you have forced it to emulate ByVal. Is there a better way to simulate C's const?
This is not evil. Programmers should understand the language and pay attention to what they write if they want their programs to work. Sorry, but this is a pet peeve of mine and you're likely to hear more about it. New programmers are constantly stating how VB should behave like the language they're used to. The feature you're describing has been around since the very beginning of MS Basic language releases (can you say CP/M or TRSDOS?). Enclosing a variable in parenthesis has the effect of passing it byval That is *protecting it* from the unknown (possibly evil) subroutine. As Myrna said, it actually passes a copy under the hood. From a language standpoint it's not so important to understand how it's implemented under the hood as to understand the effect. It is not evil. It's a feature that allows you more control. Dan
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Dan Barcl #7 / 13
|
 Discuss: The Evil VB Equivalent to C's const
On Wed, 7 Apr 1999 14:52:27 +0100, "Bertie Wooster" Quote:
>>Q: Why would you ever want to pass by reference anyway? >>A: When you are calling functions that use large arrays or, better yet, >>large UserDefinedTypes into a function you don't want all the overhead >of >>making a copy. I'm working on a middleware piece that translates client >>information and packages it to be sent off to a legacy server. The client >>sends 10k to 20k in a nested structure. Processing has to be done to some >>of the fields in this structure and passing by value is inefficient here. >I believe that when you reference a function in an out-of-process component >as you appear to be doing, Michael, it will *always* be done behind the >scenes by copying. In these cases, using ByVal is actually more efficient >than ByRef because in the latter case VB assumes it needs to copy the >results back as well.
This is correct, and it can make a big performance difference in some circumstances. As I said in another note in this thread, it has the *effect* of passing byval. Dan
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Rick Rothstei #8 / 13
|
 Discuss: The Evil VB Equivalent to C's const
I posted the following quote a while ago in response to another, similar stream: The following is quoted directly from "VB & VBA In A Nutshell - The Language" by Paul Lomax (Copyright and Published by O'Reilly & Associates, Inc.) on Pages 51-52: "When passing variables to procedures that are either in the same project or that are methods of an in-process ActiveX component, ByRef is much faster than ByVal. This is because the memory reference gives the called procedure almost instantaneous access to the variable's value. However, when passing variables to a method in an out-of-process server, ByVal has the performance advantage. This is because a procedure in a different process can't use the reference supplied by ByRef. Since they don't share memory, the called procedure has to obtain a copy of the variable's value. But since parameters are usually passed by reference to permit called routines to change their value, the value of the ByRef argument is copied back to the calling procedure, and the original variable is updated with this value." Quote:
>On Wed, 7 Apr 1999 14:52:27 +0100, "Bertie Wooster"
>>>Q: Why would you ever want to pass by reference anyway? >>>A: When you are calling functions that use large arrays or, better yet, >>>large UserDefinedTypes into a function you don't want all the overhead >>of >>>making a copy. I'm working on a middleware piece that translates client >>>information and packages it to be sent off to a legacy server. The client >>>sends 10k to 20k in a nested structure. Processing has to be done to some >>>of the fields in this structure and passing by value is inefficient here. >>I believe that when you reference a function in an out-of-process component >>as you appear to be doing, Michael, it will *always* be done behind the >>scenes by copying. In these cases, using ByVal is actually more efficient >>than ByRef because in the latter case VB assumes it needs to copy the >>results back as well. >This is correct, and it can make a big performance difference in some >circumstances. As I said in another note in this thread, it has the >*effect* of passing byval. >Dan
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Bertie Wooste #9 / 13
|
 Discuss: The Evil VB Equivalent to C's const
... Quote: >It is not evil. It's a feature that allows you more control.
I think though it's worth adding that it's a feature which is most often used unknowingly, as in: MySub ( X ) ' instead of MySub X or Call MySub ( X ) Probably every VB program ever written contains an example, most of them benign. Bertie
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
David Phillip #10 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Interesting. I remember a time when CALL was required when paren's enclosed the param's. I guess that is progress, but I'm old fashioned and still use CALL. David Phillips Quote:
>... >>It is not evil. It's a feature that allows you more control. >I think though it's worth adding that it's a feature which is most often >used unknowingly, as in: > MySub ( X ) ' instead of MySub X or Call MySub ( X ) >Probably every VB program ever written contains an example, most of them >benign. >Bertie
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Dan Barcl #11 / 13
|
 Discuss: The Evil VB Equivalent to C's const
On Wed, 7 Apr 1999 16:53:24 +0100, "Bertie Wooster" Quote:
>... >>It is not evil. It's a feature that allows you more control. >I think though it's worth adding that it's a feature which is most often >used unknowingly, as in: > MySub ( X ) ' instead of MySub X or Call MySub ( X )
You clearly know this, but I'll elaborate for those who don't... You are right, this is a part of the definition that can be easily overlooked if you don't understand it. When using the Call keyword, parenthesis are required around the parameters. When *not* using the Call keyword, parenthesis are required to be *missing*. In this case parenthesis are assumed to be a part of the parameter if they are found. This can lead to a bug if there is only one parameter. VB would assume the parameter is to be passed byval. If there is more than one parameter you'll get a syntax error if you try to do this. Dan
|
Sun, 23 Sep 2001 03:00:00 GMT |
|
 |
Kathleen Joeri #12 / 13
|
 Discuss: The Evil VB Equivalent to C's const
Dan, This is tricky for new folks. FWIW, I have been teaching my way, way smart brother VB over the last couple of weeks. He is doing a class design, has his head around huge concepts, calls with detailed questions about how control arrays are different critters, but he still gets caught by the darn parens on function/subs. We'll give him another week or two. -- Kathleen
|
Mon, 24 Sep 2001 03:00:00 GMT |
|
 |
Rob Bove #13 / 13
|
 Discuss: The Evil VB Equivalent to C's const
<<"When passing variables to procedures that are either in the same project or that are methods of an in-process ActiveX component, ByRef is much faster than ByVal. This is because the memory reference gives the called procedure almost instantaneous access to the variable's value.>> Other than String variables, which are obviously a different animal, I think the performance differences between ByRef and ByVal in an in-process call are negligible at best. And they certainly don't outweigh the safety factor gained by not having changes visible in the calling procedure when they shouldn't be. Just my opinion. -- Rob Bovey, MCSE The Payne Consulting Group http://www.payneconsulting.com * Post follow up questions to this newsgroup * * I do not respond to questions sent via e-mail * Quote:
>I posted the following quote a while ago in response to another, similar >stream: >The following is quoted directly from "VB & VBA In A Nutshell - The >Language" by Paul Lomax (Copyright and Published by O'Reilly & Associates, >Inc.) on Pages 51-52: >"When passing variables to procedures that are either in the same project or >that are methods of an in-process ActiveX component, ByRef is much faster >than ByVal. This is because the memory reference gives the called procedure >almost instantaneous access to the variable's value. >However, when passing variables to a method in an out-of-process server, >ByVal has the performance advantage. This is because a procedure in a >different process can't use the reference supplied by ByRef. Since they >don't share memory, the called procedure has to obtain a copy of the >variable's value. But since parameters are usually passed by reference to >permit called routines to change their value, the value of the ByRef >argument is copied back to the calling procedure, and the original variable >is updated with this value."
>>On Wed, 7 Apr 1999 14:52:27 +0100, "Bertie Wooster"
>>>>Q: Why would you ever want to pass by reference anyway? >>>>A: When you are calling functions that use large arrays or, better yet, >>>>large UserDefinedTypes into a function you don't want all the overhead >>>of >>>>making a copy. I'm working on a middleware piece that translates client >>>>information and packages it to be sent off to a legacy server. The >client >>>>sends 10k to 20k in a nested structure. Processing has to be done to >some >>>>of the fields in this structure and passing by value is inefficient here. >>>I believe that when you reference a function in an out-of-process >component >>>as you appear to be doing, Michael, it will *always* be done behind the >>>scenes by copying. In these cases, using ByVal is actually more efficient >>>than ByRef because in the latter case VB assumes it needs to copy the >>>results back as well. >>This is correct, and it can make a big performance difference in some >>circumstances. As I said in another note in this thread, it has the >>*effect* of passing byval. >>Dan
|
Wed, 26 Sep 2001 03:00:00 GMT |
|
|
|