I am showing this gcc3 bug just in case any other Boost developer has run into it and knows some easy workaround. It will save me some time as the workaround in the actual case, which is more complicated, is very laborious as I envision it ( I have not yet attempted to code up the laborious workaround ). I ran into this type of case as the problem in my tti library which is keeping it from supporting gcc3+. Here is the simplified code, called TestGcc3.cpp. I have removed all Boost dependencies to make it as simple as possible to see: "template<class T> struct eval; template < template<class> class F, class P1

struct eval<F<P1> > : F<typename P1::type>{}; template < template<class,class> class F, class P1, class P2

struct eval<F<P1,P2> > : F<typename P1::type,typename P2::type>{}; struct noparam { typedef noparam type; }; template < class T, class P = noparam

struct ptmf { typedef int type; }; template < class T, class P = noparam

struct tkf : eval<ptmf<T,P> >{}; template <class T> struct ATemplate { typedef T type; }; int main() { tkf<ATemplate<int> > aVar; return 0; }" The compiler command line, which is essentially what bjam generates, is: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c "TestGcc3.cpp" The error message is: "TestGcc3.cpp: In instantiation of `tkf<ATemplate<int>, noparam>': TestGcc3.cpp:52: instantiated from here TestGcc3.cpp:42: error: ambiguous class template instantiation for `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:19: error: candidates are: struct eval<F<P1, P2> > TestGcc3.cpp:10: error: struct eval<F<P1> > TestGcc3.cpp:42: error: invalid use of undefined type `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp:2: error: declaration of `struct eval<ptmf<ATemplate<int>, noparam> >' TestGcc3.cpp: In function `int main()': TestGcc3.cpp:52: warning: unused variable 'aVar'" I am looking for a workaround for gcc3+ compilers which does not involve getting rid of the default parameters. If I remove the default parameters, and change the instantiation of tkf to: tkf<ATemplate<int>,ATemplate<int> > aVar; the compile is successful and there is no error. This is of course a very simplified illustration of much more complicated code and maintaining default parameters within the more complicated situation is a much cleaner syntax than an alternative, even if I can get an alternative to work correctly without default parameters.