18 Dec
2012
18 Dec
'12
10:28 p.m.
I've run into an unexpected behaviour, and I'm not sure if the compiler has a bug, if Boost.MPL has a bug, or if I have the wrong expectations. I am using Boost v1.49.0, but I also tested r82084 of the Boost trunk.
I'm not sure which is the case either, but notice that a simple
workaround is to define f after traitor_1 is complete (you can still
*declare* f where you do now). This is not an unreasonable
requirement, because the body of f performs a traitor_1 -> C
conversion, for which it needs to instantiate the constructor of C,
for which it needs to instantiate has_traitor