プログラミング言語C++におけるライブラリ設計で「ADL(Argument Dependent Lookup)経由でのみ呼び出し可能な非メンバ関数／演算子オーバーロード 定義」を実現するテクニック。
2019-12-03追記：2019年11月会合にて (PDF)P1965R0 が採択され、C++標準規格上の用語(term)として "hidden friends" への言及が明記された。
下記説明コードのみではメリットがわかりづらいが、非メンバ関数インタフェース追加による名前空間汚染の抑止と、プログラマが意図しない関数呼び出しによるトラブル回避が主目的。
namespace NS1 { struct C { /*...*/ }; // 非メンバ begin/end 関数 inline C::iterator begin(C& c) { return c.begin(); } inline C::iterator end(C& c) { return c.end(); } } namespace NS2 { struct C { /*...*/ // "Hidden Friends" begin/end 関数 friend iterator begin(C& c) { return c.begin(); } friend iterator end(C& c) { return c.end(); } }; } NS1::C c1; auto b1 = begin(c1); // OK: ADL経由でNS1::begin関数を見つける auto e1 = NS1::end(c1); // OK: 完全修飾名でNS1::end関数を指定 NS2::C c2; auto b2 = begin(c2); // OK: ADL経由でNS2::begin関数を見つける auto e2 = NS2::end(c2); // NG: 完全修飾名ではNS2::end関数を呼び出せない
トラブル事例
LWG3065 よりC++標準ライブラリで実際に問題となったコードを引用する。名前空間std::filesystemの取り込み(using)によりoperator==(const path&, const path&) が導入され、左辺ではコンストラクタpath(const wchar_t(&)[N])*1が右辺では変換コンストラクタpath(string&&)*2が暗黙に呼び出されることで、文字列比較ではなくパス名(pathname)比較 path(L"a//b") == path("a/b") が行われる*3。この問題は Clang 7.0.0 にて再現確認できた。
#include <assert.h> #include <string> #include <filesystem> using namespace std; using namespace std::filesystem; int main() { bool b = L"a//b" == std::string("a/b"); assert(b); // passes. What?! return b; }
同種の問題は LWG2989 でも報告、標準ライブラリ修正されている。
提案文書(PDF)P1601R0 Recommendations for Specifying "Hidden Friends"より一部引用（下線部は強調）。
When there is no additional, out-of-class/namespace-scope, declaration of the befriended entity, such an entity has become known as a hidden friend of the class granting friendship. Were there such an out-of-class/namespace-scope declaration, the entity would be no longer hidden, as the second declaration would make the name visible to qualified and to unqualified lookup.
There have been recent discussions about employing this hidden friend technique, where applicable, throughout the standard library so that the declared entities (typically operator functions such as the new spaceship operator) would be found via ADL only. Because the library has not previously deliberately restricted lookup in this way, there is no precedent for specifying such a requirement. The remainder of this paper provides specification guidance to proposal authors who intend to impose such a requirement.
C++17 6.4.2/p4, 10.3.1.2/p3より一部引用（下線部は強調）。
When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualifier (6.4.3.2) except that:
- Any using-directives in the associated namespace are ignored.
- Any namespace-scope friend functions or friend function templates declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (14.3).
- All names except those of (possibly overloaded) functions and function templates are ignored.
If a
frienddeclaration in a non-local class first declares a class, function, class template or function template the friend is a member of the innermost enclosing namespace. Thefrienddeclaration does not by itself make the name visible to unqualified lookup (6.4.1) or qualified lookup (6.4.3). [Note: The name of the friend will be visible in its namespace if a matching declaration is provided at namespace scope (either before or after the class definition granting friendship). -- end note] If a friend function or function template is called, its name may be found by the name lookup that considers functions from namespaces and classes associated with the types of the function arguments (6.4.2). If the name in afrienddeclaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace. [Note: The other forms offrienddeclarations cannot declare a new member of the innermost enclosing namespace and thus follow the usual lookup rules. -- end note] [Example:// Assume f and g have not yet been declared. void h(int); template <class T> void f2(T); namespace A { class X { friend void f(X); // A::f(X) is a friend class Y { friend void g(); // A::g is a friend friend void h(int); // A::h is a friend // ::h not considered friend void f2<>(int); // ::f2<>(int) is a friend }; }; // A::f, A::g and A::h are not visible here X x; void g() { f(x); } // definition of A::g void f(X) { /*...*/ } // definition of A::f void h(int) { /*...*/ } // definition of A::h // A::f, A::g and A::h are visible here and known to be friends } using A::x; void h() { A::f(x); A::X::f(x); // error: f is not a member of A::X A::X::Y::g(); // error: g is not a member of A::X::Y }-- end example]
関連URL
- https://twitter.com/yohhoy/status/1125671584897744902
- cppreference std::filesystem::path, cpprefjp std::filesystem::path
*1:厳密には template<class Source> path(const Source& source, format fmt = auto_format) テンプレートコンストラクタが選択され（30.10.8.3, 30.10.8.4.1/p7）POSIXベースOSでは未規定(unspecified)なエンコード変換が行われる（30.10.8.2.2）
*2:POSIXベースOSでは path::string_type 型は basic_string<char> となり（30.10.8/p5）、厳密には path(string_type&& source, format fmt = auto_format) コンストラクタが選択される（30.10.8.4.1/p4）
*3:30.10.8.1/p2: "Except in a root-name, multiple successive directory-separator characters are considered to be the same as one directory-separator character."
