xsharp.eu

Hi Wolfgang,

Clipper did not have strongly typed string vars, so you can not really compare its behavior to VO. (well, it's been a lot of years since I last wrote anything in Clipper, hope I am not saying something extremely stupid!

Chris

Hi Chris,

no, you are right: Clipper has no strong typing. But it had this strange and illogical behavior for string compares, where
and
gave different results.

Wolfgang

From 5.3 (non character examples skipped)

//--------------------------------------
<> != #
Not equal--binary (Relational)
------------------------------------------------------------------------------
Syntax

<exp1> <> <exp2>
<exp1> != <exp2>
<exp1> # <exp2>

Type

Character, date, logical, memo, NIL, numeric

Operands

<exp1> and <exp2> are expressions of the same data type or NIL
to be compared for inequality.

Description

The not equal ( <>) operator compares two values of the same data type
and returns true (.T.) if <exp1> is not equal to <exp2> according to the
following rules:

. Character: The comparison is based on the underlying ASCII
code and is the inverse of the equal operator (=). This means that
the comparison is sensitive to the current EXACT SETting. See the
examples below.

Examples

. These examples illustrate how the not equal operator (<>)
behaves with different data types:

// Character
SET EXACT ON
? "123" <> "12345" // Result: .T.
? "12345" <> "123" // Result: .T.
? "123" <> "" // Result: .T.
? "" <> "123" // Result: .T.
SET EXACT OFF
? "123" <> "12345" // Result: .T.
? "12345" <> "123" // Result: .F.
? "123" <> "" // Result: .F.
? "" <> "123" // Result: .T.

// ----------------------------------------------------------
= (equality)
Equal--binary (Relational)
------------------------------------------------------------------------------
Syntax

<exp1> = <exp2>

Type

Character, date, logical, memo, NIL, numeric

Operands

<exp1> and <exp2> are expressions of the same data type to
compare.

Description

The equal operator (= ) compares two values of the same data type and
returns true (.T.) if <exp1> is equal to <exp2> according to the
following rules:

. Character: The comparison is based on the underlying ASCII
code. ASCII codes for alphabetic characters are ascending (e.g., the
code for "A" is 65 and the code for "Z" is 90).

When EXACT is OFF, two character strings are compared according to
the following rules. assume two character strings, cLeft and cRight,
where the expression to test is (cLeft = cRight):

- If cRight is null, returns true (.T.).

- If LEN(cRight) is greater than LEN(cLeft), returns false
(.F.).

- Compare all characters in cRight with cLeft. If all
characters in cRight equal cLeft, returns true (.T.); otherwise,
returns false (.F.).

With EXACT ON, two strings must match exactly except for trailing
blanks.


Examples

. These examples illustrate how the equal operator (=) behaves
with different data types:

// Character
SET EXACT ON
? "123" = "123 " // Result: .T.
? " 123" = "123" // Result: .F.
SET EXACT OFF
? "123" = "12345" // Result: .F.
? "12345" = "123" // Result: .T.
? "123" = "" // Result: .T.
? "" = "123" // Result: .F.


//----------------------------------------------------------------
==
Exactly equal--binary (Relational)
------------------------------------------------------------------------------
Syntax

<exp1> == <exp2>

Type

All

Operands

<exp1> and <exp2> are expressions of the same data type to be
compared.

Description

The exactly equal operator (==) is a binary operator that compares two
values of the same data type for exact equality depending on the data
type. It returns true (.T.) if <exp1> is equal to <exp2> according to
the following rules:

. Array: Compares for identity. If <exp1> and <exp2> are
variable references to the same array, returns true (.T.); otherwise,
returns
false (.F.).

. Character: Comparison is based on the underlying ASCII code.
ASCII codes for alphabetic characters are ascending (e.g., the code
for "A" is 65 and the code for "Z" is 90). Unlike the relational
equality operator (=) , true (.T.) is returned if <exp1> and <exp2>
are exactly equal including trailing spaces; otherwise, the
comparison returns false (.F.). SET EXACT has no effect.

Examples

. These examples illustrate how the == operator behaves with
different data types:

// Character
? "A" == "A" // Result: .T.
? "Z" == "A" // Result: .F.
? "A" == "A " // Result: .F.
? "AA" == "A" // Result: .F.

For me, it's not illogical. When setting

SET EXACT OFF
the '=' comaprison is similar to Value:StartsWith( ).

For this reason I had always SET EXACT OFF and used this like.

It simplifies search operations. It's similar to SET SOFTSEEK .

Frank

Hi Frank,

for me it is exactly the other way: I prefer to specify the softseek parameter explicetely each time I execute a seek, and I don't like the implications of Set Exact to off - you have to think over it every time you look at written code. For me, code has to be clear at the first glance, otherwise it is badly written.

Wolfgang

We also eliminated all != between strings and replaced them with !(x == y) in VO. We didn't want to rely on SetExact and some other not known factor to influence to change the behaviour. And the chance that somewhere the SetExact setting would be changed without us knowing it...

If the != comparison between USUAL and string (or USUAL and USUAL?) is extra troublesome, is it an idea to introduce a compiler warning for that special case? that way one can choose to eliminate those one by one.

Regards,
Otto