Joel de Guzman wrote:
Not an ideal fix, but illustrates where the change for our compiler is necessary in the Boost source. The changes would need to be made in fusion/adapter/std_pair.hpp, fusion/sequence/generation/make_vector.hpp, fusion/sequence/generation/make_list.hpp to name a few :-(
Quite a lot. Fusion relies on it for, e.g. enable_if specialized classes. I'm curious though why all fusion::tuple tests run ok while the fusion::vector tests fail. The former is built using the latter (http://beta.boost.org/development/tests/trunk/developer/fusion.html)
So there is a source work around as well as a compiler fix. Like I mentioned earlier it will be some time before the compiler change is reflected into a production compiler. One of our internal requirements that we have for publishing results is that the compiler used to publish results has to be available to customers therefore I cannot use a pre-release compiler for nightly Boost runs.
How would you like to proceed?
I'd be willing to put in workarounds (ifdefs). Alas, I do not have access to this compiler. I'd appreciate help from you or someone else.
Since I've been the one pushing you fix this... I don't mind spending some time on this, but I don't have access to this platform/compiler either. Even if we could just get the TR1 tuples working that would be a big start. John.