$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [optional] layout
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2009-10-02 07:20:57
"Steven Watanabe" <watanabesj_at_[hidden]> wrote in message
news:4AC4EDDE.5070606_at_providere-consulting.com...
> These two structs should both take up 16 bytes.
> You don't save anything by reordering the
> members.
true :blush: should've checked the issue beforehand ;)
but it was more of a side note/'thought' anyway...my main concern was with
following issue...
>> and, more importantly, it forces pointer offset adjustment/calculation
>> when accessing a boost::optional<> through a pointer (and trying to
>> access the actual contained object)...
>>
>
> Is the difference in performance actually measurable in any way?
well, "actually measurable difference in performance" is, imho, kind of a
"grey area"/"subjective metric"...and a library should not, imnho, make
'real world' usage assumptions if it does not have to...and in this case, as
far as i can see/imho, it does not have to...that is, from the standpoint of
boost::optional<> it makes no difference what layout it uses, but one of
those layouts does cause the usage of more complicated addresing modes/extra
adjustment code (depending on the platform) in certain cases...the fact that
this is infinitesimally insignificant compared to a single default
construction of a std::sstream ;-D makes no difference (if i am not mistaken
with the assumption that the actual layout makes no difference from the
boost::optional<> point of view)...
-- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley