Re: [boost] [optional] layout

Subject: Re: [boost] [optional] layout
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-10-27 19:13:09

"Mathias Gaunard" <mathias.gaunard_at_[hidden]> wrote in message
news:ha5309$6jc$1_at_ger.gmane.org...
Domagoj Saric a écrit :

>> ps. it would be 'cool' if all of the functionality from boost::optional<>
>> not related to the 'is initialized' bool (conditional destruction, etc...)
>> could be extracted into a separate class (usefull for cases where you have
>> to delay/in-place construct an object but are certain that you will
>> construct it by the point where it needs to be used or destroyed...so you do
>> not need the 'conditional' overhead)...
>
>
>If you are sure that the optional gets initialized, then there is no point in
>such a thing to begin with.
>
>Simply don't declare your object before you can initialize it. If you can't,
>that probably means you need to reorganize your code.

that's true for 'most' code but not all...otherwise placement new would be 
equally 'pointless'/indication of bad design/code organization...
...because that is what i was whishing for to be extracted from optional<> - 
the placement new/in-place construction + aligned storage + reference 
workarounds&co. wrapped up machinery...

...for example:
1.
template <class Data, class Widget>
class DataWithUI : public Data
{
  void createUI();
  void destroyUI();
  boost::optional<Widget> ui;
}

where ui is always created after data and always destroyed before data...and 
there are many such pairs...if all uis are created and destroyed at the same 
time (for example with/by their parent) there is no need to track their 
lifetime individually hence no need for the individual bools for each 
"optional" ui...

2. you have fusion containers of non default constructible objects and/or 
objects that you cannot construct all at once (a trivial example: one of the 
parameters to the constructor of the objects is the order/index of the object 
in the fusion container) but need to, for example, construct them in a 
loop...so you wrap that fusion container and ensure proper 
construction/initialization and complete destruction in the 
constructor/destructor of the wrapper - this then gives you single 
deterministic points of construction and destruction (for all the contained 
objects) making the individual bools redundant...

3. the simple bool/true-false lifetime management is not enough for a 
situation, e.g. you have a  reference counted singleton...then the following 
source code:
...
boost::optional<Singleton> singleton;
...
if ( !ref_count++ )
  singleton = boost::in_place();

will actually produce the following binary code
if ( !ref_count++ )
{
  if ( singleton.is_initialized() )
    ~singleton();
  singleton = boost::in_place();
}

with similar redundancy in the destructor...

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley