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 14:56:41

On Mon, 20 Sep 2010, Larry Evans wrote:
> On 09/20/10 10:50, dherring_at_[hidden] wrote:
>> 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.
>
> An alternative to boost::variant is the:
>
>  http://svn.boost.org/svn/boost/sandbox/variadic_templates
>    /boost/composite_storage/pack/container_one_of_maybe.hpp
>
> which *might* work for you.  I say *might* because I don't
> know exactly what you mean by:
>
>  "never-empty guarantee" conflicts with our needs
>
> because those needs are not spelled out.

Rephrase:  We don't need the never-empty guarantee; but it conflicts with 
the always-in-place requirement.  Steven's suggestion to add boost::blank 
looks promising.  The documentation should be updated to mention it.

This container looks interesting; but other than the sources, I don't see 
any documentation?

For now, we'll stick with what I've cobbled together.

>> 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.
>
> I'm also unsure of what's meant by:
>
>    the discriminant to member mapping (which may be N:1).
>
> If you mean types could be duplicated, IOW, allow:
>
>  variant<int,int>
>
> then that's what one_of_maybe does.
>
> The one place I found for corba spec (found with google "corba idl
> spec") was here:
>
>  http://www.objs.com/x3h7/corbaidl.htm

If you're interested, see also Part 1, section 7.11.2.2 of
http://www.omg.org/spec/CORBA/3.1/
and the C++ mapping on
http://www.omg.org/technology/documents/idl2x_spec_catalog.htm

We support a slight variant of this spec.

> This layout (discriminant followed by dependent value) is the
> exact reverse of the container_one_of_maybe is laid out.
> Originally, the discrimiant was 1st; however, the following
> post:

That order doesn't bother me too much.  The "N:1" notation meant that, 
just like a "switch statement", there may be N cases that specify one 
member.  It is also possible for multiple members to have the same type.

For example, here's an IDL snippet.  It shows the discriminant is a 
"long"; both default and 2 specify member y.

union U switch(long)
{
     case 0:
         long x;
     default:
     case 2:
         char y[10];
     case 3:
         float z;
};

Later,
Daniel