おもちゃのコンパイラのシンボルテーブル

Question

私は個人的なプロジェクトとして（クールな言語用の）コンパイラを作成していますが、シンボルテーブルを設計する際に問題があります。コンテキストの場合、私はASTとしてクラスの階層を使用しています。ここではASTの小さな抜粋です：

現在

class NodeAST { 
public: 
    virtual void accept(Visitor&) = 0; 
}; 

class ProgramAST : public NodeAST { 
private: 
    const std::vector<ClassPtr> vClasses; 

public: 
    ProgramAST(std::vector<ClassPtr> vClasses); 

    auto class_cbegin() const { 
    return std::cbegin(vClasses); 
    } 
    auto class_cend() const { 
    return std::cend(vClasses); 
    } 

    virtual void accept(Visitor& v) override; 
}; 

class ClassAST : public NodeAST { 
private: 
    const std::string name; 
    const std::vector<FeaturePtr> vFeatures; 

public: 
    ClassAST(std::string name, std::vector<FeaturePtr> vFeatures); 

    auto getName() const { 
    return name; 
    } 

    auto feature_cbegin() const { 
    return std::cbegin(vFeatures); 
    } 
    auto feature_cend() const { 
    return std::cend(vFeatures); 
    } 

    virtual void accept(Visitor& v) override; 
}; 

、私のシンボルテーブルの中心に、以下のように定義されたマップである。

std::unordered_map<std::string, NodeAST*> table 

それはで対応するノードに宣言の名前をマップAST。このようにして、たとえば、私がASTノードで設定した型を使って、ゆるい識別子の型を記入することができます。

ただし、ノードのシンボルテーブルにクエリを実行すると、NodeAST*が返されるという問題があります。実際に使用するにはClassAST*、MethodAST*、VarDecAST*などにダウンキャストする必要があります。

ダウンキャストの必要性を回避する方法でシンボルテーブルを設計するにはどうすればよいですか？

Answer 1

私が実装しているプログラミング言語はわかりませんが、実際には動的キャストを完全に避けることができるとは思われません。たとえば、f(1)の場合、fは、言語にラムダがある場合は関数または変数のいずれかになります。あなたはそれをシンボルテーブルで調べることで見つけ出す必要があります。

この可能性を絶対に排除できれば、理論上は各タイプごとに別々のシンボルテーブルを作成できます。しかし、もしあなたがそれらを検出する必要があるならば、明らかに名前の衝突を見つけるのが難しくなり、プログラミング言語が後で拡張するのが難しくなるかもしれないことを覚えておいてください。私はこのソリューションをお勧めしません。動的キャストは、カプセル化され、全体のコードベースを中心に広がらないように

個人的に私はちょうど、あなたのNodeASTクラスにto_class()、to_var()、is_class()、is_var()などのようなメソッドを追加します。 get_class(),get_var()など

RTTIのランタイムコストが懸念される場合は、他のコンパイラが使用しているソリューションを参照することができます。また、シンボルテーブルのクラスを作成することもできます。 LLVMについては、ここで説明します：http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

Answer 2

私はVisitor Patternを使用して共通のベースを持つポインタのコンテナにアクセスしています。 1つの実装では、dynamic_cast <の実装よりも約40％のスピードアップを経験しました。これは、私が書いていたデータベース抽象レイヤーで重要でした。

ここでの答えの一つでもう少し説明があります.... Visitor Pattern上Right design pattern to deal with polymorphic collections of objects

Wikipediaのページには、ディスパッチャクラスによって訪問されたベースポインタのコレクションの素敵な短いC++の例を示します。

質問に「訪問可能」クラスのソースコードが表示されています。 dynamic_cast <>が必要な理由を確認するには、「訪問者」の実装を確認する必要があります。それは必要ではありません。使用する正しいvisit（）関数は、関数パラメータのオーバーロードによって選択する必要があります。

乾杯