[boost] Re: [Fun] (( a xor b )) formal review request...

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-08-21 08:15:52

John Torjo wrote:
> Why macro, and not the straightforward:

Because of the guarantees it gives:

a) Arguments are converted to bool (*)
b) The result is boolean
c) The arguments are evaluated left-to-right
d) There is a sequence point between the argument evaluation

(*) Fernando: This is sometimes what you need and what usually is 
mentioned in the documentation: You need a type convertible to bool. 
This also means that the user can write whatever operator! he likes.
Actually, a) and b) are usually what people think they do, but classes 
with strange operators sometimes lead to surprising behaviour.

c) and d) try to mimic what && and || do, except for short-circuiting 
which can't be done for a logical xor.

Given that a) and b) are not even guaranteed for && and ||, we might 
consider providing three macros:

#define BOOST_DETAIL_AND_HELPER(x) \
static_cast<bool>(x):false

#define BOOST_DETAIL_XOR_HELPER(x) \
!static_cast<bool>(x):static_cast<bool>(x)

#define BOOST_AND )?BOOST_DETAIL_AND_HELPER(
#define BOOST_OR )?true:static_cast<bool>(
#define BOOST_XOR )?BOOST_DETAIL_XOR_HELPER(

Usage:

(( a BOOST_AND b ))
(( a BOOST_OR b ))
(( a BOOST_XOR b ))

That gives you all guarantees a) to d) plus short-circuiting for 
BOOST_AND and BOOST_OR. Well, the syntax is still strange and I don't 
have a use-case for something with the given guarantees, though :)

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de