Re: [boost] [optional] generates unnessesary code for trivial types

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

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