開発三種の神器の一つ「草薙のデバッグブレーク文」が復活した

午前0時半起床,晴れ.朝食は薄切りチーズトースト2枚,コロッケ小1個.「妻を寝取られた男の残念な家系図」をなんとかしなくてはならない.それが目下喫緊の課題だ.かなり難しい問題だがやるしかない.その前に一つ片付けておかなくてはならないことがある.例のSTOP文だ.STOP文は以下のようなマクロとして定義されている.

#define STOP { __asm int 3 }

これまではプログラム中の任意の箇所にこの「STOP」を挿入するだけで簡単にブレークできていたが,Visual Studio 2017 に移行してからはSTOPで止まることができなくなってしまった.いや,一回だけは停止するのだがそのタイミングでコードが書き換えられ,それ以降は止まらなくなる.仕方ないので「初回停止したときに手操作でブレークポイントを設定する」ということにしたが,これではやはり用に足りない.たとえば,

if (some condition) STOP;

という文があったとすると,この文全体にブレークポイントが掛かってしまうためブレーク文の意味がなくなってしまう.

if (some condition) {
  STOP;
}

とすれば条件が成立したときだけ止めるようにすることはできるだが,簡潔さに欠ける.マクロの中でSTOPマクロを使っているような場合などにはお手上げだ.このような状況で,一度は Visual Studio 2005 まで戻ってしまおうか?とさえ考えたのだが,それもあまりに退行的と思われたのでいろいろ試みた末,下記のような代替構文を考案した.

#define STOP { try { __asm { int 0} } catch (…) {} }

__asm int 0 というのはあきらかにイレギュラーなステートメントだが,余分なメッセージを出さずにブレークできるので __asm int 3 とほぼ等価な動作になる.ただし,これは「割り込み」ではなく「例外」なので例外ハンドラーでキャッチする.少なくとも外観的にはこれで完全に int 3を代替することができる.いや,完全に同じではない.STOPでブレークするときには下記のようなパネルすら表示されなかった.まぁ,この程度のことは仕方ない.中断/継続ボタンで動作を選択することができる.

image

「中断」すれば,ブレークした正確なソースコードの行番号が分かる.変数などを調べてからまた「続行」することができるし,「継続」でただちに続行することもできる.これでようやく Visual Studio 2005 で慣れ親しんだ開発環境に戻ることができた.この「STOP文」は馬場研究所の「三種の(プログラム開発用)神器のうちの一つ」とも言うべき大事な「資産」であり,これがなくては手も足も出ない.今後はこれを「草薙のデバッグブレーク文」と呼ぶことにしよう.

ざっくり修正して多少動くようになった.3段階の措置が必要となっている.

  1. MARGBOX::IsPrimeboxOrNotで「基準ノードの配偶者の配偶者で展開」に切り替える 基準ノードの配偶者の配偶者は「単身先祖配偶者」の立場から「本人ポジション」を得て外部系列先祖ノードとなる
  2. DecidePrimaryNode で外部系列の優先ノードを先祖ノードからその配偶者に切り替える decidePrimaryNode では優先ノードが決定できない場合にはTRIBEBOX::GetAlternativePrimeNode を呼び出して代替候補を探す
  3. これにより外部系列に属する「基準ノードの配偶者」は「配偶者ポジション」に配置されるが,多重カード状態を解消するためにはこのあとでBTWを組まなくてはならない.

ステップ2まで消化した段階では多少のエラーを無視して下図が出力される.

image

基準ノードは配偶者を3持っているが,うち2つは外部系列内で配偶者ポジションに配置されている.ここで「基準ノードの子ども枠はBTW不可とする」という制限を外すと基準ノードの配偶者は一人を残して外に出てしまう.この動作はかなり奇妙だ.確かに「基準ノードの子ども枠はBTW不可とする」という規則は「基準ノードの子ども枠はBTWの右枠としない」ことを意味するから,少なくとも外に出てゆく動作はそれに適ったものと言えるが,なぜ一つだけ残るのかその理由が分からない.これは「別の問題」ではあるが,まずこちらから見ることにする.

image||

いや,少し考え違いしていたかもしれない.この図面では基準ノードN氏の配偶者であるYKの出現は2つあるが,どちらも配偶者だ.少なくとも現行ではこのような構図をBTWによって解決することはできない.なぜか?「そうなっていないから」と言えばそれまでだが,BTWが成立するためには少なくとも2人の本人当事者が必要だ.これをA,BとすればAはBと結婚していることが前提となる.このような条件の元で配偶者ポジションのBを消去して多重解消するというのがBTWの仕組みだ.今の場合はA,Bという本人の他にCという配偶者が存在し,AとC,BとCが婚姻しているという構図になっている.

このような状況に対処するためには,BTWの構成を大幅に拡張しなくてはならない.また,それが実現できないといま追求している「残念な家系図」を改善することもできないだろう.というのは,上記したような補正によって発生する図式は明らかにA,B,Cの3つ巴の関係式になるからだ.現行のBTWは Between Two Women と言いながら実際に扱っているのは「遠隔の対関係」であり,三角関係にはなっていない.Cが本人ポジションを持っていれば,2つのBTWを組み合わせることで「両手に花」状態を演出することが可能だが,Cの出現がすべて配偶者ポジションになっている場合には適用不可能だ.

これまでは「多重カードがすべて配偶者ポジションのカードのみの場合には『不可避の多重』として無視する」というルールになっていたが,上記の三角関係BTWが実装されれば,このような「配偶者多重」の問題を解消することが可能になる.これは画期的な進歩であり,もしこれが実現できれば「重婚同類グラフで循環がなければ多重カードは発生しない」という原則を「例外なし」に確立することができる.つまり,系図作図上の最大の課題である「多重カードの極小化」の完全解ないし最適解を得ることができる.

事例では「配偶者多重」が起きているのはほとんど女性の場合に限定されていたので,これを「あちこちに男のいる多情な女が多重になるのはどうしようもない」と解釈して(割り切って)いたが,この判断には「性差に関するある種の偏見」つまり,「男性優位の見方」が影響していたように思われる.「残念な家系図」がクローズアップされたことでようやくこれが「節操のない女の問題」ではなく,一般的な三角関係問題の一部であることが認識されたと言える.

現行のBTWをアレンジするだけでこのような場合に対処することは可能だろうか?現行方式ではBTWの要素は以下に限定される.

  1. BTW左手本人
  2. BTW右手本人
  3. BTW右手枠

BTW左手本人とBTW右手本人はBTW連結線によって結合される.これをBTW対関係と呼ぶとすれば,BTW三角関係は以下の4要素からなると考えられる.

  1. BTW左手本人
  2. BTW右手本人
  3. BTW左手枠 配偶者存続枠
  4. BTW右手枠 配偶者抹消枠

BTW連結線はBTW右手本人とBTW左手枠配偶者を連結するものとなる.この操作によってはBTW左手枠はまったく改変を受けないと考えられるから,無視することができるとすれば,下記のようになる.

  1. BTW左手本人=BTW左手枠配偶者
  2. BTW右手本人
  3. BTW右手枠 配偶者抹消枠

これなら現行のBTW論理とほとんど相似形と言ってもよいトポロジーになりそうだ.BTWは通常BTW左手本人から発案されることになっているので,その資格を「BTW左手枠配偶者」まで拡張すれば何とかなりそうな感じだ.いずれにしてもかなり大掛かりな修正になることは間違いないので,まず,バックアップを取ってから始めるのが適当だ.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA