David Abrahams wrote: > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > >> Yes, exactly. Sorry if I wasn't precise enough. >> >> The bool type will cancel type_with_alignment<> effects (at least on >> Intel compatible platforms); i.e. unique alignment of each >> optional<T> type. > > Sounds like you want > > type_with_alignment<T>::type storage; > new ((void*)&storage) T(x, y, z) > > Can you really do anything to make this cleaner? I guess: > > aligned_storage<T> storage; > new (storage.bytes) T(x, y, z); > > might be a help. What else are you gaining? And how do you destroy > the T? If not explicitly and you don't have a "constructed" flag, > you're going to have exception-safety problems.
Everything seems already defined ;) Given the fact optional<>::m_storage is aligned like a bool...: - Maybe aligned_storage<> should always destruct its object. It would be the user's responsability to construct the object before its destruction, otherwise the result would be undefined. - Maybe we could create 2 separate type lists if optional<> is used many times in the same object, gathering m_initialized types and m_storage in separate lists: struct A { optional<char> i; // bool alignment optional<short> l; // bool alignment optional<double> d; // bool alignment }; Could be transformed into: struct A { typedef optional_typelist< typelist<char, short, double> > optional_members; typedef array<bool, optional_members::size> optional_inits; optional_inits init; // Array of booleans optional_members storage; // Typelist storage }; In this example, optional_typelist<T1, T2, T3, ...> would be a list of optional<T1>, optional<T2>, optional<T3>, ... It could be simplified even more, but this is just a suggestion. Philippe A. Bouchard _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost