Domagoj Saric wrote:
...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...
Make createUI the constructor and destroyUI the destructor.
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...
That's a good point. You initialize things in groups so you don't need a boolean per thing. The solution is easy: instead of a structure of optional things, make an optional structure of things; you transform N booleans into one, as expected.
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)
You know what position a tuple element is going to be in before initializing the tuple, surely.
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...
Well, first, I don't think this is so easy. Are you taking into account that constructing the subsequent elements might throw, and that you therefore need to destruct the previous ones? Otherwise, I don't understand that point, since tuples and loops aren't exactly things that go well together. Maybe you meant something else than tuples when you were talking of fusion containers?
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...
shared_ptr already provides delayed construction, I don't see why you would want to use optional here? Because you want to store the memory in static memory maybe? For that, just use boost::aligned_storage and placement new, works with shared_ptr like the rest just fine.