Re: [boost] [variant] awkward recursion

Subject: Re: [boost] [variant] awkward recursion
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-11-01 09:37:45

on Wed Oct 31 2012, Antony Polukhin <antoshkka-AT-gmail.com> wrote:

> 2012/10/31 Dave Abrahams <dave_at_[hidden]>
>>
>>
>> on Wed Oct 31 2012, "Peter Dimov" <lists-AT-pdimov.com> wrote:
>>
>> > Steven Watanabe wrote:
>
>> >> I believe that I've seen tickets in trac indicating
>> >> that at least one STL implementation checks that
>> >> the element type is complete, so we can't even
>> >> assume that it works in practice.
>> >
>> > The variant could perhaps define some dummy complete type X and
>> > allocate space for vector<X>, betting on the fact that vector<Y> would
>> > have the same size. And if it doesn't, well, the heap is it then.
>>
>> Yeah, I thought of that.  Very interesting problem space in the end.
>> I'm slightly tempted to think about a rewrite.
>>
>
> May be it would be better to write a metafunction:
>
> template <class T> size_forward {
>     enum ENUM{value = sizeof(T)};
> };
>
> User is free to specialize it, so Boost.Variant can use it to get
> sizes of types (instead of directly calling to sizeof(T))
>
> Specialization for your case will be:
>
> template <> struct size_forward<vector<Y>> {
> enum ENUM{value = sizeof(vector<X>)};
> };
>
> I think that such metafunction could be widely used (for example in
> Boost.Optional)

As far as I can tell, putting sizeof() inside a layer of template
instantiation doesn't solve anything.  But maybe I'm missing something.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost