Image of Navigational Map linked to Home / Contents / Search Function v Constant

by Jim Karabatsos - GUI Computing
Image of Line Break

It seems that a passing comment I made in an article last issue (bemoaning the lack of the ability to evaluate functions with constant arguments) struck a real chord with our readers. The problem is it was two different chords. The first group basically agreed with what I said, as shown in this e-mail:

Hi Jim
You are so, so right about this. It is one of my pet peeves, and I was quite pleased to see an articulate flame on the topic. WHAT WERE THEY THINKING OF? By the way, how do you feel about the .[_NewEnum] method on collections?
Must've been the same guy.
Say, I have an idea. We get some guns, and we fly to Seattle, rent a car, and find the guy who did this. And on the way, we get the guys who are responsible for the Registry. And then we....
Oh well, just a dream. Keep up the good work.
-- Trevor

Here is a clip from a message from Bruce McKinney on the same issue:

Like you, I have been on a hopeless and futile campaign to get VB to add an initialization syntax. We'll soon see whether VB6 actually becomes the first language in history to support inheritance without constructors (and without initialization of standard types). There is a tirade on this subject (with workarounds) at the start of Chapter 8 of my book. Alas, it makes all the same points as the VB4 tirade in the first edition.

What really surprised me was that this first group was very much in the minority. The second group was much larger and wanted to point out to me that VB has (since V4) had constants like vbTab so there was no need for me to do this.

Hmmm. Let me quote one of my responses:

Hello Joe,
>> I'm going to assume you just blanked on the fact that
>> VB predefines vbTab (along with vbCRLF, vbNullString, etc)
>> for you, so there's absolutely no need for this.
>> Faster too, since the value is already initialized.

No, I did NOT blank out on this fact, although it is surprising to me how many emails I have received about this statement. Obviously, I failed to stress my real gripe: that I cannot use the built-in functions with constant expressions to initialise the value of constants. Yes, VB does define vbTab and the constants you have pointed out above. But what about this scenario:

  Const ACK = Chr$(6)
  Const NAK = Chr$(21)
  Const NUMBER_OF_LETTERS = Asc("Z") - Asc("A") + 1
or even

The bottom line is that no set of pre-defined constants packaged into the standard type libraries can give me every constant I might ever want, so I would like to have the ability to roll my own, and there is currently no way to do this using just Visual Basic. Yes, I know how to work around it -- whether it be by using variables as if they were constants (and defining an INIT procedure I need to call, but losing the protection of constants), or defining a set of read-only methods as I alluded to in my article, or creating a type library using MIDL (which is fast becoming my preferred approach) -- but my point is that I should not have to do this. It would be a relatively easy matter for the compiler to recognise that the parameters to the built-in function are constant and then call the function at *compile* time to determine the value of the expression. Indeed, this optimisation should then carry forward into the rest of the code, so that if I coded this:

   Const VERSION_NUMBER = 3.11
and later, in my Form_Load() I coded this:
   lblVersion.Caption = "Version " &  Format$(VERSION_NUMBER, "#0.00")
then it should compile as if I had coded:
   lblVersion.Caption = "Version 3.11"
This too is an assignment of a constant expression:
   SQL = "SELECT Field1, Field2, Field3 " & "FROM MyTable " _
       & "WHERE Field1 = 'SMITH'"
so it should compile as a simple assignment of one constant to the SQL variable, not as a RUN-TIME concatenation of three constant strings.

Yes, I do know that the speed of modern PCs makes this all rather academic.

Generally speaking, these things will have NO real impact on your program. However, I happen to believe that VB has now progressed far beyond the point where there is ANY excuse to cut corners in the compiler. It is used by more programmers than any compiler except maybe COBOL, and any work done on the compiler has such enormous payback in gained productivity in our industry. Furthermore, I think VB programmers can no longer be treated as somehow less "real programmers" than, say, C programmers -- that they cannot be given certain language facilities because they will somehow shoot themselves in the foot.

Anyway, sorry for the long response, but this is a pet peeve of mine and I guess you happened to hit the right button. On the up side, I guess I have just written an article for the next issue.

Regards, and thanks for your email.

-- Jim

Enough said?

Written by: Jim Karabatsos
April '98

Image of Arrow linked to Next Article
Image of Line Break