I need to get all the syntax trees that referenced to a given syntax tree.
Following is my use case:
User selected the Class1.cs which has a reference from Class2.cs,Class3.cs,...
Requirement:
I need to get all the syntax trees which are referenced by the selected class (Class1.cs)
Related
I am implementing a symbol table as described in the dragon book:
class SymbolTable {
std::unordered_map<std::string, Record> table;
SymbolTable* parent;
public:
SymbolTable(SymbolTable* p) : parent{p} {}
const Record* lookUp(const std::string& name) const {
for (auto* scope = this; scope != nullptr; scope = scope->parent) {
auto iter = scope->table.find(name);
if (iter != cend(scope->table))
return &iter->second;
}
return nullptr;
}
bool insert(const std::string& name, const Record& record) {
return names.insert({name, record}).second;
}
};
However, I am not sure how to store the record data. Who should own the type information? Should Record contain a non-owning pointer to the type already stored in the AST?
Also, I would like to keep my symbol table around for later compiler passes. Cooper & Torczon briefly mention directly inserting pointers to the appropriate SymbolTable in the AST node. Is that the common approach?
The lookup for names in records usually doesn't follow the bottom-up approach implemented using a parent pointer from scope to scope. (In fact, that simple datastructure may not be entirely applicable to scopes either; as soon as you introduce lexical closures, your scope relationships become more complicated.)
Although there are languages which will do implicit lookup from a structure to the containing structure's members, they're rare and experience shows that this form of name lookup is prone to difficulty, even though it occasionally seems convenient.
The most common pattern is that a structure type contains a list of members, each with its own type. That list of members is, in effect, a symbol table since in order to parse a member reference like r.a.b.c, you need to search for a in r's members, then b in r.a's members, and so on. That suggests that a structure type contain a symbol table of members (which might or might not be a pointer, depending on your design. Typically member lists of a structure are not shared, but in the case of OO subclass/superclass relationships, member lookup can be more complicated.)
I guess the point I'm trying to make here is that the structure of your symbol table depends a lot on the nature of your language. At its core, a symbol table contains a list of symbols organized in a way which makes it efficient to lookup a symbol by its name. The symbol table associates each symbol with some symbol data object, which might vary from symbol table type to symbol table type (for example using C++ generics) or might be consistent across all symbol tables. Often, symbol tables differ from simple hash tables (or associative containers) by the fact that the symbols also have some kind of linear ordering, used to produce a linear representation at compile time. Precise details will vary, but being able to iterate over the symbols in a consistent, well-defined order is often an important feature.
By the general principle of separation of concerns, a symbol table as described above should not also attempt to be a container of symbol tables. The symbol table can answer questions about the names it contains. Searching through multiple symbol tables (scope search, or whatever) is best done with a different object, which knows how to handle name lookup failure in some symbol table but doesn't need to understand the technical details of a single name lookup.
Whether you can keep persistent pointers or references to a symbol table depends entirely on your low-level design. If that's your wish, it's easily accomplished. I think it is pretty common, but I can't speak for the huge variety of language implementations out there.
Symbol tables do not always interrelate in simple ways which can easily be expressed as ownership. In that, they are similar to other internal objects floating around in a compiler. An AST Node might suddenly become a shared node in a graph rather than being a tree node, once you start to implement common-sub-expression optimisations. (And that's just one example.) As far as I know, most compilers of any complexity end up implementing some kind of garbage collection for internal objects, unless of course the compiler is written in a language with general garbage collection.
I want to declare
map<set<multiset<int>>,int> mymap;
but MSVC 2015 gives me this error:
error C2338: The C++ Standard doesn't provide a hash for this type.
How can I supply comparison operator? Probably this is what missing here?
As per request,
Most probably you were trying to create mymap like so:
unordered_map<set<multiset<int>>,int> mymap;
The key type for the unordered_map is set<multiset<int>> which does not define a hash function. But, it does define operator<.
So, the definition given in the post should be fine, but you probably were using an unordered_map.
P.S. Using set<multiset<int>> as a key type for a map doesn't feel right. set::operator< has O(n) time complexity. multiset::operator< is the same. But, if you are not worried about performance, it's fine.
I am confused with a project that I study for a course.
I have to build a tree-expression, I know how the algorithm works, but I have difficulties with setting up the nodes.
The instructor gave us this class: Expression Node
Where it has 2 other subclasses: Constant Node and Operator Node?
and in the "Expression Tree class": Where am I building the tree-expression? I have a Stack with this type : Expression Node
my question is: after I assign an operator or an constant, how can I push it to the Stack, since the types are different.
i am working with C++
thank you.
Apply polymorphism: Push pointers ( or references ) to your nodes.
Since your stack contains elements of type "ExpressionNode", it can accept all types that derive from it ( Constant and Operator).
If you have access to boost, boost::variant is what you are looking for.
See this, it is OO version of union.
header file
#include <boost/variant.hpp>
stack<boost::variant<int,char>> s;
s.push('+');
s.push(1);
In this explanation, the following variables are used:
A: Page address
B: Page name
C: Category Name
D: Variable. Value is 'A'
T: Template
V: Variable
Using MediaWiki, the syntax for using a link is [[C/A|B]]. This creates a link to page A, which is inside category C, with text B. The syntax for using a template inside another template with a variable as an argument is {{T|{{{V|#}}}}} This produces the result of template T with variable V. Suppose this result is exactly A. Now, combining these approaches, I expect the code [[C/{{T|{{{V|#}}}}}|B]] to produce the same link as the link syntax example. However, the result is:
[[C/A|B]]
E.g. exactly the code that needs to be evaluated. Note how the template does get evaluated correctly, but the link is not parsed. It seems like I need to 'reverse' the priority some way.
Side note: My approach does work with just variables. E.g. if variable D were to hold the value A, the code [[C/{{{D|#}}}|B]] does produce the correct link. MediaWiki documentation is surprisingly sparse on the subject.
Hint: Wikipedia itself has a number of link templates that can be used as examples, however these form a complex interwoven web from which it is hard to interpret the correct notation for this particular case.
Questions:
How do I properly call a template inside of this context?
What about using the template result for other parts of the link,
such as the text?
What if this is a linked image or other special link?
Other things:
Preferrably, the solution should involve the use of only a single template if this is possible. If a 'dummy' link template containing a simple [[{{{1}}}]] is required, is there a default MediaWiki template that can do this, reducing clutter?
Obviously the following type definition is cyclic:
type node = int * node;;
Error: The type abbreviation node is cyclic
My question is how comes the following one is not cyclic?
type tree = Node of int * tree;;
The second definition also refers to itself.
One way to look at it is that node is an abbreviation for a type, not a new type itself. So the compiler (or anybody who's interested) has to look inside to see what it's an abbreviation for. Once you look inside you start noticing things that make it difficult to analyze (e.g., that it's a recursive type and hence can require many unfoldings).
On the other hand, tree is a new type that's characterized by its constructors. (In this case, just the one constructor Node). So the compiler (or other interested party) doesn't need to look inside at all to determine what the type is. Once you see Node the type is determined. Even if you do look inside, you only need to look down one level. This allows recursion without causing any difficulties in analysis.
As a practical matter, recursive types of the first sort are often unintentional, and they lead to strange typings. The second sort are virtually impossible to create by mistake because of the little signposts (constructors) all along the way; in fact they're kind of like the lifeblood of the type system.