Boost logo

Boost :

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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk