[boost] Re: inert_bool

From: Ed Brey (brey_at_[hidden])
Date: 2003-09-08 08:51:58

Douglas Gregor wrote:
> On Friday 05 September 2003 02:43 pm, Ed Brey wrote:
>> struct inert_bool_structure {};
>> typedef inert_bool_structure const* inert_bool;
> 
> This allows several things we'd rather not allow:
>   shared_ptr<T> p;
>   p + 2; // not quite what we expected
>   delete p; // dangerous
     function_obj == p  // bool comparison may be unexpected.
     void const* v = p

These are all well-observed imperfections.  (I tacked on the last two myself, to get the issues in one place.)

In the "p + 2" case, it would be better if the code didn't compile; OTOH, the results don't break from boolean semantics, so doesn't seem likely to confuse anyone.

The "delete p" case is fixed with a private destructor, i.e.:
struct inert_bool_structure { private: ~inert_bool_structure(); };

In the equality between different classes case, we enter mixed metaphor land.  By one school of reasoning, if you can say:

if (function_obj) ...
and
if (shared_ptr_obj) ...
and 
if (function_obj && shared_ptr_obj) ...

then wouldn't

if (function_obj == shared_ptr_obj) ...

be a logical extension?  A counter argument is that this isn't the only way to think of the scenario, and a coding error can occur when someone is quite reasonable thinking in terms of content equality.

The void const* conversion case could hide a nasty bug, since the meaning subtly changes in shared_ptr by forgetting the .get().  No solution comes to mind for this.

The problems with inert_bool seem great enough to kill it.  It is a shame in a way, since the efficiency problem of the pointer to member approach affects each usage, even though the added safety comes in handy only rarely.

Unless I missed something bool_testable only provides half the problem: it provides operator!, but not the implicit bool conversion.  Perhaps the thinking is to add a templated bool conversion.  This would solve the heterogeneous class comparison problem, but not the void const* problem.  Still, maybe it is the best compromise.

An entirely different approach is to use a null class.

struct null_t {
    template<typename T> operator T*() const {return 0;}
};
null_t const null;

template<typename T> inline bool operator==(shared_ptr<T> const& p, null_t) {return p.get() == 0;}
template<typename T> inline bool operator==(null_t, shared_ptr<T> const& p) {return p.get() == 0;}
template<typename T> inline bool operator!=(shared_ptr<T> const& p, null_t) {return p.get() != 0;}
template<typename T> inline bool operator!=(null_t, shared_ptr<T> const& p) {return p.get() != 0;}

In this approach, shared_ptr wouldn't include any boolean operator at all.  Instead, code using would look like this:

if (p != null) ...

Not as nice an terse as just "if (p)", but safer and more explicit, and still prettier, IMHO, than "if (p.get())".  A side benefit to this approach is that a null object would be a nice utility addition to boost anyway, since it is less ambiguous than 0 (although it doesn't work on pointer to members ... ah those pesky tradeoffs).

Further thoughts?

Ed