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

Subject: Re: [boost] [optional] memory use for optional refs and ptrs
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-06 07:11:55

Rutger ter Borg
> 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.

I can imagine it happening sooner with patches to the code and documentation.

> 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.

I imagine it isn't so rare for those in the habit of using optionals, but then again, I find a raw pointer to have just the needed semantics that I wouldn't use optional for that case.  (I don't find myself wanting to have an optional pointer that might be null when present.)

> 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.

That's an interesting scenario, but is it likely that so many pieces would be optional in a single context like that?

(I haven't looked, but I do hope that the bool follows the optional value to reduce padding overhead.)

> 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).

I wouldn't want that to replace the current design, but it would be useful as an alternative to the current design or an extension of it.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.