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

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Hite, Christopher (Christopher.Hite_at_[hidden])
Date: 2012-02-14 05:29:16

> Nevin Liber wrote:
> 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?
I get that use case.  You're writing a DB wrapper and you've got optional strings,doubles,ints, and bool should work with the exact same semantics.  Sure then use optional<bool>.

> > 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.
Sure, you could implement it with 1 byte (or whatever sizeof(bool) is) and store ~0 to indicate unset.
operator*() can return the address of the byte.  This works because you should never call this if it is empty.

        optional<bool> ob=true;
        bool& b =*ob;  //fine
        b=false; // legal
        ob=none; //b is no longer a valid ref = same as any other T

You should never set b to ~0, but that is bad form anyway and most compilers give warnings when assigning ints to bools lke that.  Consider this:
        int i=256;
        bool b=i;  //is b 0?

Still I don't recommend doing strange things like this.  However if someone came and said "my DB app stores tons of optional<bool> and it's burning twice the storage it needs", well I guess it couldn't hurt right?

> If there are debates about about the meaning of reassignment, then it really is NOT equivalent to T*.
You can convert a T* to and from optional<T&>.  So in that sense they are equivalent.  Syntactically they are very close except when being assigned.

Chris