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

Subject: Re: [boost] [type-traits] aligned_storage in unions
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-09-20 15:37:35

On 09/20/10 13:56, dherring_at_[hidden] wrote:
> 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.

I'm still unsure what "always-in-place" means.  Based on what Steven
was saying, I'm guessing it means only stack or static storage can
be used (i.e. no calls to new or malloc).  Is that right?
If so, then one_of_maybe satisfies that requirement.  However,
unlike boost::variant, it makes no provision for failure of
operator= when the source and target are different types; however,
that could be remedied by simply catching any throw and setting
which() to indicate the one_of_maybe was uninitialized.  Since
the uninitialized value ( of type nothing, defined here:

  http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost
    /composite_storage/special_components.hpp

) cannot throw during construction, it would workaround the operator=
problem.

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

Will work on that ;)

> 
> 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.
> 
[snip]

This is what I meant to imply by the example:

  variant<int,int>

With the current variant, this won't work; however, it's perfectly OK
with one_of_maybe.  One reason I wanted this was to emulate
the way lex works, which returns a discriminated union.  Most of
the types in the union are simply unused because one's not really
interested in the character string representation of some keyword,
instead, one is only interested in which keyword was found, and that's
encoded in the discriminant.  One_of_maybe has another special
type for this very purpose.  It takes up no room (there's
a specialization of size_of template which returns 0 for
this special type); hence, it doesn't contribute to the calculation
of the size of one_of_maybe.

> Later,
> Daniel

Regards,
Larry