Re: [boost] [optional] memory use for optional refs and ptrs

Subject: Re: [boost] [optional] memory use for optional refs and ptrs
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-10-06 13:19:07

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