Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-11 16:55:55


From: "Jonathan Turkanis" <technews_at_[hidden]>
> Rob Stewart wrote:
> > From: "Jonathan Turkanis" <technews_at_[hidden]>
>
> >> I don't want to get distracted by the issue of whether the fact that
> >> an operator is defined in a friend declaration can be considered an
> >> implementation detail. My real question whether I can document the
> >> basic_character interface, broadly conceived, as simpler than it
> >> really is, and add a note explaining what's missing. I don't want a
> >> simple library element to require a huge section of documentation.
> >
> > I'm not sure you got my point. I don't think you can avoid
> > documenting the full interface of basic_character, including the
> > namespace scope operators.
>
> But if they're defined as friends, there not technically namespace scope
> operators. I guess I can define them at namespace scope just to avoid this
> problem.

If they are friends defined in a class template, they are, by
definition, namespace scope functions. It just happens that they
aren't declared/defined until the template is specialized. The
fact that you use that implementation technique to make the T
specialization of an operator a friend of basic_character<T>
doesn't change the nature of the operators.

The fact that they are friends is merely an implementation detail
that permits their being defined within the class definition in
the first place.

Let me put it another way:

namespace boost { namespace iostreams {
   inline template <typename Ch>
   bool operator ==(basic_character<Ch> lhs, Ch rhs)
   {
      return lhs.value() == rhs;
   }
} }

That operator works just fine. It doesn't need to be a friend.
It doesn't have to be implemented within the class definition, so
it doesn't need to be part of the class synopsis.

OTOH, if some of the operators needed to be friends for some
reason, that's an implementation detail and you can still
document them as == above.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk