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 13:10:14

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

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.

The container_one_of_maybe doesn't have a "never empty"
guarantee.  Instead, it allows the container to have
an uninitialized state indicated by which() returning
a special value.  Also, the type of which() can be
user specified which may satisfy your requirement to:

  expose the type of the "which"

This user specification is done by specializing:

    template
    < typename Index //2nd arg to composite_storage template
                     //e.g. mpl::integral_c<int,Index0>
                     //where Index0 is index of 1s element
                     //of the components.
    >
  struct enum_base
  {
          typedef
        //type of discriminant.  For example, int or char.
        //Usually some function of Index.
      type
      ;
  };

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

A search for "discrimin" on that page found:

  discriminated union type consistingof a discriminator followed
  by an instance of a type appropriate to thediscriminator value

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:

  http://article.gmane.org/gmane.comp.parsers.spirit.general/19226

explains the reason for the change.  It also shows the location
of the non-variadic template version of the code.
If you really need the order reversed, it could be changed back
without much trouble.  I guess it could be made a policy for
one_of_maybe; however, that would mean another template
parameter :(

Hope that was clear enough ;)
Please let me know if not.

-regards,
Larry