Re: [boost] [type-traits] aligned_storage in unions

Subject: Re: [boost] [type-traits] aligned_storage in unions
From: dherring_at_[hidden]
Date: 2010-09-20 11:50:18

On Sat, 18 Sep 2010, Larry Evans wrote:
> On 09/17/10 13:31, OvermindDL1 wrote:
>> On Fri, Sep 17, 2010 at 9:46 AM,  <dherring_at_[hidden]> wrote:
> [snip]
>>> It doesn't satisfy my need for everything to be in-place (e.g. for seamless
>>> use with shared memory, memory pools, etc.).  [Note: we don't actually use
>>> std::string; it was just convenient for the example.]
>>
>> How is it not in-place?
...
> Maybe Daniel doesn't want to pay for the extra memory
> required by the which.  At least that's the only reason
> I can think of :(

See
http://www.boost.org/doc/libs/1_44_0/doc/html/variant/design.html

In particular, "Temporary Heap Backup" and "Future Direction".

We have some specialized requirements.  We couldn't even use 
boost::shared_ptr until it added both the custom allocator and deleter. 
The "never-empty guarantee" conflicts with our needs and is not a concern 
at this time.

As a side note, we also must expose both the type of the "which" and the 
discriminant to member mapping (which may be N:1; see the CORBA IDL spec). 
So I believe boost::variant would still be hard to use even if the heap 
issue were resolved.

Later,
Daniel