ここでは何が起こっていますか？

Question

これは、

#include <boost/intrusive_ptr.hpp> 

class X 
{ 
public: 
void intrusive_ptr_add_ref(X* blah) 
{ 
} 

void intrusive_ptr_release(X * blah) 
{ 
} 

}; 



int main() 
{ 
    boost::intrusive_ptr<X> ex(new X); 
} 

をコンパイルしていません。しかし、このことを行います

#include <boost/intrusive_ptr.hpp> 

class X 
{ 
public: 
    friend void intrusive_ptr_add_ref(X* blah) 
    { 
    } 

    friend void intrusive_ptr_release(X * blah) 
    { 
    } 

}; 



int main() 
{ 
    boost::intrusive_ptr<X> ex(new X); 
} 

と、この：

#include <boost/intrusive_ptr.hpp> 

    class X 
    { 
    public: 


    }; 


    void intrusive_ptr_add_ref(X* blah) 
     { 
     } 

     void intrusive_ptr_release(X * blah) 
     { 
     } 

int main() 
{ 
    boost::intrusive_ptr<X> ex(new X); 
} 

私はそれがSFINAE（I天国」とは何かを持っていると仮定しますtはまだ理解して気にしていますか？）友人修飾子は、囲まれた名前空間に定義された関数を自由な関数として入れますか？ （これらの特定のメンバ関数が... documentionに記載されていない）add_refとreleaseとして非フレンド、メンバ関数を自分の投稿を削除誰

編集

は、問題を解決しました。 friend修飾子を含むネストされた定義はどうなりますか？

Answer 1

boost::intrusive_ptrのドキュメントから：

すべての新しいintrusive_ptrインスタンスはそれを引数としてポインタを渡し、関数intrusive_ptr_add_refに修飾されていない呼び出しを使用して参照カウントをインクリメントします。同様に、intrusive_ptrが破棄されると、intrusive_ptr_releaseが呼び出されます。この関数は、参照カウントがゼロになったときにオブジェクトを破棄する責任があります。ユーザは、これら2つの機能の適切な定義を提供することが期待される。引数依存ルックアップをサポートするコンパイラでは、intrusive_ptr_add_refおよびintrusive_ptr_releaseは、そのパラメータに対応するネームスペースに定義する必要があります。さもなければ、定義は名前空間を後押しする必要があります。

これは、intrusive_ptr_add_refとintrusive_ptr_releaseがメンバ関数ではなく、フリー関数（フレンド関数はそのように動作する）であるべきであることを意味します。さらに、それらは資格なしで呼び出されるため、グローバル名前空間に置かれるか、ADLによって見つかるはずです。

編集：friend修飾子を使用して、ネストされた定義についてのご質問： friend機能が非memberfunctionsのように定義されているので、friend void intrusive_ptr_add_ref(X* blah)はmy_x_ptr->intrusive_ptr_add_ref()としてintrusive_ptr_add_ref(my_x_ptr)の代わりとして呼び出されます。