How to build a recursive descent parser - c++

Question

I've been working on a recursive descent parser for a simple calculator. When something is declared it is either declared as an int or a float. Currently I am saving the strings into two different vectors one for int and one for float. At this point I don't care what the numbers associated are I simply care that the string is declared before it is used.
My issue is that I have to be able to output a warning message if an int and float are being used in an operation such as float + int.
So if expression is term+expression or term-expression or term. In recursive descent how could I possibly check to see if an int is being used in an operation with a float. Sorry if the explanation is not clear. I'm finding it a bit difficult to explain. I have add some code if necessarily, I just didn't want to flood the question with code.
edit:
there is still a bunch of code missing, I figured just grab the important part, but I can upload the entire thing if need-be. I see some people didn't understand what the main question was. One of the requirements is "When integer and float values are mixed in +, -, * and /, the integer is converted to a float. print a message indicating the line number and that a conversion would be required." At the moment the program reads from a file. if you say "int x;" the program will currently save x in the int vector, then when you say something such as x=5; it will acknowledge that x has been declared and the assignment will pass. my issue is where if you say int x; float y; int z; x=5; y=7.5; z=x+y; how would I be able to check for that as at the moment my program only saves the type for variables and not the value. Essentially I'm wondering if it would be possible to do something like scan the completed parse as if it was a string or some other method of finding out of an operation using int and float is being done.
the lex scanner was created with flex
class Token {
Tokentype type;
string value;
int linenum;
public:
Token(Tokentype t, string v="") {
type = t;
value = v;
}
Tokentype getType() { return type; }
string getValue() { return value; }
int getLinenum() { return linenum; }
};
vector<string> int_list;
vector<string> float_list;
class PTree {
PTreeNodetype type;
PTree *left;
PTree *right;
public:
PTree(PTreeNodetype t, PTree *l=0, PTree *r=0) {
type = t;
left = l;
right = r;
}
PTreeNodetype getType(){ return type;}
};
// expr ::= term PLUS expr | term MINUS expr | term
PTree *
Expr() {
PTree *term = Term();
Token *t;
if (!term)
return 0;
t = getToken();
if (t == NULL){
delete t;
return 0;
}
if(t->getType() != T_SC)
{
if (t->getType() == T_RPAREN){
pushbacktoken(t);
return new PTree(EXPR, term);
}
if (t->getType() != T_PLUS && t->getType() != T_MINUS)
{
cout << t->getLinenum() << ":" << "Error: expected + or -" << endl;
pushbacktoken(t);
delete t;
return 0;
}
delete t;
PTree *expr = Expr();
if (!expr)
return 0;
return new PTree(EXPR, term, expr);
}
pushbacktoken(t);
return new PTree(EXPR, term);
}

Answer 1

I think you need to explain the structure of your code a little more.
In an interpreter like you are talking about normally there are three things going on:
A lexer/scanner is generating a token stream
A parser is taking the token and building semantic objects
A interpreter is consuming the semantic object tree and executing them
Stage 1 doesn't need to care that you are adding an int and a float. Stage 2 can populate an a warning field in your semantic object/struct that interpreter will print when it sees populated or the interpreter can recognize this warning condition itself.
To provide you any more detail or use more specific terminology we would need to see how you are representing operations.

Answer 2

Two options that I see, depending on what you are doing.
First. Don't worry about it while you are building the parse tree. Later, when you walk the tree, you can easily check this and throw an error.
Second. Use different rules for int and float. So you would have a rule for adding two ints and a rule for adding two floats. This also means you wouldn't have a number rule, which I am guessing you do, that mixes both ints and floats.
I definitely recommend the first way.

Answer 3

Calculators don't traditionally "declare" things, so its unclear what your calcualtor knows when it is parsing an expression.
If I assume that you "declare i int, r real" before the expression "i*r" is parsed, you seem to have several questions:
a) how do you know as you parse whether i and r have been declared? The technical answer is that during parsing you don't have to know; you can parse, build up a tree, and do such checking later. On a practical level, people often weave symbol lookups into the parsing process (this gets messier as your language gets bigger, so it isn't recommended for other than calculators [you'll discover that most C compilers do this, adding to their messiness]). The answer is easy: keep a list of defined symbol strings around, and when you encounter an identifier, look to see if its in the list.
b) how do you know the type of "i" or "r"? Easy. Associate with the symbol string, the declared type, e.g., , . Associated sets of declarations are commonly called symbol tables.
c) how do you know if operations are operating on the same ("the right") kind of values? Here you need to associate with every operand, its "type". Constants have obvious type; 1.0 is real, 1 is integer. "i" is integer, and your parser knows it because it looked up the type (above); similarly for "r". Each expression term then has to check its operands for compatibility. What might not be obvious is that each expression has to compute it result type, e.g., 3 * 4.0 is real, not integer. So in parallel to the parsing machinery, you need to propagate a type.

Answer 4

+1 to voidlogic. His answer should give you a basic idea of how to build a recursive descent parser. If you are having trouble with a certain part of yours, it would be nice to get a little more detail about how you are structuring your code.
If you would like to see an example of one, look at this implementation.

Answer 5

Here is a book that may help:
Compilers: Principles, Techniques and Tools ("Dragon Book") by A. Aho, M. Lam and R. Sethi.
Here is a set of tools that may help you:
GNU flex
GNU bison