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
> 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]> (847) 691-1404
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk