> 見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･
見間違いかと思います (^^;
create.cで解析木のノードを確保する際も、fix_tree.cで主にTypeSpecifierを
確保する際も、最終的にはdkc_malloc()を呼んでいますし、dkc_malloc()は
コンパイラが保持してるMEM_Storageを使用してメモリ確保しています。
http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/11.html#22
> 実は、構文解析で構文ツリーが出来た時点では、TOPのCT_Compilerのオブジェクトを
>deleteすればディストラクタ繋がりできれいに総てのメモリーを解放できたのですが
>Fixtreeを作ってみると、多重リンクはするはリンクが切れてフリーが山ほど出てくる
>はで。
fix_tree.cでは主にTypeSpecifierを解析木に付加しますが、おっしゃるとおり、
たとえばある式がintのTypeSpecifierを持っていて、それにマイナス演算子を適用した
ような場合には、マイナス演算子の式のTypeSpecifierは、その子ノードのものを
直接使用していたはずです(多重リンク)。また、[]演算子を適用するとTypeDeriveが
1段階外されますが、この時、[]演算子のノードのTypeSpecifierは、TypeDeriveの
連結リストの途中のノードを指します(その下のノードでは根元を参照していますが)。
このへんのことは以下にちょっとだけ書いてありました。
http://kmaebashi.com/programmer/devlang/diksam_0_1_comp.html
| コンパイル時のTypeSpecifierは、なにしろ解析木のすべての式のノードに
| 割り当てられます。たとえば「a + 1」という式がありaがint型の時、
| intを表現するためのTypeSpecifierが(「a」と「1」と「a + 1」のために)
| (現状の実装では)3つ確保されています。でもよく考えれば「a + 1」のノードの
| TypeSpecifier は左辺か右辺かどっちかのを直接参照してもよいはずで、
| 実際マイナス演算子ではそうしています。
| このように、TypeSpecifier構造体は、誰が所有者なのかわけがわからんような
| こんがらがった参照で保持されているので、解析木の他の部分同様、
| コンパイル終了時に(MEM_Storageの機能を使用して)一括で破棄しています。
>class CT_Compiler : public CBase
>{
>public:
> CT_Block * current_block; // 一番外側のブロック
微妙に気になるのですが、current_blockは、少なくとも元のソースでは、
「一番外側のブロック」ではなく、その名のとおり「現在のブロック」です。
create.cにおいてBlockを生成する際に、親のブロックへの参照をセットするために
使用しています。
>class CT_Expression : public CBase
>{
...
> union {
> ST_MemberExpression member_expression; // 使用していない？
これは、オブジェクトのメンバを参照するためのノードですが、
クラスを導入していないver.0.2では確かに使っていませんね。
ていうかソースには一応入っていたことに私の方が驚きました。