問題タブ [circular-dependency]

私には2つのクラスがあります：DataObjectとDataElement。s DataObject（のみ）へのポインタを保持し、aにはいくつかのタイプへのポインタが含まれます。DataElementDataElementDataObject

DataObject以前は、のsへのポインタのみを使用しているため、これは問題ありませんでした。したがって、のヘッダーでのDataElement前方宣言で十分です。DataObjectDataElement

ただし、ここで、にデストラクタを追加しようとしています。ここでは、をDataElement削除する必要がありDataObjectます。これについて、コンパイラは次のように述べています。

どうすればこれを解決できますか？前方宣言は明らかに十分ではありませんが、の完全なヘッダーを含めることはできませんDataObject。これにより、循環依存が再び発生します。

前もって感謝します！

事実：

• マネージャーとスペシャリストという 2 つの主要なクラスがあります。
• スペシャリストにはいくつかの異なるタイプがあります。
• スペシャリストは、自分の仕事を成し遂げるために他のスペシャリストの助けを必要とすることがよくあります。
• マネージャーはすべてのスペシャリストを知っており、最初は各スペシャリストは自分のマネージャーだけを知っています。（これが問題です。）
• 実行時に、Manager はスペシャリストのリストを作成して保存します。次に、マネージャーはリストを繰り返し処理し、各スペシャリストに初期化を依頼します。初期化中、各スペシャリストはマネージャーに、何らかの説明を満たす他のスペシャリストを提供するように依頼します。これが完了すると、マネージャーはループに入り、スペシャリストは専門的なタスクを順番に実行するよう求められます。

これはまともなパターンのように思えますが、マネージャーにはスペシャリストのリストがあり、スペシャリストにはマネージャーがあるため、循環依存の問題が発生しています。

これは、あるクラスの存在を別のクラスから何らかの形で前方宣言する必要がある場合ですか? (そうなら、どのように?) または、この問題を解決するために何らかの設計パターンを使用する必要がありますか? (もしそうなら?) また... 私はパターン自体はかなり大丈夫だったので、これが悪いことである理由を理解するのを手伝ってくれる人を気にしません.

私は2つのプロジェクトを持っています

• UI : すべてのフォームとユーザー コントロールが含まれています
• Translation : UI の翻訳に使用した翻訳コードが含まれています

Ui プロジェクトは翻訳が必要なため、明らかに翻訳プロジェクトへの参照が必要です。

特別な翻訳が必要な UI でカスタム ユーザー コントロールを定義したためです。翻訳プロジェクトは型を知る必要があるため、翻訳にもUIへの参照が必要であり、その結果、循環依存が生じます。

これは実際に問題ですか?はい、どうすればこれを最もよく解決できますか? カスタム タイプを取り出して別のプロジェクトに入れますか?

ありがとう

ゲームエンジン用のコンポーネントベースのエンティティシステムを作成しています。

コンポーネントの配列を定義するためにコンポーネント基本クラスヘッダーを含める必要があるエンティティクラスがありますprivate Component* components[ 123 ]

ただし、コンポーネントの基本クラスでは、を定義する必要がprivate Entity* ownerEntityあります。これは、コンポーネントが誰に属しているかを知っていることが重要だからです。

これにより、Entity.hにはComponent.hが必要になり、その逆も同様です->循環参照

どうすればこれを解決できますか？

Parentと合成関係を持つクラス、たとえば を作成したとしChildます。親クラスは、子のリストを保持します。

すべての子が親への参照を保持するようにしたいので、すべての子がParentポインターを保持します。

これにより、循環包含が発生します。parent.h で参照しChild、child.hで参照Parentします。したがって、Parentを含めるChild必要があります。これには を含める必要がありますParent。

これを回避する最善の方法は何ですか?

Boost Graphics Library の adjacency-list の使用に問題があります。循環依存の問題のようです: クラス A を使用するテンプレートの typedef T があります。さらに、A は型 T のオブジェクトへのポインターを格納します。コンパイラは、T が型に名前を付けていないことを教えてくれます。

以下は、より具体的なファイルの抜粋です。

この依存関係/包含順序の問題を解決するにはどうすればよいですか?

別の編集: edge_descriptor の型は int のようなプリミティブ型である可能性があるという考えがありました。Lane の edge_descriptors を単純な int 変数に置き換えることができ、tie.hpp 内の graphdefinitions.hpp のインクルードを削除できたので、これで問題は解決したはずです。残念ながら、私の考えはひどいものでした。別の解決策を見つけなければなりません。Edge_descriptor タイプは理由があるようです...

循環インポートで 2 番目のモジュールが最初のモジュールの変数を変更できるようにしようとしていますが、うまくいかないようです。

2 つの質問があります: 1) なぜこれが機能しないのか / 言語開発の観点から見た理由は何ですか? 2) 同じことをおそらく少し異なる方法で実行できる簡単な解決策はありますか?

a.py:

b.py:

スワップ可能なハッシュ関数を使ってハッシュテーブルを定義したいと思います。ハッシュ関数は、ハッシュテーブルとハッシュされるキーへのポインターを受け取り、次のようなintを返します。

ここで、ハッシュテーブルには、キーのハッシュに使用される関数へのポインターが格納されます。

残念ながら、これは循環参照を作成します。

ハッシュ関数定義にハッシュテーブルへのポインターが必要です。これにより、ハッシュテーブルのサイズに対してモジュラスを実行できるため、バケットの最大数を超えません。ハッシュ関数ポインターをあちこちに渡す必要がないように、ハッシュテーブルにハッシュ関数が必要です。

私はこれが次のようなコードにつながることを理解しています：

これは少し奇妙ですが、私はそれで大丈夫です。

typedefをどちらかの順序で配置しても機能しません。ハッシュテーブルで長い定義を使用し、後でtypedefを実行する必要がありますか、それともより良い方法がありますか？

これはすべてストレートCで意図されており、C++ではありません。ANSI Cソリューションをお勧めします！

Visual Studio ソリューションに 2 つのクラス プロジェクトがあります。プロジェクトの性質上、両方のプロジェクトは互いのサービスを必要とするため、お互いを参照します (「私はあなたの背中を掻き、あなたは私の背中を掻く」というフレーズを考えてみてください)。

Visual Studio (2010) では、プロジェクト a からプロジェクト b への参照を追加できません。これは、プロジェクト a が既にプロジェクト b を参照しているためです。

この循環依存を解決するためにどのような戦略がありますか?

ありがとう