[proto][1.43] Problem with proto::matches
Hi Eric, I went into the following error with a grammar using terminals of T[N] (terminal<int[2]> in the example, gcc 4.5.0, boost 1.43): /usr/local/include/boost/proto/matches.hpp:1026:13: error: ambiguous class template instantiation for struct boost::proto::detail::lambda_matches<int [2], boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:119:13: error: candidates are: struct boost::proto::detail::lambda_matches<T, boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:129:13: error: struct boost::proto::detail::lambda_matches<T [M], U, -0x00000000000000001l> Adding the following specialization in matches.hpp solves it: template<typename T, std::size_t M> struct lambda_matches<T[M], proto::_ BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(-1)> : mpl::true_ {}; Best regards, Antoine
On 8/4/2010 4:44 PM, Antoine de Maricourt wrote:
Hi Eric,
I went into the following error with a grammar using terminals of T[N] (terminal<int[2]> in the example, gcc 4.5.0, boost 1.43): <snip>
Thanks for the report. I'll look into it. It'd make things easier if you could send a complete test case so I can test over here. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 8/4/2010 4:44 PM, Antoine de Maricourt wrote:
Hi Eric,
I went into the following error with a grammar using terminals of T[N] (terminal<int[2]> in the example, gcc 4.5.0, boost 1.43):
/usr/local/include/boost/proto/matches.hpp:1026:13: error: ambiguous class template instantiation for struct boost::proto::detail::lambda_matches<int [2], boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:119:13: error: candidates are: struct boost::proto::detail::lambda_matches<T, boost::proto::wildcardns_::_, -0x00000000000000001l> /usr/local/include/boost/proto/matches.hpp:129:13: error: struct boost::proto::detail::lambda_matches<T [M], U, -0x00000000000000001l>
Adding the following specialization in matches.hpp solves it:
template<typename T, std::size_t M> struct lambda_matches<T[M], proto::_ BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(-1)> : mpl::true_ {};
I can't reproduce this error. The following program compiles just fine for me on gcc 4.5: #include <boost/proto/proto.hpp> int main() { BOOST_MPL_ASSERT(( boost::proto::matches< boost::proto::terminal<int[2]>::type , boost::proto::_ > )); } Can you please send a program I can use to reproduce the error? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Le 07/08/2010 00:00, Eric Niebler a écrit :
Can you please send a program I can use to reproduce the error?
The most simple form I came to is below: #include <boost/proto/proto.hpp> namespace bp = boost::proto; template <typename A> struct B : bp::terminal<A>::type { }; int main() { BOOST_MPL_ASSERT(( bp::matches< bp::terminal< B<int[2]> >::type, bp::terminal< B<bp::_> > > )); } Best regards, Antoine
On 8/7/2010 9:52 AM, Antoine de Maricourt wrote:
Le 07/08/2010 00:00, Eric Niebler a écrit :
Can you please send a program I can use to reproduce the error?
The most simple form I came to is below:
#include <boost/proto/proto.hpp>
namespace bp = boost::proto;
template <typename A> struct B : bp::terminal<A>::type { };
int main() { BOOST_MPL_ASSERT(( bp::matches< bp::terminal< B<int[2]> >::type, bp::terminal< B<bp::_>
)); }
First, let me say that what you're doing here is a little unusual. You're creating a proto terminal that contains ... a proto terminal. Which is fine; a proto terminal is an object like any other and can be put inside another proto terminal, but you should know that Proto will treat anything inside a proto terminal a just a blob; it will not try to do any further matching or introspection on it. That said, this code should work. I've simplified a bit: #include <boost/proto/proto.hpp> namespace bp = boost::proto; template<typename A> struct B {}; int main() { BOOST_MPL_ASSERT(( bp::matches< bp::terminal< B<int[2]> >::type , bp::terminal< B<bp::_> > > )); } B doesn't inherit from proto::terminal anymore; the problem is the same. It's as you described and your patch is correct. Thanks. I just committed a fix to trunk. It won't be in the upcoming 1.44, but it'll be in 1.45. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (2)
-
Antoine de Maricourt -
Eric Niebler