Re: [Boost-users] large variant performance compared (50 elements)

Subject: Re: [Boost-users] large variant performance compared (50 elements)
From: Larry Evans (cppljevans_at_[hidden])
Date: 2011-01-28 06:09:36

On 01/27/11 13:26, Paul wrote:
>> [snip]
>> The two attached files get me closer to a compilation.
>> Two significant changes to the originals:
>>
>>    1) in assign_variant(,true), I had to disable the BOOST_STATIC_ASSERT
>>       because if was always causing a compiler error.
>>
> 
> This might also indicate your are trying to assign a type to the variant
> that is not one of the bounded types. See your callstack.

After changing the code to:

       BOOST_MPL_ASSERT((boost::mpl::false_)); //Compiler error here
indicates that (one of) the variants bounded types is no

to allow the compilation to proceed a little further, the g++ compiler
just prints:

CLoPtrVariant.hpp: In member function 'void
Layout::CConvertVariant<Typelist>::assign_variant(boost::shared_ptr<Type>&,
mpl_::true_)':
CLoPtrVariant.hpp:315:7: error: no matching function for call to
'assertion_failed(mpl_::failed************
mpl_::bool_<false>::************&)'

So, there's no callstack available.

BTW, if the BOOST_STATIC_ASSERT (or in the above modification, the
BOOST_MPL_ASSERT) always fails, as it always must since it is passed
the compile time constant, boost::mpl::false_, then the following
assignment statement:

        m_rVariant = rValue;

can never execute; so, why is it there?  OTOH, why bother with
assign_variant at all since the assert can take place in the
calling routine.

> 
>>    2) I had to forward declare:
>>
>>         CLoPtrVariant(const CLoPtrVariant<Typelist2>&  rOperand)
>>
>>       because the body used CConvertVariant which hadn't been declared
>>       yet.
>>
> 
> Odd, since its a template/argument-naming dependant function and the poi
> is way down it should give you no problems!? 

Does poi mean "point of instantiation"? If so, then I don't
see how that's relevant. AFAICT, the problem is that there's no
declaration of CConvertVariant before it's used and the g++ compiler,
understandably, issues the diagnostic.  Now if CConvertVariant were
declared after the CTOR, but *within* the CLoPtrVariant class,
then I think it would work; however, since CConvertVariant is
declared outside of CLoPtrCVariant, there's a problem.

Maybe visual c++ allows this freedom; however, I don't think
that is portable.