Польские правила обозначений для добавления "в" и оператор с логикой - PullRequest
Новая
       9

Польские правила обозначений для добавления "в" и оператор с логикой

1 голос
/ 24 августа 2011

у меня есть это выражение 

ratecode in ('EURV','EURA','EURB','EURO','CHUPin*+-da~') && ( sourcecode ~in ('FMFC','FM') || block == 'yes')

теперь, которые являются правилами rpn 

    /// 2.  Repeat until we reach end of infix expression 
    ///     I.  Get token (operand or operator); skip white spaces 
    ///     II. If token is: 
    ///         a.  Left parenthesis: Push it into stack 
    ///         b.  Right parenthesis: Keep popping from the stack and appending to 
    ///             RPN string until we reach the left parenthesis.
    ///             If stack becomes empty and we didn't reach the left parenthesis 
    ///             then break out with error "Unbalanced parenthesis" 
    ///         c.  Operator: If stack is empty or operator has a higher precedence than 
    ///             the top of the stack then push operator into stack. 
    ///             Else if operator has lower precedence then we keep popping and 
    ///             appending to RPN string, this is repeated until operator in stack 
    ///             has lower precedence than the current operator. 
    ///         d.  An operand: we simply append it to RPN string. 
    ///     III.    When the infix expression is finished, we start popping off the stack and 
    ///             appending to RPN string till stack becomes empty.

я добавил &&, ||, ~, in,

теперь, какэто должно изменить правила RPN?

*** Обновление

Это моя таблица операторов 

Operator Priority
"+"      0
"-"      0
"&&"     0
"||"     0 

"/"      1
"*"      1
"=="     1
"("      1

"~"      3
"in"     3
")"      3

1 Ответ

2 голосов
/ 24 августа 2011

Правила не меняются для этих дополнительных операторов. Вам просто нужно назначить каждому оператору правильный приоритет. Например, && обычно имеет более низкий приоритет, чем большинство других операторов, а || имеет более низкий приоритет, чем &&.

...