Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Nevin Liber (nevin_at_[hidden])
Date: 2012-02-13 14:42:27

On 13 February 2012 01:15, Hite, Christopher
<Christopher.Hite_at_[hidden]> wrote:
> We could be having the same conversation about optional<bool>.  Here the documentation is clear: it works as expected but is the user probably should be using tri-state.

Why?  The poster child is database access, where every field can be
set or unset, and every set field has a value.  Why would anyone want
to special case access to bool to use a different type?

> We could optimize optional<bool> to store ~0 to indicate unset.

Could you elaborate?  I don't see how, at least not without changing
the interface, as a "dereferenced" optional<bool> has to return a
reference to bool whose address cannot change.

Please look at vector<bool> to see the trouble caused when people
changed the generic interface for a specific type.

> As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*.  It also allows for debates about the meaning of reassignment.

If there are debates about about the meaning of reassignment, then it
really is NOT equivalent to T*.

> I'm not dead set against this optimization.  I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests.

Do you honestly think it is more work than was put into writing your
email message (let alone all the future threads that will inevitably
keep coming up)?
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]