Re: [boost] [fusion][IBM xlc] TR1 tests and others failing.

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-26 19:06:33

Christopher Cambly wrote:

> The problem with boost::fusion:traits::tag_of<>, and make_vector<> is that
> we are not considering default arguments for partial specializations.  The
> code sequence is a forward declaration using default arguments followed by
> a partial specialization definition.
> 
> Our compiler explicitly disallowed the checking of default arguments for
> partial specilizations. Most likely this was just an oversight on our part,
> but I will need to clarify with the standard.
> 
> Here is a small test-case that causes the error message as well show the
> problem:
> 
> //Begin t.C
> template <typename T0 = void, typename T1 = void> struct make_vector;
> template <typename T0> struct make_vector<T0> { };
> //End t.C

Does it only happen if make_vector is forward declared?

> The workaround in the Boost source code would be to specify the default
> argument explicitly.  I tried the following change for
> boost/fusion/adapter/std_pair.hpp and the error message disappeared.
> 
> --- boost/fusion/adapted/std_pair.hpp.orig      2007-10-26
> 11:31:11.276781194 -0400
> +++ boost/fusion/adapted/std_pair.hpp     2007-10-26 11:31:32.676781424
> -0400
> @@ -20,7 +20,7 @@
>      namespace traits
>      {
>          template <typename T1, typename T2>
> -        struct tag_of<std::pair<T1, T2> >
> +        struct tag_of<std::pair<T1, T2>, void >
>          {
>              typedef struct_tag type;
>          }
> 
> 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.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net