If anyone can suggest a workaround for these compiler bugs, I am happy to implement them. I have tried to understand what the macro generates and maybe we can fix it by using fusion/mpl instead of partial template specialization. I don't fully understand the macro, but maybe i am not too far off, so that my solution might still work.
the need for partial template spcialization arised because basically the type/member list (A1, a1)(A2,a2)... is translated into
typedef A1 t1_type; typedef A2 t2_type; ... t1_type& t1;//linked to a1 t2_type& t2;//linked to a2 ...
or something very similar to it.
thus you need to specialize deref to do something roughly like( i simplyfy here because i am too lazy to look up the original solution):
template<int> struct deref{}; template<> struct deref<1>{ typedef t1_type& type; type call(Sequence& seq){ return seq.t1; } }; ...
now think about the following: typedef boost::fusion::vector
t_seq; t_seq t;//tied to a1...an template<int N> struct deref{ typedef result_of::at_c type; type call(Sequence& seq){ return at_c<N>(seq.t); } }; could this work? Of course this is detrimental to the compil times since fusion::vector needs to be itnroduced and instantiated. However this might just be the solution used for GCC<4.5 and MSVC, in this cas "slow" is better than "compiler gives up".
Nice idea! I think that would work. Could you please file a Trac ticket for this with your example code? I will post a patch there once I've implemented the workaround. Regards, Nate