Thanks for your response. I've sidestepped the issue by implementing a workaround. Thus, I'm not desperate to get this working (or upgrade the compiler). However, I've confirmed that this behavior is still present in boost 1.42.0 so perhaps it should be filed as a bug... or at least, docs should warn about 3.4.6 incompatibilities.
AMDG
marty wrote:
Thanks for your input. Unfortunately; no dice. It still doesn't compile (below), and the error(also below) provides little insight in my relatively inexperienced assessment. I have a feeling that the enable_if mechanism is not behaving properly on my particular system.
It isn't the enable_if per se that is causing the problem. is_match_condition doesn't seem to work properly.
(the fact that others have successfully compiled this implies that the boost::function must have the correct signature to satisfy the enable_if....)
----error
/usr/local/include/boost/asio/read_until.hpp:60: error: enumerator value for `value' not integer constant ../src/temp.cpp: In constructor `MyClass::MyClass()':
The compiler doesn't seem to like the implementation of has_result_type here.
I'm following up my original post with some actual code an interested person might try to compile, as well as the specific errors I'm getting. boost 1.41.0, gcc 3.4.6
Can you use a more recent compiler?
It also /might/ work if you replace has_result_type with BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) and add #include
. In Christ, Steven Watanabe