"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>> 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.
And if the object's constructor throws an exception, what then?
> - 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.
You're really a fiend for low-level optimizations, aren't you?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
