BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS should be defined for gcc 3.4.x

[Christopher Schmidt]

The attached piece of code fails to compile under gcc 3.4.2 (MinGW official). Output:

test.cpp:3:3: #error BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS not defined! test.cpp: In function `int main()': test.cpp:13: error: call of overloaded `F(const int&)' is ambiguous test.cpp:6: note: candidates are: void F(C&) [with int i = 0, C = const int] test.cpp:7: note: void F(const C&) [with int i = 0, C = int]

I think BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS should be defined for this compiler version. At the moment, Boost.Config just defines BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS for gcc 3.1.x and 3.2.x .

[Christopher Schmidt]

testcase

[John Maddock]

I'm not sure if that is *exactly* the use case that that macro was intended for - is there a specific use case within Boost that requires this? I'm asking because I'd rather not disable features (or whole libraries in the case of Boost.Units) for gcc-3.4 unless we really have to.

Thanks, John.

[Christopher Schmidt]

I need a macro that describes that defect for my work on Boost.Fusion. At the moment, this problem is workarounded by the general use of boost::lazy_disable_if (e.g. ​https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/sequence/intrinsic/at.hpp#L70). Of course I can still live with a general lazy_disable_if, but unfortunately this is not fast in terms of compile time and neither looks nor feels right.

[John Maddock]

The thing is if we change this, then it'll make Boost::Units unusable on cygwin (and maybe other libraries too).

Can you not use something like:

#if defined(BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS)

BOOST_WORKAROUND(GNUC, <4)

workaround here #else conforming code #endif

?

[Christopher Schmidt]

A hardcoded BOOST_WORKAROUND looks reasonable to me. I am fine with this.