"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4AC4EDDE.5070606@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