Re: [boost] Problems with proto and /clr

Subject: Re: [boost] Problems with proto and /clr
From: Eric Niebler (eric_at_[hidden])
Date: 2011-10-11 14:44:04

On 10/11/2011 4:40 AM, Jorge Lodos Vigil wrote:
> Hi
> In boost 1.47 proto stopped compiling with /clr in VS2008 and VS2010. Take the calc3 example, for instance.
> 
> The root problem is that /clr is instantiating templates that normally are not.
> The change in proto is the new is_applyable metafunction. In normal compilation, when the received parameter is not callable mpl::and_ ensures that there is no need to fully instantiate the is_transform metafunction parameter. Apparently when using /clr it gets instantiated any way.
> You may verify this commenting out the 3 BOOST_MPL_ASSERT_RELATION lines in calc3 sample (so it will compile)  and adding the following in the main function:
> 
> // This is an instantiation of is_applyable that causes problems
> typedef boost::mpl::max<CalculatorGrammar,boost::proto::_state> is_applyable_parameter_t;
> 
> // This is why it normally compiles
> BOOST_MPL_ASSERT_NOT((boost::proto::is_callable<is_applyable_parameter_t>));
> 
> // The following correctly fails to compile, the is_transform metafunction must never be instantiated
> //bool is_tranform = boost::proto::is_transform<is_applyable_parameter_t>::value;
> 
> // This is the line that does not compile with /clr but normally does
> typedef mpl::and_<mpl::false_, boost::proto::is_transform<is_applyable_parameter_t> > problem_t;

This is a Proto bug, but I don't know why it is only triggered with
/clr. Thanks for the detailed analysis.

> This code fails to compile with /clr, because is_applyable_parameter_t is instantiated and CalculatorGrammar is not comparable.
> 
> Before I continue to dig in proto code, try workarounds and create tickets, I thought I might ask these questions here:
> 1. In case a workaround can be found (decomposing is_applyable in 2 metafunctions, for instance) is it of interest to support /clr?
> 2. Is this situation a compiler bug, a proto bug or just bad luck + undefined behavior?
> 
> I'll appreciate any comment you may have on this. Please note that this causes xpressive and probably spirit to fail compilation with /clr.
> 
> On a side note note, if there is interest to support /clr, it should not be a problem to modify MSVC test scripts. Only the /clr parameter must be added to the command line, nothing else. Apparently there is no big demand for C++ with /clr, but if there is interest I could try to modify tests scripts and correct any problem that may surface.
> Thank you in advance for your time.

This is now fixed on trunk in changeset 74919.

https://svn.boost.org/trac/boost/changeset/74919

I hope to get this merged to the release branch ASAP so this can be in
the next release.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com