Any reason not to use XOR?

[Pat Bullman]

Hello Forum,

I always thought that the simplest way to set a variable to either 0 or 1 was with the XOR function, as in the following snippet:

%LIGHT_ON  = 0
%LIGHT_OFF = 1

TYPE Lights
  nStatus as LONG                   ' Must be either %LIGHT_ON or %LIGHT_OFF
END TYPE

SUB SetLightStatus( nLightStatus as long )

  gLight.nStatus = 0 XOR nLightStatus

END SUB


' Usage:

SetLightStatus %LIGHT_ON                         ' Set light status to on

'             or            

SetLightStatus %LIGHT_OFF                        ' Set light status to off

This way gLight.nStatus can only be set to either 0 or 1 (%LIGHT_ON or %LIGHT_OFF) so it's also a form of data checking. I have used this technique in .DLL's used by other parties.

However, it has been suggested (by the young "bulls") that XOR is old-fashioned and that I should be using in-built functions like IIF() or SWITCH() or even a simple IF..THEN statement, but I can't see why.

Surely XOR is not that hard to understand and (from memory) it relates directly to the assembler command - XOR - and must be very effiecient.

Is there a better way of doing this in PowerBASIC?


Pat

[Rodney Hicks]

XOR is one of the tools, and if it's the best tool for the job, use it.

[John Gleason]

Usually the XOR operator is better in a toggle type situation. Although it can be used as you've shown, it's definitely faster to directly set the value when you don't care about its previous state:

gLight.nStatus = %LIGHT_ON
'or
gLight.nStatus = %LIGHT_OFF

[Gary Beene]

I use it all the time, especially to flip state on a menu.

Case %ID_ExcludeTitle
  If Cb.CtlMsg = %BN_Clicked Then   'flip check status
     ExcludeTitle& = ExcludeTitle& Xor 1
     Menu Set State hMenuSyntax, ByCmd %ID_ExcludeTitle, ExcludeTitle&*8
   End If

It gives me a multiplier (1 or 0) to use to set a value of 0 or 8 (check state).

[Michael Mattias]

LightOn = %TRUE | %FALSE

[Eric Pearson]

I prefer this syntax:

ExcludeTitle& = NOT ExcludeTitle&   'produces -1 or 0
Menu Set State hMenuSyntax, ByCmd %ID_ExcludeTitle, -ExcludeTitle&*8  'produces 8 or 1

It's more readable IMO, and in a case like yours, where the code would not be called repeatedly in a short time frame, the number of lost CPU cycles -- if any -- would be trivial.

-- Eric

[Gary Beene]

In this test,

NOT 0 gives -1
NOT 1 gives -2

MsgBox Str$(Not 0)
MsgBox Str$(Not 1)

Did you mean something else?

[Gary Beene]

Sorry MCM,

But I didn't understand your response. Would you clarify what you meant?

[Bern Ertl]

gLight.nStatus = 0 XOR nLightStatus

If the zero is hard coded, you might as well just use:

gLight.nStatus = nLightStatus

[Michael Mattias]

>But I didn't understand your response. Would you clarify what you meant?

Why mess with XOR when %TRUE or %FALSE will do?

[Cliff Nichols]

LightOn = %TRUE | %FALSE

I think the question is...."How the heck is that used????"

inquiring minds would like to know

[Pat Bullman]

Thanks for the response.

While direct usage is the simples, as in:

gLight.nStatus = nLightStatus

it does not do any sort of checking that nLightStatus is either %LIGHT_ON or %LIGHT_OFF, as mentioned in my original post. (The code snippet I originally provided was simply to demonstrate my problem.)

The actual code is used in setting a variety of flags, with the code usually sitting in a dll used by third parties. I could redo the code, like:

FUNCTION SetLightStatus( nLightStatus as long ) EXPORT AS LONG

  FUNCTION = %OK                           ' Set default response

  IF (nLightStatus = %LIGHT_ON OR nLightStatus = %LIGHT_OFF ) THEN

    gLight.nStatus = nLightStatus

  ELSE

    FUNCTION = %FAILED_BAD_PARAMETER

  END IF


END FUNCTION

but when you have many paramenters to check the code becomes messy. Using XOR forces the TRUE or FALSE staus. I could also use SELECT..CASE. It was suggested I use:

gLight.nStatus = IIF&( nLightStatus = 0, %LIGHT_ON, %LIGHT_OFF )

It was also suggested that I use the SWITCH statement, which I've never used before, but it looked congested.

Anyhow, I take it from your responses that XOR is still used, appears suitable for the job and function nicely.

Thanks,


Pat

[Eric Pearson]

Gary --

> NOT 0 gives -1
> NOT 1 gives -2
> Did you mean something else?

No.

NOT 0 gives -1
NOT -1 gives 0

So the value of the variable toggles between those two values, which are the "natural" True and False values for all signed integers.

The math in my Menu Set State line has an added minus-sign to produce 0 or positive 8, which are the values that are required by the API.

There's nothing wrong with using XOR, I just think that NOT is more intuitive and human-readable. For example "IF NOT ExcludeTitle& THEN" reads almost like a plain-English sentence.

-- Eric

[Michael Mattias]

>For example "IF NOT ExcludeTitle& THEN" reads almost like a plain-English sentence.

Sure, if it's Master Yoda speaking.....

[Michael Mattias]

FWIW, ISTRUE() and ISFALSE() exist precisely to deal with "NOT didn't work the way I thought it would"

[Guy Dombrowski]

Why all that fuss about a YES or NO flag ?????

[Gary Beene]

Sorry Eric, I didn't see the minus sign to the left of the word - so I see how yours works.