C ++のネストされたプライベート構造体タイプを考えると、ファイルスコープの静的関数からそれにアクセスするための戦術はありますか？

誰かが次の引用で著者ジョン・ラコスによってほのめかされた正確なコーディング戦術を説​​明できますか？

ジョン・ラコス：

さらに議論の余地があるのは、構造体のコピーを2つ持つ方がよい場合が多いことです。たとえば、1つは.hファイルにネスト/プライベート（インラインメソッドやフレンドにアクセス可能）、もう1つは.cppファイルのファイルスコープに（file-にアクセス可能）です。スコープ静的関数）—実装の詳細でグローバル空間を汚染するのではなく、ローカルで同期を維持するようにしてください。

引用は、新しいLakosの本であるLarge Scale C ++に表示されます。

（この本は、Lakosの以前の本であるLarge Scale C ++ Software Designと同じ主題の更新された扱いです）

引用はセクション0.2、9ページにあります。

後の章でLakosが何を説明しているのかが明確になったら、ここに戻って回答を投稿します。

その間、私は引用を理解することに魅了されました、そして、さらなる手がかりのために本の目次と索引をスキャンする私の試みはまだ答えをもたらしませんでした。

これは、神秘的な戦術によって解決されると私が想像する問題の私自身のサンプルコードです。

// THE HEADER

namespace project
{
class OuterComponent
{
public:
    inline int GetFoo()
    {
        return m_inner.foo;
    }

    int GetBar();

private:
    struct InnerComponent
    {
        int foo = 0;
        int bar = 0;
    };

    InnerComponent m_inner;
};
} // namespace project

一緒に：

// THE CPP IMPLEMENTATION FILE

namespace project
{
namespace
{
    /*
       MYSTERY:
       Per the book quotation, I can somehow add a "copy of InnerComponent" here?
       And "make sure to keep them in sync locally"?
    */

    // COMPILATION ERROR (see below)
    int FileScopeComputation( OuterComponent::InnerComponent i )
    {
        return i.bar - 3;
    }
} // namespace

int OuterComponent::GetBar()
{
    return FileScopeComputation( m_inner );
}

} // namespace project

もちろん、上記はコンパイルされません。

エラーは次のようになります。

error: ‘struct project::OuterComponent::InnerComponent’ is private within this context
     int FileScopeComputation( OuterComponent::InnerComponent i )
                                               ^~~~~~~~~~~~~~

名前の付いた無料の関数は、私がよく理解している理由でFileScopeComputationアクセスできませんInnerComponent。

上記のコードを本の見積もりに関連付ける

これをLakosの引用に戻すと、私の考えはFileScopeComputation、引用が「ファイルスコープ静的関数」と呼んでいるものの1つのインスタンスであると考えています。

コードをコンパイルするInnerComponentための「明らかな」解決策の1つは、のpublicセクションで宣言されるように移動することですOuterComponent。

しかし、私は自分の「明白な」解決策を（引用によると）「実装の詳細でグローバル空間を[汚染]する」罪を犯していると考えています。

したがって、私のコードは、（a）ほのめかされた戦術の目標と、（b）1つの潜在的な解決策の望ましくない汚染の両方を捉えているようです。では、代替ソリューションは何ですか？

どちらかまたは両方に答えてください：

（1）struct InnerComponentフィールドOuterComponent::m_innerがプライベートのままで、タイプOuterComponent::InnerComponentもプライベートのままであるように、cppファイルに別のコピーを作成する方法はありますFileScopeComputationか？それでも、関数には、のインスタンス上のデータにアクセスするのと「同等の」何かを行う方法があります。InnerComponent？

私はキャスティングでいくつかの奇妙なことを試しましたが、本の中で推薦する価値があるように見えるものは何もありません。一方、本の中でラコスが推奨するものはすべて、非常に推奨に値するものであるというのが私の経験です。

（2）見積もりがどのようなシナリオに適用されるかを完全に誤解していますか？もしそうなら、引用が実際に言及しているC ++ソフトウェア設計の問題は何ですか？他にどのような問題がありますか？「構造体の2つのコピー... 1つはhファイルにあります...もう1つはcppファイルにあります」？

更新：

dfriによる知覚的な答えに基づいて、上記のコードは実際に最小限の変更でコンパイルすることができ、次のようになります。

• フィールドOuterComponent::m_innerはプライベートのままです
• タイプOuterComponent::InnerComponentもプライベートのままです
• それでも、この関数にFileScopeComputationは、次のインスタンスのデータにアクセスする方法があります。InnerComponent

ヘッダーコードには、次の1行のコードが追加されます。

...
private:
    struct InnerUtil; // <-- this line was ADDED. all else is same as above.
    struct InnerComponent
    {
        int foo = 0;
        int bar = 0;
    };

    InnerComponent m_inner;
};

そして、cppファイルコードは次のようになります。

struct OuterComponent::InnerUtil
{
    static int FileScopeComputation( OuterComponent::InnerComponent i )
    {
        return i.bar - 3;
    }
};

int OuterComponent::GetBar()
{
    return InnerUtil::FileScopeComputation( m_inner );
}