Re: [boost] [config] [random] usage of BOOST_NO_MEMBER_TEMPLATE_FRIENDS

Subject: Re: [boost] [config] [random] usage of BOOST_NO_MEMBER_TEMPLATE_FRIENDS
From: John Maddock (john_at_[hidden])
Date: 2009-02-07 05:04:10

> 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_in_namespace.ipp

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.