K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>>　見間違いかもしれないけど、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では確かに使っていませんね。
>ていうかソースには一応入っていたことに私の方が驚きました。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！