From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
From: "Jonathan Turkanis" <technews@kangaroologic.com>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;