unordered_multimap::emplace() is not available for Solaris Studio C++ compiler

[Maxim Kartashev <maxim.kartashev@…>]

Trying to compile ./libs/unordered/test/unordered/unnecessary_copy_tests.cpp with Sun C++ 5.11 results in the following error:

".../boost_1_47_0libs/unordered/test/unordered/unnecessary_copy_tests.cpp", line 249: Error: Could not find a match for boost::unordered_map<unnecessary_copy_tests::count_copies, unnecessary_copy_tests::count_copies, boost::hash<unnecessary_copy_tests::count_copies>, std::equal_to<unnecessary_copy_tests::count_copies>, std::allocator<std::pair<const unnecessary_copy_tests::count_copies, unnecessary_copy_tests::count_copies>>>::emplace<boost::unordered_map<unnecessary_copy_tests::count_copies, unnecessary_copy_tests::count_copies, boost::hash<unnecessary_copy_tests::count_copies>, std::equal_to<unnecessary_copy_tests::count_copies>, std::allocator<std::pair<const unnecessary_copy_tests::count_copies, unnecessary_copy_tests::count_copies>>>::Arg0>() needed in unnecessary_copy_tests::unnecessary_copy_emplace_map_test_type::run().

Investigation revealed that necessary emplace() method is indeed missing: it is placed under

#if !BOOST_WORKAROUND(SUNPRO_CC, BOOST_TESTED_AT(0x5100))

which effectively removes emplace() with default argument from Sun C++ compiler's sight.

The reason for this "workaround" is unclear as the test compiles successfully (with "workaround" removed, of course) even with 5.9 compiler. (It fails at run time, though, when compiled with stlport4, but passes with stdc++)

[Maxim Kartashev <maxim.kartashev@…>]

Fix for this ticket

[anonymous]

The workaround was required to be able to use the containers with incomplete types, which is far more useful functionality than the zero-argument emplace. It was a different test that picked up the failures.

Btw. there's going to be a new version in 1.48, so patches against older releases might not apply.

[Maxim Kartashev <maxim.kartashev@…>]

Is there a ticket ID for that change so that I can verify that my proposed patch does not break more than it fixes? Or maybe that test name is known?

[anonymous]

The change was in [58002]. I don't remember the details but it would have been made due to failures in the test results, rather than bug reports. A lot has changed since then so it might be possible that it doesn't apply any more, or only applies to older versions.

[Maxim Kartashev <maxim.kartashev@…>]

Well, in this case can we move forward with fixing this the way I proposed since it has visible benefit yet at the same time drawbacks are unclear?

[Daniel James]

At some point the workarounds were disabled for the latest versions of the compiler.