Hello, We are having trouble with boost::unit_test::test_case_filter while using boost 1.37 on Solaris 10 (x86) with Sun's own C++ compiler (5.9). We're using Sun's own STL implementation, *not* stlport. $ CC -V CC: Sun C++ 5.9 SunOS_i386 Patch 124864-09 2008/12/16 The problem occurs in the constructor of test_case_filter, specifically at this line: ------- m_filters.push_back( std::vector( string_token_iterator( *tit, (dropped_delimeters = ",", kept_delimeters = dt_none) ), string_token_iterator() ) ); ------- Here is the compiler's complaint: ------- "[...]boost-1.37.0/include/boost/test/impl/unit_test_main.ipp", line 116: Error: Could not find a match for std::vectorboost::unit_test::test_case_filter::single_filter::vector(boost::unit_test::basic_string_token_iterator, boost::unit_test::basic_string_token_iterator) needed in boost::unit_test::test_case_filter::test_case_filter(boost::unit_test::basic_cstring<const char>). "[...]boost-1.37.0/include/boost/test/impl/unit_test_main.ipp", line 116: Error: Formal argument x of type const std::vectorboost::unit_test::test_case_filter::single_filter& in call to std::vectorboost::unit_test::test_case_filter::single_filter >::push_back(const std::vectorboost::unit_test::test_case_filter::single_filter&) is being passed int. ------- It would appear that, even though Sun's definition of std::vector does include a (template) constructor that takes two iterators (see /opt/sunstudio12/SUNWspro/prod/include/CC/Cstd/vector), the compiler is unable to match the boost code to this constructor. In fact, it seems unable to infer a match for this constructor even with some simple test code: ------- std::list<int> l; std::vector<int> v(l.begin(), l.end()); ------- ...which results in this error: ------- Error: Could not find a match for std::vector<int>::vector(std::list<int>::iterator, std::list<int>::iterator) ------- Apologies for the length of this post so far. I have two ensuing questions: 1. Is using Sun's C++ compiler and STL implementation with boost a bad idea? (unfortunately, due to other library dependencies, we cannot use gcc and/or stlport) 2. If we provide some workaround code for this particular problem, is it likely that it would be accepted as an addition to boost? Naturally we don't want to maintain our own local boost patches, so if our workaround would be accepted then it would hopefully benefit others as well as saving us from having to maintain local patches. many thanks in advance for any responses, David Graham Senior Software Engineer CR2 Ltd - http://www.cr2.com/ CR2