• ** There has been a recent site upgrade. Please clear your browser cache to avoid issues. **
  • New forum feature - post voting and best solution

    Check out this thread for the details: https://www.access-programmers.co.uk/forums/threads/new-forum-feature-post-voting-and-best-answer.314134/

    This new feature looks great to me! :)

  • We now have 3 forum themes

    Go for the default (light) theme, Shades of Grey or Shades of Blue. I just added the Blue one.

    The thread about it is here: https://www.access-programmers.co.uk/forums/threads/new-forum-theme-shades-of-blue.314136/

Identifier type characters (1 Viewer)

Guus2005

AWF VIP
Local time
Today, 11:14
Joined
Jun 26, 2007
Messages
2,584
When i have a question and looking for an answer i want to find it at my favorite site, AWF.
So when i find a nifty piece of code i use it in a solution looking for a problem and post it here.

This was what i was looking for:
Code:
Dim V$
Dim T%
Which means V is declared as a string and T is an integer which i found after googleing

1597050003791.png


For the complete list and more, browse here:

Just to know what it means, NOT to use it. I prefer the written declaration
Code:
Dim V as string
Dim T as Integer
or even better
Code:
Dim strV as string
Dim intT as Integer
Just so you know.

Share & Enjoy!
 

arnelgp

error reading drive A:
Local time
Today, 17:14
Joined
May 7, 2009
Messages
10,525
according to the book i've read, the equivalent function with $ suffix is much
faster than without it. it is because those without the $, the returned value is a Variant type
and conversion takes place when assigning.
 

Guus2005

AWF VIP
Local time
Today, 11:14
Joined
Jun 26, 2007
Messages
2,584
No argument there, however variables declared as Dim V$ are not faster than variables declared as Dim V as string!
 

arnelgp

error reading drive A:
Local time
Today, 17:14
Joined
May 7, 2009
Messages
10,525
it was also mentioned that LongLong is suffixed with ^, eg:

Dim lnglngVar^
 

vhung

Member
Local time
Today, 02:14
Joined
Jul 8, 2020
Messages
144
"the equivalent function with $ suffix is much
faster than without it. it is because those without the $, the returned value is a Variant type
and conversion takes place when assigning."
wow
>very silly
>try that sometimes later
 

vhung

Member
Local time
Today, 02:14
Joined
Jul 8, 2020
Messages
144
"suffixed with ^"
guess
>"suffixed with ^" is an exponential sign
>i used it with my access calculator
>see attachment
 

Attachments

  • AccdbCalc.png
    AccdbCalc.png
    48.7 KB · Views: 16

Isaac

Lifelong Learner
Local time
Today, 02:14
Joined
Mar 14, 2017
Messages
2,330
according to the book i've read, the equivalent function with $ suffix is much
faster than without it. it is because those without the $, the returned value is a Variant type
and conversion takes place when assigning.
I do not believe that is correct.

If this were true: "those without the $, the returned value is a Variant type", then it would not also be true, that the practice of using the symbols has become almost completely obsolete and unused. I am sure that all of the people (90%) who are using the method: Dim VariableName as String are not tolerating that they are really declaring Variants up to the point of assignment.

And:
1599838881010.png


And, spelling out the type (as type) is more readable and clear.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 04:14
Joined
Feb 28, 2001
Messages
17,933
Isaac, you might not be old enough to remember this. But I am.

In classical BASIC circa late 1960s, you could dynamically create variables without first declaring them with a DIM statement. It didn't matter so much back then because the language was fully interpretive INCLUDING VARIABLES! Didn't matter how you used it, every variable was a Variant even though they did not name it as such. As time passed, stronger-typed languages became the vogue. BASIC took the simple way out and allowed static type declarations. In compiled languages, because you have to implement type-specific hardware instructions, you CANNOT take the dynamic variant approach to its limits. All variables have to be type-declared before you can compile instructions that would reference them, because otherwise the wrong instruction would be used and you would have a bad result. In fact, the ONLY machine I ever saw that didn't make a difference between LONG and SINGLE was a Honeywell 4800 because they used a bizarre floating-point format. All other machines delineate between integer math and floating math. Since strings are actually just implicit arrays of byte integers, that issue of instruction types applies to strings too. And we can't forget that not only do we have a difference between string vs. integer vs. floating point, but the sizes of integers and of floating point items ALSO can be different. We have BYTE, WORD, LONG, and LONGLONG (or QUAD, depending on your version of VBA) for integers and SINGLE or DOUBLE for floating-point. And again, the compiler has to know that you are using ahead of time to be able to build the right code.

VBA allows the "old" behavior because you CAN leave off Option Explicit and just name variables without regard to data typing. But to allow for more usage of strong-typing principles, VBA also allows Option Explicit so that you can let the compiler catch type-assignment errors. Now here is where you run into issues with what you said.

VBA is a semi-compiled language. It is not interpreted. Instead, it runs as a PCode emulator, where PCode is the instruction set of a hypothetical but well-defined virtual machine. VBA compiles PCode from your module content. When you use DIM X AS STRING, you have in fact declared an item to statically be a string. It will contain a string-descriptor. It is not a variant at any time, because remember this: You can get compilation errors such as Type Mismatch even before you run the code. Declared types are NOT dynamic EXCEPT for Variant types. Whenever you have a type conversion of ANY kind, it is because the compiler noted that a specific data type was used that required conversion, so extra conversion instructions were compiled into the sequence.

Now, as to whether there is a speed difference between, say, TRIM() and TRIM$(), I don't know for certain because Microsoft, in their infinite wisdom, does not give us insight into the PCode compiled for a particular code sequence. However, if I declare a string variable and then assign TRIM$(x) to that variable, the compiler will recognize that a conversion is not required for that case, so won't include conversion code. The speed difference is that a variant data type has a descriptor even for numeric data. But it is not clear that other data types DO have descriptors.

You may ask how I am so sure. If you web-search VBA LANGUAGE SPECIFICATIONS you can find a few good articles that even define when type conversion code will be implemented. Be warned, however, to bring lots of strong black coffee if you really want to start reading that much.
 

Isaac

Lifelong Learner
Local time
Today, 02:14
Joined
Mar 14, 2017
Messages
2,330
When you use DIM X AS STRING, you have in fact declared an item to statically be a string. It will contain a string-descriptor. It is not a variant at any time
Yep - that's what I was saying.

you CAN leave off Option Explicit and just name variables without regard to data typing.

Not exactly ... Option Explicit's effect is to require you to Declare variables: It has no effect on the rules of typing them.
1599842285298.png


VBA also allows Option Explicit so that you can let the compiler catch type-assignment errors

I would diverge on this point as well - Option Explicit, along with Dim lngVar as Long, followed by the statement: lngVar="test", actually will not produce a compile error.
1599841941314.png


I'll take your word on the BASIC part - you're right, that was before my techie years and possibly to some degree before my years! :)
 

Attachments

  • 1599842076973.png
    1599842076973.png
    33 KB · Views: 8

isladogs

CID VIP
Local time
Today, 10:14
Joined
Jan 14, 2017
Messages
13,920
Sorry Isaac but that does produce a compile error...when it runs
1599855554463.png
 

Isaac

Lifelong Learner
Local time
Today, 02:14
Joined
Mar 14, 2017
Messages
2,330
A run time error, not a compile error.

My post was focused on the fact that it won't produce a compile error -- I meant, of course, the error that the parser catches specifically during
Debug > Compile. And was a response to Doc's " VBA also allows Option Explicit so that you can let the compiler catch type-assignment errors ", which is incorrect.

so 1) we're talking about 2 different errors, compile vs. runtime
and 2) Option Explicit produces no different results. The sub you pictured will err at runtime whether Option Explicit is on or not.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 04:14
Joined
Feb 28, 2001
Messages
17,933
There are circumstances where VBA will disallow that at compile time, particularly if you are talking about a subroutine call.


I stand by my statement that the compiler knows when something is illegal. I'll admit I'm surprised it doesn't flag the simple test that you guys did. Doesn't matter, though. Bad usage is bad usage either way. Catch it now, catch it later.
 

Isaac

Lifelong Learner
Local time
Today, 02:14
Joined
Mar 14, 2017
Messages
2,330
Bad usage is bad usage either way. Catch it now, catch it later.
Absolutely agree! Declare and type all variables 100% of the time, is my rule. Even further, give variables descriptive names. So strong is my habit that I can't remember not to when making VBScript - Most of the time the first run ends up revealing that I've tried to type something at least once. But I'm OK with that, it's evidence of a deep habit.

And I see what you mean about the other occasions, such as a mistyped variable being passed as an argument.

I'm working right now on a support project with a huge VBA project in a complex Excel workbook/interface. Almost no variables were declared, much less typed. It has made the "understanding" process incalculably harder. At least most variables have names which are descriptive to the author, but even there, heavy abbreviating was followed, the interpretation of which depends entirely on business domain knowledge. :confused:
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 04:14
Joined
Feb 28, 2001
Messages
17,933
Almost no variables were declared, much less typed. It has made the "understanding" process incalculably harder.

I'm beginning to sense that you have a flair for understatement. This kind of "declaration vacuum" happened to me once along time ago when I was given some assembly language code with NO COMMENTS and was asked to fix it because it was broken. I empathize deeply, my friend.
 

arnelgp

error reading drive A:
Local time
Today, 17:14
Joined
May 7, 2009
Messages
10,525
did you not Carefully read and understand what i wrote.
you are trying to Experiment with variable Declaration,
while I wrote about the Return from a Function, eg:

Chr$() against Chr()
LTrim$() against Ltrim()
String$() against String()
UCase$() against UCase()
etc...

the functions with $ suffix, returns an Explicit string
while those without returns a Variant type.

the former is much faster since there is no
type conversion from Variant to string.
 

arnelgp

error reading drive A:
Local time
Today, 17:14
Joined
May 7, 2009
Messages
10,525
VBA Developer Handbook 2nd Edition
Ken Getz
Mike Gilbert

Sybex 2000(c)
string.jpg
 

Isaac

Lifelong Learner
Local time
Today, 02:14
Joined
Mar 14, 2017
Messages
2,330
did you not Carefully read and understand what i wrote.
you are trying to Experiment with variable Declaration,
while I wrote about the Return from a Function, eg:
Possibly I thought you were talking about variable declaration based on this:
Dim lnglngVar^
...And possibly because the OP has framed this thread as discussing identifier type symbols for the purpose of declaring variables.

Thanks for clarifying..
 
Last edited:

Users who are viewing this thread

Top Bottom