Rutger ter Borg wrote:
On 2010-10-06 00:19, Fernando Cacciola wrote:
Ok, yes, in that case there is no possible doubt about the semantics, so the boolean can be spared.
OTOH, is such a corner case that I don't imagine myself doing it in the sort term.
Although it isn't the most important case for me, it has its own section in the documentation, and I will probably be using lots of these. What also doesn't seem right to me is that, e.g.,
struct A { int a; double b; double c; std::string d; };
struct B { boost::optional< int > a; boost::optional< double > b; boost::optional< double > c; boost::optional< std::string > d; };
the size of A is 32 bytes in this case, and the sizeof B is 56 bytes: almost doubled. So, while it may be argued that the case above is a corner case, too, I don't it's an acceptable penalty to anyone to pay 24 bytes for something that can be stored in 4 bits and/or in the type itself.
What would make optional useful to me, is a kind of optional that allows the boolean set/get stuff to be done (and possibly stored) outside of the optional itself. E.g., by means free functions that can be overloaded (and throw in the ability of defining tags to the optional template-parameters to be able to define a bit# in a bitset).
Just replicate the tuple interface but accpet and return optional<T> for each element and store it as a bit_vector and a regular tuple internally. Call it tuple_optional or tuptional or some such. Such a library could be implemented, documented, tested and ready for review in about one week flat, but I have no interest in either writing it or using it. I don't use optional either. Regards, Luke