From my initial look through boost::optional's implementation, it seems as
though it's doing nothing to optimize its space usage in some trivial cases.
The first one I was surprised by was optional - still uses sizeof(struct
{ T& t; }) + sizeof(bool) space, rather than simply using a pointer to
represent both the reference and the unspecified state (using null, since a
reference doesn't use that state). Is there a reason for this (perhaps I'm
missing something & a reference is smaller than a pointer in certain
implementations).
Similarly - would it be worth considering optimizing optional<bool> (though,
as per the documentation, this is perhaps a little "tricky" at best, owing
to the implicit bool of optional itself) to use one byte instead of two?
[long term - I'm wondering if a generic "efficient optionality" could be
implemented by arbitrary types - privately exposing an extra unused state
from their representation for use by optional only. Then, potentially,
making versions of (boost/std)::shared_ptr/unique_ptr that would be
never-null (only constructible via make_shared like machinery) &
optional would then be an explicit representation of
the optional situation, but without any overhead - shared_non_null_ptr<T>
would simply expose its null state only to optional]
