Decimals can only be represented in Variants, and don't have one of those symbols.
And there are a few others that don't have those symbols, like Date, and LongLong in a Variant. Also, Variants themselves don't have a particular symbol like that. However, if you forget to declare the type, you'll get a Variant.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
And, just for some completeness, Booleans are just a special case of an Integer, much the same way that a Date is just a special case of the Double.
Typically, a Boolean only takes on the values of 0 or -1. But, with some trickery, you can make them take on any value that an Integer can have.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
And, just for some completeness, Booleans are just a special case of an Integer, much the same way that a Date is just a special case of the Double.
It isn't really as simple as that and it isn't a good way to look at it. It probably feels clever right up until the first time such assumptions bite you hard and you waste untold hours trying to unravel what somebody did trying to be clever. If you want type conversions always specify them explicitly.
In any case you should avoid using those type suffix symbols except where you need them: some decimal and hex numeric literal values.
Using them to define variables and functions just creates a cluttered mess that is harder to read and thus produces more errors. It is the opposite of good practice. They are a throwback that probably would have been deleted if we ever got a VB7.
It isn't really as simple as that and it isn't a good way to look at it.
I don't disagree with that at all. However, it is useful for me to know that a Boolean is two bytes (16 bits). (Maybe think about it sitting in a UDT.) Also, it's useful for me to know that a TRUE=1111111111111111 (or -1), and a FALSE=0000000000000000 (or 0). And that this is quite different from C and most other languages (especially for the TRUE).
But, you are correct. It would be really bad programming practice if a VB6 Boolean were used for anything more than a True/False Boolean. It's not good practice to do arithmetic with these things, as is often done in C (and related languages).
And yeah, I personally NEVER use the character variable typing suffixes. If VB6.5 ever comes about, I doubt they'll remove them, just to preserve backward compatibility, but I agree that we should avoid them.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
so, it is better to use a byte instead of a boolean, like
if myvar (byte) = 0 then for false and = 1 for true instead of myvar (boolean) = true and = false?
as byte is 1 byte and boolean 2 bytes?
and what about speed, if we are gonna check 1M variables if true or false.
if boolean is slower and also uses 2 bytes, its quite useless.
Well, it probably won't make a lot of difference, but since we work with 32-bit and 64-bit processors, in general accessing a 32-bit value is faster than accessing a 16-bit value, and accessing an 8-bit value is slower as well. It has to do with memory alignment when reading into a register. A 32-bit value will read directly into a 32-bit portion of the register in one access, where a 16-bit or 8-bit value may not align with the natural boundary of the memory bus and register so involves extra hardware cycles to align and mask the bits appropriately into the register, so is slower probably 75% of the time.
So, is it more important to save a little bit of speed or a 50% of your memory, its up to you.
I've seen cases with chess tables and other options, where it made since to only use 1-bit booleans, so you could have 16 booleans in the space that VB would normally take, but accessing those values would take a little longer, but not that much if you use a look up table to isolate the bit and a boolean operation to test it. In some situations it could actually be faster as you could test a group of 16, 32 or 64 bit boolean values in one shot to see if any in the group were true or false.
Another example is where it could speed up things is where you might have 64-booleans store in a 64-bit value that represent the state of 64 things and you only want to do something if one or more of them changed states. You could XOR the current value with the previous history, and if the result is 0, then none of the 64 values have changed so you saved having to test 64 things independently.
They are a throwback that probably would have been deleted if we ever got a VB7.
They were supported in VB7, i.e. VB.NET 2002, and they are still supported in VB 2017, so it seems rather unlikely that they would have been removed if a COM-based successor to VB6 was ever created.
they aren't going anywhere. They can be used on literals. It's one of the few ways to ensure you don't get a cast error when trying to assign 1 to a decimal. They also serve the purpose of letting the code reader know in-line what data type the variable is.
Using them to define variables and functions just creates a cluttered mess that is harder to read and thus produces more errors. It is the opposite of good practice. They are a throwback that probably would have been deleted if we ever got a VB7.
I doubt Olaf would agree to remove these monstrosities from his vNext. . . as far as I've seen snippets of his.
Since i never used any of those symbols in my life i'm completely indifferent to them.
Use proper hungarian notation and be done with it.
Code:
Dim sTemp As String
Dim iTemp As Integer
Dim lTemp As Long
Dim bTemp As Boolean
Dim dTemp As Double
Dim snTemp As Single
Dim byTemp As Byte
Dim curTemp As Currency
'and so on....
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
Since i never used any of those symbols in my life i'm completely indifferent to them.
Use proper hungarian notation and be done with it.
Code:
Dim sTemp As String
Dim iTemp As Integer
Dim lTemp As Long
Dim bTemp As Boolean
Dim dTemp As Double
Dim snTemp As Single
Dim byTemp As Byte
Dim curTemp As Currency
'and so on....
Exactly. Avoid using those symbols if at all possible.
A hypothetical VB7 must support that suffixes in order to ensure backward compatibility with all the sources. The same thing for PSet, Line, Circle, Print, !-symbol (access to a parametric value by the key), :=, etc.
Last edited by The trick; Oct 19th, 2018 at 05:24 AM.
I don't disagree with that at all. However, it is useful for me to know that a Boolean is two bytes (16 bits). (Maybe think about it sitting in a UDT.) Also, it's useful for me to know that a TRUE=1111111111111111 (or -1), and a FALSE=0000000000000000 (or 0). And that this is quite different from C and most other languages (especially for the TRUE).
But, you are correct. It would be really bad programming practice if a VB6 Boolean were used for anything more than a True/False Boolean. It's not good practice to do arithmetic with these things, as is often done in C (and related languages).
And yeah, I personally NEVER use the character variable typing suffixes. If VB6.5 ever comes about, I doubt they'll remove them, just to preserve backward compatibility, but I agree that we should avoid them.
It was my understanding that FALSE was defined as 0, and TRUE was defined as NOT FALSE .... which is what allows things like this possible:
Code:
Dim x as Integer
x = 4
if x then
MsgBox("This is True")
End If
As long as the expression evaluates to a TRUE (or NOT FALSE) state the message box will get displayed.
As long as the expression evaluates to a TRUE (or NOT FALSE) state the message box will get displayed.
Yes, but still x is not equal to True
thinBasic Code:
'
If x = True Then
MsgBox "Unreachable"
End If
Only when you assign -1 to x you can get x = True to succeed.
You can apply the same reasoning for Boolean variables, provided that you somehow coerce them to contain anything besides 0 and -1 e.g. a 4 like in your example can be done with this:
thinBasic Code:
'
Dim x As Boolean
Call CopyMemory(x, 4, 4)
If x Then
MsgBox ("This is True")
End If
If x = True Then
MsgBox "Unreachable" '<--- does not get called
End If
In the snippet above the neither x = False nor x = True conditions succeed -- just FYI.
There are a couple of points made about these Booleans in the above. For grins, I think I'll try and address them. Here's what I see as the points:
How do "If" statements work in terms of making boolean decisions?
Are Booleans really a special case of Integers, and how can we get into trouble with them?
Which is faster to use as a boolean type variable, Boolean, Byte, or maybe Long?
I think I'll address the last point in a subsequent post.
So, how do "If" statements work? For me, it's a bit more involved than that. First, I think it's important to realize that, with respect to boolean type operations, there are two kinds of operators, bitwise and logical. (By "logical", I mean we're trying to make a Yes/No, True/False decision.)
And, I always contrast VB6 to C to keep this straight. In C, for our bitwise operators, we've got &, |, ^, ~. And then, for our logical operators, we've got <, >, <=, >=, ==, !, !=, &&, ||.
VB6 makes a bit of a mess with this, and makes it much more difficult to recognize when you're doing a logical operation versus a bitwise operation. However, we can safely say the following: For VB6, AND, OR, NOT, XOR, IMP, EQV are our bitwise operators. And = (when not being used for assignment), <, >, <=, >=, <> are our logical operators. And, to make matters worse, in the VB6 MSDN, the AND, OR, NOT, XOR, IMP, EQV are called "Logical Operators" which is absolutely wrong. If anyone likes, I can easily prove that these are bitwise and not purely logical.
Now, just to be clear, in C, a bitwise operator is typically thought of as an operator that operates on each bit independently. The simplest is the ~ (or NOT in VB6). This operator just takes each bit and flips it. Now, a logical operator is one that always reduces to a TRUE or FALSE. In C, that would be an integer 1 or 0. In VB6, that would be an integer -1 or 0. (The 1 vs -1 is another issue, but I'll let that go for now.)
Now, another important thing to remember is that VB6 (and, any language, for that matter) is going to often create temporary variables (that aren't represented in the source code) to get its work done. And, we're better off thinking of "If" statements in these terms. For instance, we'll never get into trouble if we think of the decision expression in an "If" statement as always reducing to a temporary Boolean before the decision is made. For instance, in the above posts, Techgnome presented the statement "If x Then". However, we could also equivalently say "If x <> 0 Then", and that's actually being done in Technome's version. Or, here's yet another way to accomplish the same thing:
Code:
Dim x As Integer
Dim b As Boolean
x = 4
b = x <> 0
If b Then
'...
All I've done is explicitly create a boolean for testing whereas, in Technome's example, it was implicitly created. However, I believe it's safe to say that an "If" statement is always reduced to a TRUE or FALSE Boolean before the decision is made.
Now, how can notthinking of AND, OR, NOT, XOR, IMP, EQV as bitwise get us into trouble? Still using Technome's example, the following is an excellent illustration:
Code:
Dim x As Integer
x = 4
x = Not x
If x Then ' Still evaluates to TRUE.
'...
Try it if you don't believe me.
And then, for using a true logical operator in VB6, we could do:
Code:
Dim x As Integer
Dim b As Boolean
x = 4
b = x <> 5
If b Then ' Evaluates to FALSE.
'...
Or, we could shorten it to:
Code:
x = 4
If x <> 5 Then ' Evaluates to FALSE.
'...
In that last example, we can appreciate that an implicit temporary variable is being created before the decision is made.
So, the take-home message is that it's important to appreciate the differences in bitwise versus logical operators. Now, how might we get into trouble trying to use Booleans as Integers. Here's a novel piece of code (wrapped into a Form_Load for you to easily examine):
Code:
Option Explicit
'
Private Declare Function GetMem2 Lib "msvbvm60.dll" (ByRef Source As Any, ByRef Dest As Any) As Long ' Always ignore the returned value, it's useless.
'
Private Sub Form_Load()
Dim i As Integer
Dim j As Integer
Dim b As Boolean
i = 5
GetMem2 i, b
If b Then Debug.Print "We're TRUE" ' <--- reports as TRUE.
b = Not b ' <-------- Think about what this is actually doing, and how many times you've used a NOT with a Boolean !!!!!
If b Then Debug.Print "We're TRUE" ' <--- still reports as TRUE!!!!!
' How can the above be? It's a Boolean!!!!
GetMem2 b, j
Debug.Print j ' <--- reports -6, which is a bit-flipped 5.
End Sub
This illustrates the true bitwise nature of the NOT operator as well as how treating Booleans as Integers can cause confusion.
Okay, I'll set up some timing tests to answer that point #3.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
This post is about the speed of using various variable types for a boolean. I thought I'd test this with the simple NOT bitwise operator, as the discussion above is mostly about Boolean and making Yes/No decisions.
First, I wasn't sure if VB6 was doing some implicit typecasting when using the NOT operator, so I did the following:
Code:
Option Explicit
Private Sub Form_Load()
Dim bb As Byte
Dim b As Boolean
Dim i As Integer
Dim l As Long
Debug.Print TypeName(Not bb)
Debug.Print TypeName(Not b)
Debug.Print TypeName(Not i)
Debug.Print TypeName(Not l)
End Sub
Happily, it reported...
Code:
Byte
Boolean
Integer
Long
So, hopefully, it's doing the NOT with the variable type being supplied, and not doing any implicit typecasting.
Next, I pulled in my high-precision timer class (TimerEx) and wrote the following code:
Code:
Option Explicit
Private Sub Form_Load()
Dim bb As Byte
Dim b As Boolean
Dim i As Integer
Dim l As Long
Dim dStart As Double
Dim dDelta As Double
Const cnt As Long = 100000000
Dim idx As Long
Debug.Print "Instantiate: "; TimerEx.Value ' Just to get it instantiated.
dStart = TimerEx.Value
For idx = 1& To cnt
bb = Not bb ' Flip bits on a Byte type.
Next
dDelta = TimerEx.Value - dStart
Debug.Print " Byte: "; dDelta
dStart = TimerEx.Value
For idx = 1& To cnt
b = Not b ' Flip bits on a Boolean type.
Next
dDelta = TimerEx.Value - dStart
Debug.Print "Boolean: "; dDelta
dStart = TimerEx.Value
For idx = 1& To cnt
i = Not i ' Flip bits on an Integer type.
Next
dDelta = TimerEx.Value - dStart
Debug.Print "Integer: "; dDelta
dStart = TimerEx.Value
For idx = 1& To cnt
l = Not l ' Flip bits on a Long type.
Next
dDelta = TimerEx.Value - dStart
Debug.Print " Long: "; dDelta
End Sub
Interestingly, Boolean, Integer, and Long all ran neck-and-neck, with Byte being half the speed. I ran it several times, but here's a typical output of my test:
Just to make sure the code-order wasn't somehow making a difference, I put the Byte test at the bottom, but the results were approximately the same. Therefore, there's certainly no advantage to using Byte variables as Booleans. And, there doesn't seem to be any advantage to trying to match our register sizes either.
Then, it dawned on me that running as machine code (rather than p-code) might make a difference, so I compiled it. Compiled, here are the results I got (two runs):
So, the Byte type definitely ran better compiled, and Integer and Long depreciated with respect to Boolean. Therefore, when considering either compiled or p-code, it seems that Boolean is our best choice.
I've also attached the entire project for anyone interested. The Project1 is for running in the IDE, and Project2 is for compiling (writing results to a file). You'll need to patch up your file's path if you play around with the compiled version. Both projects share the TimerEx class.
Best Regards,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I even use it when coding in C, although I'm definitely an outcast using Hungarian and CamelCase in that community. But it just seems ideal to me, especially for any strongly typed language such as VB6 or C.
Now, I often do coding in MatLab and PHP, both loosely typed languages. PHP is particularly loosely typed. It's as if you're coding in VB6, but the "Option Explicit" statement has been taken away from you, all "Dim" statements have been removed, and every variable is always declared as a Variant. It's near impossible to just look at a variable and determine what type it is, and it can easily change types with a trivial operation.
Personally, I highly prefer strongly typed languages. It's just one less thing I must keep track of when writing code, or coming back to code I haven't looked at in a while.
Just My Humble Opinion,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
thanks for testing it.
compiled is always the choice of testing speed, i have encountered this before that IDE <> Compiled is so different we can't even compare it.
so, conclusion is that byte/boolean are the almost identical in speed, the difference is very little, but if we do have thousands of variables, byte is better to use for true/false as it will also use less memory.
also, with byte, we could have "0=undefined,1=false,2=true", to mimic the undefined properties some languages have.
too bad we dont have signed byte, -128 to 127, something i would request in VB7.
...but if we do have thousands of variables, byte is better to use for true/false as it will also use less memory.
Yeah... no... that's not the take away at all... a byte isn't going to take up "less" memory... a boolean and a byte will "use" the same amount because of byte boundaries... technically speaking a boolean only really needs is a single bit - it's either on(1) or off(0) ... there is no other variance to it. But because of addressing you can't access a single bit in memory... so you have to access the entire byte.... so you end up with 00000000 or 11111111 ... again, this goes back to some of the things that elroy was talking about when we try to coerce a boolean into an integer (or the other way around) ... and it's because of memory addressing issue. So in a practical sense, a boolean should use less memory, but for technical reasons, the realities of it is that a boolean and byte will use the same amount.
Originally Posted by baka
also, with byte, we could have "0=undefined,1=false,2=true", to mimic the undefined properties some languages have.
Are you talking about a byte boolean or a byte byte? I disagree in both cases... a boolean has two values... true or false... it's binary... it shouldn't be allowed to have any other value. It can be nullable, but that's not a value... that's a non-value... an unknown... which is different.
Originally Posted by baka
too bad we dont have signed byte, -128 to 127, something i would request in VB7.
Ick.... I can't even fathom a reason for needing a negative byte...
Private Type MyBool
var1(5000) As Boolean
var2(10000) As Boolean
End Type
Private Type MyByte
var1(5000) As Byte
var2(10000) As Byte
End Type
Dim MBool As MyBool
Dim MByte As MyByte
Private Sub Form_Load()
Dim FileSave%
FileSave = FreeFile
Open App.Path & "\Bool" For Binary Access Write As #FileSave
Put #FileSave, , MBool
Close #FileSave
Open App.Path & "\Byte" For Binary Access Write As #FileSave
Put #FileSave, , MByte
Close #FileSave
End Sub
Bool is 30 004 bytes
Byte is 15 002 bytes
maybe in memory they are the same, but still it counts.
Hmmm, I should probably stay out of this memory debate, but I'll weigh in anyway.
Personally, for me, I think it'd take millions (or maybe even billions) of "flags" (i.e., boolean indicators) before it'd make any significant difference with respect to memory usage. And, if I had some program that needed that, I'd possibly consider using individual bits as Techgnome suggested. I'd possibly write some function that kept a static internal array of bytes, where you could ask it questions like, "is the 126543940th bit on?" A function something like "Function IsBitOn(lngBitNumber) As Boolean". It'd probably be slightly slower than either a Boolean or Byte array, but I doubt it would be much slower, and it'd be far more memory efficient.
Now, regarding memory boundaries, Techgnome is correct with respect to individual variables. Other than within UDTs and Arrays, as far as I know, variables always start on a four byte boundary in compiled code. However, in p-code, they might start on any two byte boundary. As a quick check of that, we might do the following:
Code:
Option Explicit
Private Sub Form_Load()
Dim bb1 As Byte
Dim bb2 As Byte
MsgBox Hex$(VarPtr(bb1))
MsgBox Hex$(VarPtr(bb2))
End Sub
You're certainly welcome to try it with other variable combinations.
Now, if we're talking about arrays or UDTs, things are different. In arrays, the individual elements will always be contiguous, based on the type of variable. UDTs can get complex, but if we're only talking about Bytes, Integers, or Booleans, they are actually also aligned contiguously, Bytes on 1 byte boundaries, Integers and Booleans on 2 byte boundaries.
Here's some code to test a UDT for Bytes:
Code:
Option Explicit
Private Type udt
bb1 As Byte
bb2 As Byte
End Type
Private Sub Form_Load()
Dim u As udt
MsgBox Hex$(VarPtr(u.bb1))
MsgBox Hex$(VarPtr(u.bb2))
End Sub
You're welcome to test it for Booleans and Integers as well.
So, to answer the question about memory, it depends on how we structure our code.
-----
Regarding signed versus unsigned, I truly wish we had a full compliment of both signed and unsigned for all of Byte, Integer, Long, and LongLong. For me, it'd be great if we had the types SByte, UInteger, ULong, and ULongLong. I think the meaning is self-evident. And maybe even UByte (equivalent to Byte), SInteger (equivalent to Integer), and SLong (equivalent to Long). But I suspect that's all wishful thinking.
Best Regards,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
If I were truly worried about memory usage, here's what I'd do. And yeah, I used a Byte array as my storage.
Code:
Option Explicit
'
Dim MyBits() As Byte
Dim MyBitsDimmed As Boolean
'
Private Sub Form_Load()
Debug.Print IsBitOn(12345)
IsBitOn(12345) = True
Debug.Print IsBitOn(12345)
IsBitOn(12345) = False
Debug.Print IsBitOn(12345)
End Sub
Private Property Get IsBitOn(iBit As Long) As Boolean
' iBit is zero based, but can't be negative.
'
Dim iByte As Long ' Also zero based.
Dim bbBit As Byte
'
If iBit < 0 Then Error 5
'
iByte = iBit \ 8&
bbBit = iBit Mod 8&
'
If Not MyBitsDimmed Then Exit Property ' Return False.
If UBound(MyBits) < iByte Then Exit Property ' Return False.
'
IsBitOn = MyBits(iByte) And bbBit
End Property
Private Property Let IsBitOn(iBit As Long, bValue As Boolean)
' iBit is zero based, but can't be negative.
'
Dim iByte As Long ' Also zero based.
Dim bbBit As Byte
'
If iBit < 0 Then Error 5
'
If Not bValue Then
If Not MyBitsDimmed Then Exit Property ' Nothing to do.
If UBound(MyBits) < iByte Then Exit Property ' Nothing to do.
End If
'
' Make sure we've got the space.
iByte = iBit \ 8&
If Not MyBitsDimmed Then
ReDim MyBits(iByte)
MyBitsDimmed = True
Else
If UBound(MyBits) < iByte Then ReDim Preserve MyBits(iByte)
End If
'
' Set our bit, True or False.
bbBit = iBit Mod 8&
If bValue Then
MyBits(iByte) = MyBits(iByte) Or bbBit
Else
MyBits(iByte) = MyBits(iByte) And Not bbBit
End If
End Property
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
not sure theres a benefit to store each boolean as bit. it will only slow it down and we are talking about very little memory gain.
but, as my example above, 15k or 30k theres a slice difference.
i will be using a UDT that contains +50 variables, strings, integer, single, bytes etc.
theres will be unknown amount of arrays that will use that UDT. it could grow above 1000 that need to be in memory and also be able to load/save.
sure i will just use around 10 boolean for each UDT, so, say its 1000 items, it will just be 20k of memory if boolean and 10k if byte, its not much.
but, since byte and boolean are equal in speed and it byte is ½ the size of boolean. byte is better than boolean.
I'd possibly write some function that kept a static internal array of bytes, where you could ask it questions like, "is the 126543940th bit on?" A function something like "Function IsBitOn(lngBitNumber) As Boolean". It'd probably be slightly slower than either a Boolean or Byte array, but I doubt it would be much slower, and it'd be far more memory efficient.
Bit-packing... it's actually a common thing to do ... or used to be back in the day. Most commonly I've seen it used for is combining flag values.
Just to make sure the code-order wasn't somehow making a difference, I put the Byte test at the bottom, but the results were approximately the same. Therefore, there's certainly no advantage to using Byte variables as Booleans. And, there doesn't seem to be any advantage to trying to match our register sizes either.
Then, it dawned on me that running as machine code (rather than p-code) might make a difference, so I compiled it. Compiled, here are the results I got (two runs):
So, the Byte type definitely ran better compiled, and Integer and Long depreciated with respect to Boolean. Therefore, when considering either compiled or p-code, it seems that Boolean is our best choice.
I compiled with
Remove Array Bounds
Remove Integer Overflow
Remove Floating Point Error
Allow Unrounded Floating Point Operations
Remove Safe Pentium(tm)FDIV Checks
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Option Explicit
Const cnt As Long = 100000000
Dim cTim As TimerEx
Dim dLng As Double
Dim dInt As Double
Dim dByt As Double
Dim dBln As Double
Private Sub Form_Load()
Set cTim = New TimerEx
Open "timing.txt" For Append As 1
Print #1, "Instantiate: "; cTim.Value ' Just to get it instantiated.
test_long
test_bool
test_byte
test_int
Print #1, "Integer: "; dInt
Print #1, "Byte: "; dByt
Print #1, "Boolean: "; dBln
Print #1, "Long: "; dLng
Close 1
End Sub
Private Sub test_long()
Dim l As Long
Dim dStart As Double
Dim idx As Long
dStart = cTim.Value
For idx = 1& To cnt
l = Not l ' Flip bits on a Long type.
Next
dLng = cTim.Value - dStart
End Sub
Private Sub test_bool()
Dim b As Boolean
Dim dStart As Double
Dim idx As Long
dStart = cTim.Value
For idx = 1& To cnt
b = Not b ' Flip bits on a Byte type.
Next
dBln = cTim.Value - dStart
End Sub
Private Sub test_byte()
Dim bb As Byte
Dim dStart As Double
Dim idx As Long
dStart = cTim.Value
For idx = 1& To cnt
bb = Not bb ' Flip bits on a Boolean type.
Next
dByt = cTim.Value - dStart
End Sub
Private Sub test_int()
Dim i As Integer
Dim dStart As Double
Dim idx As Long
dStart = cTim.Value
For idx = 1& To cnt
i = Not i ' Flip bits on an Integer type.
Next
dInt = cTim.Value - dStart
End Sub
[RESOLVED] whether boolean has a symbol ?
Reply With Quote
Originally Posted by Elroy
