Re: [proto] invalid use of incomplete type 'detail::uncvref<...>'
Eric, that was great explanation. Now, everything makes sense. Thanks. :) --- On Mon, 28/2/11, Eric Niebler wrote: > From: Eric Niebler > Subject: Re: [proto] invalid use of incomplete type 'detail::uncvref<...>' > To: proto@lists.boost.org > Date: Monday, 28 February, 2011, 20:26 > On 3/1/2011 3:15 AM, Hossein Haeri > wrote: > > Hi Eric, > > > >> boost/proto/matches.hpp:391:13: error: invalid use > of incomplete > >> type 'struct > >> > boost::proto::detail::uncvref > >> mpl_::integral_c > >::type' > Now look at how you've defined > >> CanBeCalled: > >> > >> template struct > CanBeCalled; > > > > Thanks. I added another specialisation for > mpl::integral_c > > > and it worked. But, now I'm wondering why on earth was > that basically > > needed? I had never touched mpl::integral_c in my code > snippet. That > > should have been generated by Proto then, right? > > No. > > > And, in that case, > > may I please know why? > > Somewhere in your code you're adding two MPL integers. > That's just how > MPL works. Your code is assuming a particular type of > Integral Constant > (mpl::int_). MPL only promises to give you /a/ MPL Integral > Constant. > > > On the other hand, I'm wondering why GCC never nagged > about the need > > for mpl::integral_c when I wrote: > > > > EW1() >> > Plus1(); > > > > In other words, why is mpl::int_ used for the > above line (when n > > == 1), whereas mpl::integral_c is used > for the following one > > (when n == 2)? > > > > (EW1() || > EW1 > AmmoMsg>()) >> Plus2(); > > Probably because the former isn't doing an addition of MPL > Integral > Constants. > > This is an MPL "gotcha". Others have complained about it on > the boost > list, IIRC. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com > ___ > proto mailing list > proto@lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/proto > ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] invalid use of incomplete type 'detail::uncvref<...>'
On 3/1/2011 3:15 AM, Hossein Haeri wrote: > Hi Eric, > >> boost/proto/matches.hpp:391:13: error: invalid use of incomplete >> type 'struct >> boost::proto::detail::uncvref> mpl_::integral_c > >::type' Now look at how you've defined >> CanBeCalled: >> >> template struct CanBeCalled; > > Thanks. I added another specialisation for mpl::integral_c > > and it worked. But, now I'm wondering why on earth was that basically > needed? I had never touched mpl::integral_c in my code snippet. That > should have been generated by Proto then, right? No. > And, in that case, > may I please know why? Somewhere in your code you're adding two MPL integers. That's just how MPL works. Your code is assuming a particular type of Integral Constant (mpl::int_). MPL only promises to give you /a/ MPL Integral Constant. > On the other hand, I'm wondering why GCC never nagged about the need > for mpl::integral_c when I wrote: > > EW1() >> Plus1(); > > In other words, why is mpl::int_ used for the above line (when n > == 1), whereas mpl::integral_c is used for the following one > (when n == 2)? > > (EW1() || EW1 AmmoMsg>()) >> Plus2(); Probably because the former isn't doing an addition of MPL Integral Constants. This is an MPL "gotcha". Others have complained about it on the boost list, IIRC. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] invalid use of incomplete type 'detail::uncvref<...>'
Hi Eric, > boost/proto/matches.hpp:391:13: error: invalid use of incomplete type > 'struct boost::proto::detail::uncvref mpl_::integral_c > >::type' > Now look at how you've defined CanBeCalled: > > template > struct CanBeCalled; Thanks. I added another specialisation for mpl::integral_c > and it worked. But, now I'm wondering why on earth was that basically needed? I had never touched mpl::integral_c in my code snippet. That should have been generated by Proto then, right? And, in that case, may I please know why? On the other hand, I'm wondering why GCC never nagged about the need for mpl::integral_c when I wrote: EW1() >> Plus1(); In other words, why is mpl::int_ used for the above line (when n == 1), whereas mpl::integral_c is used for the following one (when n == 2)? (EW1() || EW1()) >> Plus2(); TIA, --Hossein ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] invalid use of incomplete type 'detail::uncvref<...>'
On 2/22/2011 1:45 AM, Hossein Haeri wrote: > EW1() >> &plus1; > EW1() >> Plus1(); > > (EW1() || EW1()) >> > Plus2();//*** > (EW1() || EW1()) >> > &plus2; > > When I compile the *** line, I get a giant spew attached in a file called > Err.txt. For those kind fellows on the list who'd like to see the actual code > as well, a *very small* zip file is attached to this posting. (The zip file > contains 2 .cpp's as well 5 .hpp's which simply need to be built altogether > in a single directory.) > > Anyone having any ideas please? You need to look more closely at the error messages you get. The actual error is: boost/proto/matches.hpp:391:13: error: invalid use of incomplete type 'struct boost::proto::detail::uncvref > >::type' Now look at how you've defined CanBeCalled: template struct CanBeCalled; #define CAN_BE_CALLED(z, n, unused)\ template\ struct CanBeCalledImpl > ... Can you see the problem yet? Hint: mpl::int_ != mpl::integral_c. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] invalid use of incomplete type 'detail::uncvref<...>'
Just to update you folks: The issue is still around in the just-released Boost 1.46 too... :( --- On Mon, 21/2/11, Hossein Haeri wrote: > From: Hossein Haeri > Subject: [proto] invalid use of incomplete type 'detail::uncvref<...>' > To: "Proto Mailing List" > Date: Monday, 21 February, 2011, 18:45 > Dear all, > > [GCC 4.5.1, MinGW32, WinXPSP3, Boost 1.42] > > I have an application in which the following two pieces of > syntax come handy (where F and G are templatised function > objects): > > 1) _1 >> F<...>() >> G<...>() -- to > be equivalent with F(G(x)) when called with _1 == x. > > 2) (_1 || _2) >> F<...>() -- to be equivalent > with F(x, y) when called with _1 == x and _2 == y. > > The same syntax for F and G above needs also to work for > ordinary functions. > > I used Proto to give my F's and G's the above desired > compositional syntax. And, it actually works quite well with > ordinary functions but becomes quite hairy for certain > function objects. For example, I have the following > test-cases where everyone behaves themselves except the line > marked with ***: > > EW1() >> > &plus1; > EW1() >> Plus1(); > > (EW1() || > EW1()) >> > Plus2();//*** > (EW1() || > EW1()) >> > &plus2; > > When I compile the *** line, I get a giant spew attached in > a file called Err.txt. For those kind fellows on the list > who'd like to see the actual code as well, a *very small* > zip file is attached to this posting. (The zip file contains > 2 .cpp's as well 5 .hpp's which simply need to be built > altogether in a single directory.) > > Anyone having any ideas please? > > TIA, > --Hossein > > > > -Inline Attachment Follows- > > ___ > proto mailing list > proto@lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/proto > ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
