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