Re: [boost] [variant] awkward recursion

Subject: Re: [boost] [variant] awkward recursion
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2012-11-03 04:19:40

2012/11/2 Dave Abrahams <dave_at_[hidden]>:
>
> on Fri Nov 02 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
>
>> On 01/11/12 14:37, Dave Abrahams wrote:
>>
>>> As far as I can tell, putting sizeof() inside a layer of template
>>> instantiation doesn't solve anything.  But maybe I'm missing something.
>>
>> The idea would be that the user of variant<T0, T1, ..., Tn> would be
>> able to provide incomplete types Ti if size_forward<Ti> is
>> specialized.

Yes, that is what I mean.

> I suppose one could arrange for a later compilation error should the
> size turn out to be wrong.

Yes, BOOST_STATIC_ASSERT((size_forward<Ti>::value == sizeof(Ti)));
must be put somevere in the code.

But, sizeof() for incomplete types is not the only problem. It looks
like we would also need has_nothrow_constructor_forward<Ti> (and may
be some more "_forward" versions of meta functions), because
Boost.Variant uses some heuristics to detect fallback_type and dynamic
allocation requirements.

Here is a small example:

struct some_pod_t;

template <> struct size_forward<some_pod_t> {enum ENU {value = 1}; };

struct some_nonpod_type {
  some_nonpod_type();
  some_nonpod_type(const some_nonpod_type&){}
  some_nonpod_type& operator=(const some_nonpod_type&){}
};

// Will not detect fallback type or will be a compilation failure in
has_nothrow_constructor<some_pod_t>
boost::variant<some_nonpod_type, some_pod_t> v;

// If there was no compilation error...

struct some_pod_t {};

// Will detect some_pod_t as fallback type
boost::variant<some_nonpod_type, some_pod_t> v2;
...
v = v2; // Strange things may happen

--
Best regards,
Antony Polukhin