Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-24 22:47:02

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.

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:

    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;

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


Joel de Guzman

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