看這一段**：
struct友元關係不能繼承。
但考慮這麼乙個情景：
你想構建任意多的擴充套件去豐富b的功能，而這些擴充套件要用到b的一些非公開方法。
既然是非公開，那就得友元了，但是擴充套件的類名你又不知道。
最直觀的想法就是建立乙個擴充套件基類a，a是已知的，可以讓a成為b的友元。
然後就遇到了上面的問題。
當然也不是沒法解決。
既然a已經是b的友元，那只要在a裡把b的方法給**一下就好了，缺點就是要用到幾個方法就得手動構造幾個方法……
這不就是……
當然也有更簡潔但更粗暴的做法：
struct在寫擴充套件的地方，類名已經確定了，於是就可以達成目標。
事實上，我覺得public/protected/private + friend這種訪問權管理是非常簡陋的，有股濃濃的linux777許可權管理的味道。
在大多數時候它都夠用。但當你需要更精細的許可權控制時，不足就很明顯了。
教科書裡的友元，通常是為了操作符過載。但實際用到友元的時候，通常是想暴露一些介面給一些特定的類。
可是友元就跟巨集一樣缺乏約束能力，還有向前宣告的***，無形之中形成了一些語法上的坑。
如果不考慮向後相容以及歷史包袱的話，我覺得友元就該取消，轉而用類似模板、concept的語法格式去實現友元，甚至是實現private、protected、public：
class不過當private遇上繼承，當訪問許可權遇上可見性，坑依舊存在。
c 友元關係與繼承
友元關係不能繼承。基類的友元對派生類的成員沒有特殊訪問許可權。如果基類被授予友元關係，則只有基類具有特殊訪問許可權，該基類的派生類不能訪問授予友元關係的類。class base frnd has no access to members in d1 class d1 public base clas...
C 筆記 繼承,友元
一 友元關係 友元關係不可繼承,base是基類,derive是派生類,f是base的友元,這麼說來,f不能訪問derive的private成員 是無誤的 但是還是不夠準確,假設base有乙個privata的virtual函式func derive繼承並重寫了此函式,那麼在基類的友元f中有如下 看似f...
C 繼承 友元 許可權
1，c 類的繼承分 public protected private三種 基類的成員 public protected private 被public繼承後 public protected private 被protected繼承後 protected protected private 被pri...