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