問題タブ [cyclic-reference]

少し複雑なオブジェクトを含む Web サービスで JAXB を使用しています。オブジェクトの 1 つである Sensor には、通信できる他のオブジェクトのリストがあり、必然的にそれ自体 (変更できない動作) を含めることができるため、XML へのマーシャリング中に循環参照が発生します。

上記のように、 @XmlIDREF と @XmlID を使用してこれを解決しましたが、非常にうまく機能します。

wsimport によって生成されたクライアント側コードは、オブジェクトを XML にマーシャリングし、サーバーはそれらを完全にアンマーシャリングできます。

私が経験している問題は、センサー オブジェクトをマーシャリングしようとすると、何らかの理由でサーバー側で循環参照例外が発生することです。腹立たしいのは、wsimport がクライアント側コードを作成するために使用する JAXB 注釈がサーバー側コードに含まれていることです。これはうまく機能しますが、サイクルのためにサーバー側センサーをマーシャリングできません。

JAXB がクライアント側のコードに追加するすべての余分な注釈をサーバー側のクラスにコピーしようとしましたが、おそらく JAXB に @XmlIDREF 注釈の適切な適用を妨げていたランタイム バグがあると考えました。そこには運がありません。

おそらく、ここで欠けている非常に基本的なものがありますが、この問題は私を少しバタバタさせており、それを理解しようとしている間、私は完全に停止しています.

調査中に気づいたことの 1 つは、コードは機能しますが、生成されたクライアント側オブジェクトの名前空間の一部が期待どおりではないということです。サーバー上の名前空間の問題が原因で IDREF マーシャリングが爆破されているかどうかを知りたいです。

子午線と緯線を格納するための次のデータ構造があります。

各地図ポイントには、次のものが格納されます。
A] 地理的および空間座標、地図作成の歪みなど。
B] 北/南/東/西ノードへのポインター。

ポイント間の関係、まず子午線/平行線への所属を保存できます...

子午線のデータ構造には、子午線の経度、子午線の始点と終点、点数が格納されます。

すべてのポイントはノード リストに格納されます。

しかし、Node2DList のコピー コンストラクターの作成には大きな問題があります。Meridian/Parallel と Node2Dlist の間には循環的な依存関係があります。

コピー コンストラクターはstd::map古いポイントとリンクを使用して新しいものに置き換えますが、これは実装上の問題ではありません...ただし、クラス Meridian ポイントから古い Node2DList のポイントへのポインターの開始/終了... Node2DList コピー コンストラクターは、古いポイントを指すすべての子午線を通知する必要がありますNode2DList ポイントを変更し、すべてのポインタを新しい Node2DList ポイントに変更します。このモデルはそれを許可しません。

考えられる解決策は、子午線と平行点を指す 2 つのポインターを追加することです。

残念ながら、この提案されたモデルは良くありません。2 つのクラス間の循環参照がまだあります...誰かがそれを改善するのを手伝ってくれますか? ありがとう...

私はこのファイルlogger.hppを持っています：

そしてこのファイルevent.hpp

上手。logger.hppにはevent.hppを含め、event.hppにはlogger.hppを含めます。

• logger.hppで演算子を定義する必要があるため、event.hppを含める必要があります。

• event.hppには、クラスEventで定義される友情があるため、logger.hppを含める必要があります。

もちろん、これは周期的な再帰です。

私はこれを試しました：

1）logger.hpp：

動作しません。コンパイラは、event.hppにLoggerと呼ばれる認識されないタイプがあることを教えてくれます（そしてもちろん彼は正しいです）：

ISO C ++は、タイプのない「ロガー」の宣言を禁止します

コンパイラは、友情宣言がある行（event.hpp内）を示します。

2）event.hppの場合：

動作しません。コンパイラーは、logger.hppにEventと呼ばれる認識されないタイプがあることを教えてくれます（そして、これも明らかな理由で正しいです）：

ISO C ++は、タイプのない「イベント」の宣言を禁止します

コンパイラは、演算子宣言がある行（logger.hpp内）を示します。

さて...これに直面する方法がわかりませんか？私はすべてを試し、どこにでも宣言を出しましたが、もちろん、それらは何の助けにもなりません。これを解決する方法??? （ベストプラクティスが存在すると思いますが、そう願っています:)）。

ありがとうございました。

ネストが深すぎるコードブロックを含むメソッドから開発者に警告し、混乱を再ファクタリングするように促すカスタムFxCopコード分析ルールを作成しようとしています。

元。私は次の状況を避けようとしています：

VisitBlock(Block block)ブロックの深さをカウントするメソッドをオーバーライドすると、スタックオーバーフローが発生します。
これは、ブロックのプロパティの1つからブロック自体への循環参照があるためです。つまり、一部のiには次のことが当てはまります。block.Statements[i]==ブロック

なぜそのような循環参照が存在するのですか？それを回避する方法は？ありがとう！

スコット・マイヤーズの「EffectiveC++」の本を読んでいます。tr1::shared_ptr組み込みのポインタがあり、そのように動作することが言及されましたが、それらはオブジェクトを指す tr1::weak_ptrポインタの数を追跡します。tr1::shared_ptrs

これは、参照カウントとして知られています。これは、非循環データ構造でのリソースリークの防止に役立ちますが、サイクルが形成されるようなオブジェクトが2つ以上含まれtr1::shared_ptrsている場合、サイクルへのすべての外部ポインタが破棄された場合でも、サイクルは互いの参照カウントをゼロより上に保つ可能性があります。

それがtr1::weak_ptrs入ってくるところです。

私の質問は、循環データ構造が参照カウントをゼロより上にする方法です。C++プログラムの例をお願いします。問題はどのように解決されweak_ptrsますか？（繰り返しますが、例を挙げてください）。

次のことについて最善の方法について質問があります

クラス B があり、B にコンビネータがあり、foo : B -> int とします。

クラス B にメソッドとしてカプセル化されたコンビネータを持たせたいので、型拡張で追加します。

私は後で foo が非常に高価であり、遅延評価で結果をキャッシュしたいことに気付きました

そのため、コンビネーターを関数としてコンストラクターに渡し、コンストラクターで foo = lazy(foo self) を使用してフィールドを初期化することで、システムに巨大なクラッチを追加します。

すなわち

これは明らかに気分が悪い

これを修正するために私が見る2つのオプションは、1、インターフェースを作成し、fooにそのインターフェースを継承させる、2、すべてを静的メソッドにしてから、それらの静的メソッドからコンビネーターを作成することです（クラスにアタッチするのとは逆のようなものです... )

これらはどちらも非常に魅力的ではなく、オプション 3 を見逃したのではないかと思っていました。

ああ、私は let rec を取得できず、これをうまく処理できませんでした。また、上記のステートメントの「何か」は、関数に依存する関数に依存する関数に依存するので、本当にしたくありません( 3 深さ）。

アドバイスをいただければ幸いです

私はこのトピックに関するいくつかの情報を検索して見つけましたが、答えは混乱するか、当てはまらないかのどちらかです。

私はこのようなものを持っています：

ここで、ファイルをロードして解析し、そこからこのデータ構造を設定します。それは不変で循環的ですが、どのようにそうすることができますか？

また、このデータ構造にデータを入力したとしましょう。rootThing.refs（3）.nameを変更するなど、変更したいのですが、どうすればよいでしょうか。

ここに投稿されたアイデアをありがとう。この時点で、このような永続的なデータ構造が本当に必要な場合は、既成概念にとらわれずに考え、クライアントコードがどのような質問をする必要があるかを検討することを考えています。したがって、オブジェクトやフィールドについて考えるのではなく、クエリやインデックスなどについて考えてください。まず、私は次の観点から考えてい ます。双方向のマルチマップ永続データ構造はありますか？

EF 4 で回避しようとしている従来のデータベース設計があります。基本的に、相互に参照する 2 つのテーブルがあり、新しいエントリを追加しようとすると問題が発生します。

私の構造はこれです：

Person には Account (AccountId) への外部キーがあり、Account には Person (PrimaryPersonId) への外部キーがあります。新しいアカウントと個人を作成する場合、これは明らかに問題です。現在の解決策は、Person テーブルで挿入トリガーを使用して、個人が作成されたときに Account テーブルを新しい PrimaryPersonId で更新することです。

トリガーを必要とせず、可能であればこのコードをモデルに取り入れて、「魔法」が発生しないようにしたいと思います。EF 4でこれを行う良い方法はありますか?

循環参照のある「楽しい」：

父親IDによってモデル化された要素の階層を含むテーブルELEMENTSがあるとします。

ルートの父親IDフィールドはnullです。

他のすべてのレコードには、父親要素の（自動シーケンスされた）主キー（ID）を持つnull以外の父親IDがあります。

たとえば、

無効な父親参照を持つすべての要素を見つけることができます（FATHER_ID外部キーではありません。この例ではそれを想定します）。

しかし、有効な父親参照を持っているが、父親参照のチェーンがルートで終わっていない要素をどのように見つけることができますか？これは循環参照でのみ発生する可能性があると思います。たとえば、AはBの父ですが、BもAの父です。このような「サブツリー」はルートにリンクされていないため、メインツリーの一部ではありません。そのようなサブツリーを見つけたいです。

もちろん、参照のチェーンがどれほど長くても、循環参照につながる要素を提供するクエリを探しています。

それはSQLで可能ですか、それとも反復的なソリューションが必要ですか？

いくつかの循環参照があるレガシーデータベースを使用しています。SL4クライアントからRiaサービスを利用する場合。（ORMマッパーを介して生成されたエンティティ）次のエラーが発生します：

パラメータhttp://tempuri.org/:GetPublicationPagesResultをシリアル化しようとしたときにエラーが発生しました。InnerExceptionメッセージは「タイプ」xxx.Entities.TblPublicationPageのオブジェクトグラフにサイクルが含まれており、参照追跡が無効になっている場合はシリアル化できません。

CyclicReferencesAware属性またはIsRefence=trueを使用してプレーンWCFに対して有効にする方法を知っています。しかし、WCFRiaServicesでこれを行う方法がわかりません。