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@ll.mit.edu> 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