ぐち0x13　〜分かったから仕事させてくれ〜

コンパイラもどきを作っているプロジェクト、
新人の漏れがWindowsへ移植作業をしている。

コンパイラもどきだから抽象構文木などのツリー構造があるのは定石どおりだろう。
ツリーのノードの継承関係がテンプレートと入り乱れてかなりのスパゲティでイライラするがそれには目をつぶってもいい。
ツリーの各ノードに情報を持たせるためのクラスとしてプロパティってクラスがあるのもまぁわかる。
だがしかしそのプロパティのクラス定義が：

・自身の名前へのポインタが一つ、アノテーションへのポインタが3つ
　（これはまぁ分かる。）
・プロパティを保持するツリー内の各ノードへのポインタの＊リスト＊
　（ノードへのバックリンクは無駄な気はするけどまぁあってもよかろうが、
　　STLのlist<>をつかってるのはなんでだ？と思っていたら、
　　どうも複数のノードから共有されたりしてるらしい）
・作成元やソースの断片を表すオブジェクトへのポインタへの＊リスト＊
　（STLのlist<>が3つそのプロパティの作成に関わった複数のオブジェクトへのリンクとかで、
　各プロパティの性質や値は作成元など外部のオブジェクトを一々呼び出しに行く仕様らしい…。
　なんでノードであれほど総称と継承を使いまくってるのにプロパティは自前で
　単一のクラス内でプロトタイプ・ベースのオブジェクト指向もどきを実装してるんだ？）
・プロパティ同士のリンクを表現しているらしいプロパティへのポインタのリストがsub,up,down,left,right,linkの6つ
　（ノードのツリーをさかのぼったり兄弟ノードを探したりするためらしい。
　素直にツリーを辿れよ…。ノードを書き換える方式なんだからノードの構成が変わるたびに
　プロパティ内のそのリンクをメンテするコストのほうが大変だろうに…。）
・プロパティとなんらかの名前を結びつけるためと見られるmap<>が7つ
　（これは未だに意味不明だ。変数表らしいデータ構造は名前用に当人が作ったオブジェクトからアクセスできるのに･･･。）
・自前でプロパティ・オブジェクトをリサイクルするためのプールと称するフリーリストが一つ
　（これはクラス変数。しかしConservative GCも使ってるのになんでリサイクルの仕組みがいるんだ？
　それもプロパティにだけ…。）
・プロパティのクラス一個のクラス宣言だけで500行強、メソッド数112個
・メソッドの機能の大半はリストやマップの管理関連だが、
　それらへのアクセスを提供するメソッドは直接リストやマップへの参照を返してしまうので
　カプセル化も全く達成できてない。

…というのは全く理解しがたい。
なんか既にどう見ても抽象構文木のプロパティって代物ではなかろう。
で、この理解しがたいクラスのとあるオブジェクトの中で
プロパティ間のリンクを管理する6つのリストの一個が特定の条件下でだけ破壊される。
移植先であるWindows上でしかそのバグが再現しないので
原作者のEU人は

　「Windowsか移植作業が原因じゃないデスカ？」

などとヌかすが、どうかんがえたってオマヘのバグだろゴルァ！

と長いグチ、御静聴に感謝。