Boost logo

Boost :

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 (

> 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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at