#78973 - 2002-06-14 10:29 AM
BUG: Double variable inside string not evaluated.
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
KiXtart environment:
Windows 95
KiXtart 4.10 RC2.
While playing with the new variable types I noticed that "double" variables within strings are not evaluated. Integers are fine. Here is some code which illustrates this:
code:
$v=0.0+3/2
"v=" $v ", type=" VarTypeName($v) ?
"v=$v, type=" VarTypeName($v) ?
$v=3/2
"v=" $v ", type=" VarTypeName($v) ?
"v=$v, type=" VarTypeName($v) ?
Results are:
quote:
v=1, type=Double
v=, type=Double
v=1, type=Long
v=1, type=Long
|
|
Top
|
|
|
|
|
#78977 - 2002-06-17 09:46 AM
Re: BUG: Double variable inside string not evaluated.
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Lonkero,
The rsult of "aa" + 3 is a string "aa3", which is exactly the same as all other conversions, i.e. the result of every expression is a value of the type of the coercing element.
Here is a good example. Have a guess what the result of this will be:
code:
$x="x" + 3.0/2 + 5.0/2 + 7/2
It's not as obvious as you might at first think. The answer is:
code:
$x=x1.52.53, type=String
The reason for this is precedence. You have to take each sub expression abd resolve them first, in the order of precedence:
quote:
3.0/2 = 1.5 (coercing value is a float)
5.0/2 = 2.3 (coercing value is a float)
7/2 = 3 (coercing value is an integer)
"x"+1.5 = "x1.5" (coercing value is a string)
"x1.5"+2.5 = "x1.52.5" (coercing value is a string)
"x1.52.5"+3 = "x1.52.53" (coercing value is a string)
The result is correct and is consistant with all the type conversion rules.
The problem is that it is horribly confusing and will make coding with the new types a complete nightmare. You will have to be so careful when constructing expressions.
Because of automatic type conversion it is all too easy to convert your double to an integer, then use that in another expression later on.
The variable may have the right value, but it will have the wrong type, so expressions which use it may give the wrong results..
This will make debugging very hard, and means that the new variable types are not reliable.
Unless it is simple the only way to ensure that your code is absolutely safe is to wrap each element of the expression in the new type conversion functions, i.e.
code:
$y=1
$x=5+$y/3
won't work because both "5" and $y are integers.
code:
$y=1
$x=CDbl(5)+Cdbl($y)/Cdbl(3)
Will always work, whether $y is an integer or double as Cdbl() coerces the type.
|
|
Top
|
|
|
|
#78979 - 2002-06-18 09:18 AM
Re: BUG: Double variable inside string not evaluated.
|
Ruud van Velsen
Developer
Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
|
In short: absolutely correct ![[Smile]](images/icons/smile.gif)
The type of a (sub)expression is based on the leftmost operand. And in the last example, 5/2 is evaluated first (due to operator precedence).
Ruud
|
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 657 anonymous users online.
|
|
|
