Boost logo

Boost :

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2012-02-09 08:06:56

On 2.2.2012. 16:18, Domagoj Saric wrote:
> On 1.2.2012. 17:53, Hite, Christopher wrote:
>>> On 27.1.2012. 11:32, Domagoj Saric wrote:
>>> k) the lifetime management pointer is now stored after the actual contained
>>> object (this helps in avoiding more complex/offset addressing when accessing
>>> optionals through pointers w/o checking whether they are initialised)
>> Seems weird. If the front of T is more likely to be used (and old char buffer),
>> your pointer may wind up in a different cache line.
> Well yes, as I said this benefits only the cases where the pointer/bool is not
> accessed (when an optional is accessed through a pointer/reference). IOW in
> 99.9% of real world cases the point is quite moot but it did make sense at a
> particular stage of a project I'm working on (when you have dozens of hundreds
> of template generated functions you can actually measure savings in code size
> when you do even such micromanagement). It no longer matters for me but the
> layout of optional2 is still like that (currently) purely because it turned out
> like that (in the current stage of development) so I wrote point (k) nonetheless
> just for the feedback ;)

Actually I forgot a, personally, much more important reason why placing the
contained object at the beginning/same address as optional itself was more
My optional use cases generally fall into two categories, optionals of
fundamental types (bools, ints and floats) and small PODs and optionals of
nontrivial GUI objects. The latter case usually looks like this (a compile-time
generated Model-View-Controller design where the "controller" is "short
circuited" for simplicity and efficiency):

template <typename T>
class Model
   optional<View<Model>> optionalGUI_;

Without a "controller", View<Model> needs to access its Model instance and
instead of storing a Model pointer it can simply deduce its address from its own
address (knowing that Views only ever exist as members of Models). When View is
inside an optional it first needs to calculate the address of
optional<View<Model>> from its own address and then the address of the Model
parent from the optional address. And the crux of the problem is: to calculate
the address of the optional it needs to know the layout of optional...

(Incidentally the current/original optional allowed for an ugly way to calculate
the offset of the contained object by using a helper class that derives from

"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman

Boost list run by bdawes at, gregod at, cpdaniel at, john at