Boost.Random uses BOOST_NO_MEMBER_TEMPLATE_FRIENDS to decide whether it is safe to define the stream operators.

#if !defined(BOOST_NO_OPERATORS_IN_NAMESPACE) && !defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) template<class CharT, class Traits> friend std::basic_ostream<CharT,Traits>& operator<<(std::basic_ostream<CharT,Traits>& os, const uniform_int& ud);

template<class CharT, class Traits> friend std::basic_istream<CharT,Traits>& operator>>(std::basic_istream<CharT,Traits>& is, uniform_int& ud); #endif

However, the documentation of BOOST_NO_MEMBER_TEMPLATE_FRIENDS says that BOOST_NO_MEMBER_TEMPLATE_FRIENDS is defined if the compiler doesn't support template<class P> friend class frd;

It seems from https://svn.boost.org/trac/boost/ticket/1068 that these do not correspond exactly.

I think that's correct.

Are there any compilers that we still care about, that don't support this use of friend?

It looks like VC++ and codegear compilers are the only current compilers we define this for, so maybe it would be easier to just add a specific exception for VC++ : #if !defined(BOOST_NO_OPERATORS_IN_NAMESPACE) && !(defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) && !BOOST_WORKAROUND(BOOST_MSVC, >= 1310))

Also, it sounds to me like the use of BOOST_NO_OPERATORS_IN_NAMESPACE is wrong because it is documented as "Compiler requires inherited operator friend functions to be defined at namespace scope" and there is no inheritance here. Is this right?

Ultimately, it's always best to refer to the test cases for these, in the case of BOOST_NO_OPERATORS_IN_NAMESPACE it's quite specific to an issue that the operators library had with operator overload resolution: https://svn.boost.org/trac/boost/browser/trunk/libs/config/test/boost_no_ops... So yes it's probably being misused, but I suspect it was added to to fix a specific issue, and since no current compilers define that macro, I think we might as well leave it alone for now? John.