Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2003-11-27 00:20:57

On 11/24/03 10:47 PM, "Joel de Guzman" <joel_at_[hidden]> wrote:

> David Abrahams <dave_at_[hidden]> wrote:
>> "Joel de Guzman" <joel_at_[hidden]> writes:
>>>> I know that. I was asking about bool_testable. Wasn't that the
>>>> component under discussion? It's a completely different technique,
>>>> IMO.
>>> I thought so. IMO, it is safe_bool that should get a fast-track
>>> review.
>> safe_bool is an idiom, not a library component. Anyone's already free
>> to use the idiom. I don't think we can review it on that basis.
> Hmmm... It would be nice if we had only one implementation somewhere
> in utilities perhaps. A single implementation will help avoid reimplementing
> the same wheel. Yes, it's a simple code, but there are some hidden issues
> such as Borland's inability to grok the member pointer trick.

Well, the safe_bool operator is usually used as the core Boolean routine, so
it fundamentally _cannot_ be provided by a library. All operator helper
classes need an author-provided core routine, so your suggestion would just
move the author-provided code somewhere else.

> IIUC, what you mean is that we do not have to review something like that.
> Ok, but it would still be good to have a single implementation. Spirit uses:

Actually, a single implementation is a _very_ bad idea!

> struct safe_bool_impl
> {
> int* dummy;
> };
> typedef int* safe_bool_impl::*safe_bool;
> inline safe_bool
> make_safe_bool(bool cond)
> {
> return cond ? &safe_bool_impl::dummy : 0;
> }
> and it is used all throughout. Example:
> template <typename T>
> inline match<T>::operator safe_bool() const
> {
> return make_safe_bool(len >= 0);
> }
> Borland, for one, does not like this code and I had to disable it:
> typedef bool safe_bool;
> inline safe_bool
> make_safe_bool(bool cond)
> {
> return cond;
> }

The problem is that for EVERY non-composite built-in type, there is a "bool
operator ==(T, T)" generated by the compiler. This means that every type
that shares a safe-bool is (in)equality-comparable with each other via a
single step automatic conversion! You have to fix this by creating == and
!= operators for every type combination, making the combinations that aren't
supposed to be comparable give some sort of compile-time error instead
(a.k.a. "poisoning"). This results in so much pointless busy work that it's
just better to give up and provide separate safe-bool's for each class you

BTW, Spirit does have a solution for this problem, right? Otherwise, you
have a major bug!

(Note that no matter how you define Boolean-conversion, you need to
explicitly provide operators == and != for your type, "poisoned" if such
objects aren't supposed to be comparable, and conventional if they are.)

> Perhaps other people might have a better workaround for Borland.
> In the same vein, perhaps there are other compilers that need
> some more workarounds?


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