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:
> 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
> // 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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk