Re: Procedure PR/PI question

On 4/29/2013 1:54 PM, Alan Campin wrote:

As I have said many times, VALUE means the compiler says I guarantee that
variable in the calling program will not be changed and it does that by
making a copy and pass a pointer to it.

Passing by VALUE does not involve passing a pointer to it. It simply copies the data from the caller's variable to another variable that's local to the procedure. It does not pass a pointer.

By contrast, CONST, if the variable size/type does not match does exactly what you're attributing to VALUE -- it makes a copy and then passes a pointer.

CONST means I will try to keep you from changing it but there are plenty of
ways to change the variable inside the procedure and have the calling
variable to be changed. These include passing as a parameter to a program
inside the procedure, getting a pointer to it, putting in a data structure.
The compiler may try to prevent you from changing but it is easy enough to
change which could result in some really nasty bugs.

Complaining that CONST is bad because a variable can still by changed though another non-CONST interface is like complaining that the locks on the front door of your house is bad because burglars can still steal your TV by entering through the back door.

The fault isn't with CONST, it's with the fact that you have two different methods to access the same variable.

Or, that you are lying to the compiler... using a prototype that doesn't match it's corresponding procedure interface.

That is why I always use a VALUE unless I passing something really big and
lately I have using Option(*String) to pass long variable strings.

VALUE is okay for short things, such as numeric values, but some environments (SQL comes to mind) don't allow VALUE. Then you end up with wrappers, et al.

Really, it's nearly impossible to "accidentally" change a CONST parameter. You pretty much have to be trying to do so. Don't throw away the baby with the bath water!