Using CONST

[hsiangch_ong]

i have moved more and more away from using const at all.  because of examples like just displayed.

suppose the programmer does needs variable "c" changed.  why bother defining it as constant in the first place?

it's understood why there have to be labels.  such as color names.  instead of hairy long integers.  that in some programs.  could be written as goggly hexadecimal.

in a program that's not even 1000 lines of code.  defining something as constant.  could cause a bug difficult to track down.  it happened to me once.  but with trying to use somebody else's "include" file.

[Pete]

Constants also create havoc when used in gender programs.

Pete

[SMcNeill]

@McNeill - CONST, on the other hand, don't do that.   If set in the main module, they remain for every point after that in your code.  You can't make a local const, or a local variable.  You set that CONST and *BY GOD*, it's going to damn stay constant!!

But you can still change the value in a function, for example. That way, you can manipulate the constant, right?

Code: (Select All)

Option _Explicit



Declare Function Beispiel(wert As Integer) As Integer



Const c = 123

Print: Print c

Print



Print Using "###"; Beispiel(c)



End



Function Beispiel (wert As Integer)



  wert = 321

  Beispiel = wert

End Function

Give this a test run and you can see one of the obvious differences in CONST and VARIABLES.

Code: (Select All)

Option _Explicit



Declare Function Beispiel(wert As Integer) As Integer



Const c% = 123

Dim Shared c1%: c1% = 987









Print: Print "Before:"; c%, c1%

Print



Print Using "###"; Beispiel(c%)

Print Using "###"; Beispiel(c1%)

Print "After:"; c%, c1%; "Notice the CONST doesn't change, but the variable does."

End



Function Beispiel (wert As Integer)

    wert = 321

    Beispiel = wert

End Function

As per your code above, notice that our CONST remains constant and doesn't change, whereas the shard variable does here.  CONST are immutable, unchangeable values inside a program.  Variables aren't, and as such, you have to be much more careful in how you use them so their value doesn't get corrupted.

If you know a value is never going to change, make it a CONST.  I honestly can't think of a single benefit in making it a shared variable.  I can't imagine a single reason why you really wouldn't want to.

[Kernelpanic]

So, finally an answer. - It's clear that one can't change the const variable itself; otherwise, it wouldn't make sense. I was thinking about the possibility of manipulation, but I have to admit, I can't think of a practical example where such manipulation would make sense.
There are simpler methods for hacking a password. Something like this was on my mind. 

Code: (Select All)

Option _Explicit



Const PW = 123



Dim As Integer eingabe



Print: Print

Input "Zahlenkombination: ", eingabe



If eingabe <> PW Then

  Print

  Print "Freischalten"

Else

  Print: Beep

  Print "Fehler!"

End If



End

[SMcNeill]

There's only one valid instance where I know you can change CONST, and that's as per the example here:

Code: (Select All)

Const foo = 123

Print foo

Whatever

Print foo



Sub Whatever

    Const foo = 987

    Print foo

End Sub

Note that FOO has a value of 123 in the main program. Then in the SUB we declare another CONST FOO and give it a value of 987. That second FOO is local in scope and *only* valid inside that SUB itself.

Now, as you mention, "I can't think of a practical example where such manipulation would make sense"...

There's only a single reason why I could see that one would want to make use of this feature of the language -- when creating a set of code to be used as an $INCLUDE library. You can set your CONST for use in your SUB/FUNCTIONs and not have conflicts with the user's other code which might reuse the same name as a const or variable. It makes your little subroutine more self-enclosed and independent, without affecting the main program as extensively.

Code: (Select All)

Sub Whatever

    Const foo = 987

    Print foo

End Sub

If the above is the whole extent of my library code, it's going to be 100% self-contained and won't affect any variables or const which may exist inside any other program. It doesn't matter if you DIM SHARED foo, or if you have a different CONST foo in your main program. The CONST foo inside that SUB is local in scope, doesn't apply anywhere else, and is ONLY valid inside that sub.

It's a means to use CONST inside your libraries, without having to affect the rest of the code making use of those libraries.

[Kernelpanic]

If the above is the whole extent of my library code, it's going to be 100% self-contained and won't affect any variables or const which may exist inside any other program. It doesn't matter if you DIM SHARED foo, or if you have a different CONST foo in your main program. The CONST foo inside that SUB is local in scope, doesn't apply anywhere else, and is ONLY valid inside that sub.

It's a means to use CONST inside your libraries, without having to affect the rest of the code making use of those libraries.

Yes, what's declared in a procedure or function is always local.
I don't have the energy to experiment with it right now, but it's interesting. It's a great way to learn the hidden intricacies of a language. Thanks!