どうも進捗が捗々しくない．少しピッチを上げることにしよう．
▲BUG20-12-02 01-34-26.ZELを起動→終了してPAIRLIST：checkdatacountでデータ数不一致が検出される datacount=3に対し，実カウント2
仮修正や条件コンパイル文が錯綜してフローを解析するのがとても難しい．この際思い切ってすべて現状でフィックスしてからデバッグに入ることにする．舵を切らずに直進するという選択が正しかったかどうかはいずれ判明することだ．以下のOPTIONSがある．
- 確定世代番号を導入する＠20201121 41箇所
- EraseFamilyTreeに終了モードを導入＠20201124 3箇所
- 同一世代人名枠チェーンをリングに転換＠20201201 9箇所
- PAIRLISTにdataCountDownを導入＠20201122 22箇所
- blackflagの論理逆転＠20201128 16箇所
- toplistを関数化（参照化）＠20201201 2箇所
- UNDO保全ノードをNringから除外＠20201202 3箇所
- コアシステムの参照を関数化＠20201127 28箇所
Dドライブが満杯になってしまったので，バックアップをEドライブに移動．84,211個のファイルを移動して空き容量66GBになった．これでまたしばらくは遊べる．上記OPTIONSはすべてフィックスした．
上記エラーはPAIRLIST::Remove→LIST::dataCountDown→DATALIST：dataCountDown→ DATALIST::findで起きている．この直後にdatacountがデクリメントされるのだから不一致となるのは当然のようにも思われる．findは接続ベースの関数だから削除操作中にも使われるが，checkdatacountをこのようなクリティカルゾーンで動作するようにできるだろうか？⇒内部処理であれば，removingがONであることで判定できる．外部処理の場合はそれもできないが，dataCountDownの中なら可能かもしれない．ただし，dataCountDownが実行された後でもremovingの状態は継続している．blackflagがONになったときはdataCountDownが完了したとみなすことはできるかもしれない．
PAIRLISTは単純な直列リストではなく，そこから分岐した枝リストをもっているためPAIRLIST::Removeはかなり難しい関数になっている．しかし，木構造を持っているのはPAIRLISTだけではないので，これがこなせないようではZTに明日はない．暫定的にPAIRLISTにunsettledというフラグを設けて，この区間ではcheckdatacountは無効であるということにしてみよう．⇒エラーは解消した．というより回避できるようになった．PAIRIST::cancelの格段でcheckdatacountを実行しているのでデータ整合性の問題は発生していないことが確認できる．この辺りはもう少し整理しておきたいところだが，先に進むことにしよう．⇒ここで一度バックアップを取っておこう．
仮修正がまだ34個残っている．⇒クリアした．#ifdefと#ifndefも書き換えておこう．#ifdefが44個，#ifndefが31個あった．INCOMPLETE:に2つオプションが入っている．「タイトル枠無しで動作する＠20201119」と「EraseFamilyTreeで削除しない＠20201120」だ．前者はTITLEBOXが空という状態を認めるという仕様変更だが，まだ動作確認していないので追ってということにしておく．後者はまったく参照されていないので捨ててよい．もう一つ，「nodule_floatは間違っている＠20201120」というのがある．これはもう少し置いておこう．懸案事項が大分積み上がっているのでメモっておこう．
- OnListremove，removingを廃止
- CallSetCouplingPtrを始末する，終末期のフェーズ
- dataCountDownの一般化，blackflagの廃止
- nodl_floatを終了処理に含める
- unsettledの一般化，On～フラグの代替？
- 検査区間（フェーズ）の点検，INITIALSTATEなど
- エラートラップを点検，throw errを廃止
- グローバル変数の廃止/局所化
- ReferenceList（参照チェックリスト）の廃止
OnLISTremoveは，DATALIST::cancelとLIST::cancelで設定され，リスト要素削除中のインジケータとして用いられてきたが，賞味期限が過ぎたので廃止してよい．unsettledを使ってほぼカバーできる．unsettledの意義付けはいまのところややあいまいだが，基本的には「接続関係が流動的」と解される．現行ではこれに類似したフラグとしてOn～というのが100個ほどある．関数～を実行中という意味のフラグだが，用途によってはunsettledで代替できるような気もする．
removingもリスト要素削除中フラグで，LIST::deleteElement，LIST：_remove，DATALIST::deleteElement，NLIST::put，PAIRLIST：Removeでセットされている．unsettledの区間はremovingよりやや広く，これだけでremovingをカバーできる．unsettledは現在PAIRLISTのメンバーとして定義されているが，有用性が認められればDATALISTファミリからnoduleクラス全体まで拡張することが考えられる．
nodule::nodl_floatはオブジェクトをシステムから切断してフロート状態にするための汎用関数で，そのオブジェクトの下位コンポーネントは接続したまま取り出される．ただし，そのオブジェクトがリスト上にある場合はそのオブジェクトの後続ノードはリストに残される．Disconnectもこれに類似した関数だが，Disconnectの場合には後続リストとともにそっくり取り出される．繋ぎ戻すための関数としてはConnectとReConnectがある．
PAIRLISTではnodl_floatでフロート化したオブジェクトを別のリストに移動する場合があり，このときはリストから切断するという操作が実施されるため，実質的に削除と同等の操作が必要になる．他のクラスではスロットの移動など接続関係の操作のみで完結するため，「事前処理」のようなものは必要としていない場合が多い．先にblackflagの廃止を試してみることにしよう．⇒実装した．
▲BUG20-12-02 01-34-26.ZELを#195 ghostnodeで起動して，PAIRLIST::CheckVerticallyInverseで(pbox->getpairlist() != this)により停止した