XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML design of ((a and b) or c)

On 12/15/06, Rick Marshall <rjm@zenucom.com> wrote:
> Hi Ken
>
> The point here is quite subtle and VERY important.
>
> Let's just take "a AND b" or "a & b" to reduce the overloading of the
> word and.
>
> Now if a and b are atomic and & is commutative the the order of
> evaluation is unimportant and optimisers can play around to suit themselves.
>
> However, if a or b are not atomic and the calculation of either has side
> effects then "a & b" is no longer commutative and optimisers cannot stop
> the calculation on detection of a or b being false.
>
> Unless of course we agree to use slightly different mathematics: "a & b"
> is not commutative; it is evaluated left to right; and evaluation stops
> if a is false. This can then be extended to "a & b & c ...".
>
> Now the "a & b" of computer languages is fundamentally different to the
> "a & b" of mathematics although they degenerate to the same thing if a
> and b are atomic.
>

Just to be sure,  &  is different from && on C.

& is the and operation betwen bits, the result is a integer
&& is the and operation betwen booleans, the result is a boolean

0x0F & 0xF0 result to 0
0x0F && 0xF0 result to true

You will not use & for shortcuts, but &&.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS