$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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