Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-11-24 05:16:41

Daryle Walker wrote:
> Sorry if we discussed this before, but why wouldn't:
> struct no_integers_except_bool
> {
> private:
> // None of these are defined
> operator signed char() const;
> operator unsigned char() const;
> operator signed short() const;
> operator unsigned short() const;
> operator int() const;
> operator unsigned() const;
> operator signed long() const;
> operator unsigned long() const;
> operator signed long long() const;
> operator unsigned long long() const;
> #endif
> operator char() const;
> operator wchar_t() const;
> };
> block the bad effects of having an "operator bool() const"? (Your class
> would inherit from this one.)

We already have this in the operators library, have a look at
bool_testable (currently in CVS only, not in 1.30.2).

> Wasn't there a problem with compilers trying
> to match a Boolean context to all of these operators, leading to
> inaccessibility and ambiguity, instead of using "bool" as an unique exact
> match?

I don't understand what exactly you refer to. Could you elaborate, please?

I think it's also fair to mention that Peter's safe bool idiom (with
returning a member variable pointer instead of a member function
pointer) is superiour if you are not afraid of the more complex
implementation. If you want a safe and easy-to-use base class,
bool_testable is AFAIK the best you can get.

Regards, Daniel

Daniel Frey
aixigo AG - financial solutions & 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at