Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VBA Variables 3

Status
Not open for further replies.

carfreak01

Industrial
Nov 26, 2002
36
0
0
US
Does anybody know why if I write this code in a command button:
Private Sub CommandButton1_Click()
Dim x As Long
x = 2000 * 365
Worksheets("Sheet1").Range("A1").Value = x
End Sub
The program detects an Overflow error,
But if I type the following code:

Private Sub CommandButton1_Click()
Dim x As Long, b As Long, c As Long
b = 2000
c = 365
x = b * c
Worksheets("Sheet1").Range("A1").Value = x
End Sub
It runs perfectly?
 
Replies continue below

Recommended for you

I thought we went through that already. In a actual physical processor, running assembly code, integer operands are passed through an integer ALU. Neither compiler nor assembler can know what the intent is, so the default ALU matches the type of the variable.

To prevent overflow, it's up to the programmer to ensure that a LONG ALU is invoked, which requires at least one operand to be LONG.

TTFN

FAQ731-376
 
But, if the result of the operation is known to be of type LONG, even if the operands are of type INT, shouldn't LONG ALU be utilized?
 
IRstuff, I think "melone" explained my doubt in a more clear way. I'm declaring as LONG the variable in which I am going to store a result of an operation, like "melone" said, shouldn't ALU match the dimension of the variable I'm using to save the information?
 
No, because it's not the same step. The results of the ALU reside in the ALU, and are not in memory. The "=" causes the transfer of the ALU contents to the memory location specified by the LONG variable.

My memory is pretty spotty, but the assembler code would look something like:

LOAD RA, A ;INT register
LOAD RB, B ;INT register
ADD RA,RB ;INT addition
STORE C, RALU ;INT loaded into LONG

There are valid arguments for either convention, but what we have is what we have, and is used by millions of programmers. Most programmers learn this in programming class and know to typecast to LONG if there's a possibility that the result will overflow.

Bear in mind, that the compiler, or Excel, doesn't "know" that your result will overflow, and both are designed to generate the fastest operational code, which is to do an INT Add and store the result to a LONG.

TTFN

FAQ731-376
 
Wouldn't the disassembly look closer to:

LOAD RA, A ;INT register
LOAD RB, B ;LONG register
ADD RA,RB,RB ;RA + RB and stored into RB
 
Depends on the ALU architecture and the microcode. Most HLLs were written when ALUs had a separate results register. And, to maintain compatibility, the least common denominator applies, so any processor that does a combo instruction is generally not supported, except with inline code, since it would otherwise result in different behavior with an older processor.

TTFN

FAQ731-376
 
Sorry to beat a dead horse - just thought of another angle that may or may not be of interest.

? 2*(2&*17000) returns 68000
? 2&*(2*17000) causes an error.

It reminds us that expressions are evaluated in an order determined by the parsing algorithm. The stuff in paranetheses is evaluated first. And in the above case this evaluation is not sensitive to the context (the context being what will the results of the stuff in brackets be multiplied by)

Likewise an assignment statment is evaluated and excuted in an order. We evaluate the right hand side, then we plug it into the left. The evaluation of the rhs is not particularly sensitive to the context (the context being what type of variable are we going to plug it into).

High level languages are sometimes very sensitive to the context and protect us from errors by analysing the context very carefully. Lower level languages do not in general protect us as much.

=====================================
Eng-tips forums: The best place on the web for engineering discussions.
 
I tried to look through the replys to see if this had been noted before - but since the calculation apperently causes an overflow due to the calculation being performed on integer values instead of long values - then if carfreak had just used his pocket calculator to comput 2000*365=730000

and used the following code:

Private Sub CommandButton1_Click()
Dim x As Long
x = 730000
Worksheets("Sheet1").Range("A1").Value = x
End Sub

then he never would have discovered this?

Best regards

Morten
 
Sure, but most LLL programmers are quite keenly aware of overflow and spend quite a bit of time manipulating their algorithms to reduce overflow.

Even in regular C, one of the reasons for having typecasting was to provide a means of preventing overflow.


TTFN

FAQ731-376
 
MortenA, in fact, the example I used is the one provided by the help function of the VBA editor. I was searching for some information on the overflow error and since it's a very short and clear example I used it.
Tomorrow when I get to my computer I'll post the code I was having problems with and that I already solve thanks to the info you all provided.
 
Status
Not open for further replies.
Back
Top