Hi,
I recently run into an ICE by compiling phoenix3 with gcc-4.2. It seems this
particular can not handle proto::detail::poly_function_traits properly.
the problem is the default Switch template initialization ... by replacing
std::size_t Switch = sizeof(test_poly_functionFun(0,0)) by typename
Hi,
I just wanted you to know that phoenix3 is in a working state once again.
I refactored everything with the changes we discussed ...
All tests from boost.bind are passing!
Placeholder unification is in place!
Now ... up to documentation writing and checking for BLL compatibility ...
Regards,
Congrats! Keep us posted once the documentation is online. I'd be glad to
write some samples and maybe publish a few blog posts about it :)
On Thu, Dec 23, 2010 at 1:57 PM, Thomas Heller
thom.hel...@googlemail.comwrote:
Hi,
I just wanted you to know that phoenix3 is in a working state once
nice xmas present :D
can't wait for the doc ;D
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Yeah, nice Thomas (and of course the other people behind it )) )
(just for xmas, gee, that's cool :p)
On 23 December 2010 13:03, Joel Falcou joel.fal...@lri.fr wrote:
nice xmas present :D
can't wait for the doc ;D
___
proto mailing list
On 12/23/2010 7:57 AM, Thomas Heller wrote:
I just wanted you to know that phoenix3 is in a working state once
again.
Woo!
I refactored everything with the changes we discussed ...
All tests from boost.bind are passing!
Woo!
Placeholder unification is in place!
Woo!
Now ... up to
On 12/23/2010 9:42 PM, Hartmut Kaiser wrote:
I have a fairly large program that compiled just fine on boost_trunk
version 67416, but is now broken. I traced to problem to an
ambiguous operator overload that occurs when both qi.hpp and
fusion/tuple.hpp are included.
The following code does
