Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: ollydbg on December 31, 2010, 06:58:34 am

Title: a bug in the expression solver (handling conditional preprocessor directive)
Post by: ollydbg on December 31, 2010, 06:58:34 am
the code has some bug, see below:

plugins\codecompletion\parser\expression.cpp

Code
long ExpressionNode::GetNodeTypePriority(ExpressionNodeType type)
{
    switch (type)
    {
    case LParenthesis:
    case RParenthesis:
        return 9;
    case Not:
        return 8;
    case Mod:
        return 7;
    case MultiPly:
    case Divide:
    case Power:
        return 6;
    case Plus:
    case Subtract:
        return 5;
    case LShift:
    case RShift:
        return 4;
    case BitwiseAnd:
    case BitwiseOr:
        return 3;
    case Equal:
    case Unequal:
    case GT:
    case LT:
    case GTOrEqual:
    case LTOrEqual:
        return 2;
    case And:
    case Or:
        return 1;
    default:
        return 0;
    }
}

The "And" and "Or" should have different precedence.

see:
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

BTW, I'm implementing some similar code (I think it was much simpler, in my quex parser tester)
see:
Yesterday, I have implement a quite simple expression parser by shunting yard algorithm combined with Quex lexer. it was very much like the yacc calculator in the demo folders.
The source code was:
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/expression_eval.cpp
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/expression_main.cpp

and the reference was:
http://en.literateprograms.org/Shunting_yard_algorithm_%28C%29
Title: Re: a bug in the expression solver (handling conditional preprocessor directive)
Post by: ollydbg on January 05, 2011, 02:01:50 am
seems no one was interested on this issue.... :(

Here is the test code to produce this issue:

Code
#if 1 || 1 && 0
int main();
#endif

Now, the cc will skip the "main" function.
But the conditional expression value is "true".
Title: Re: a bug in the expression solver (handling conditional preprocessor directive)
Post by: MortenMacFly on January 05, 2011, 06:57:18 am
seems no one was interested on this issue.... :(
I guess it's Loaden who should give a statement. It seems you are right, obviously.
Title: Re: a bug in the expression solver (handling conditional preprocessor directive)
Post by: Loaden on February 11, 2011, 08:21:37 am
seems no one was interested on this issue.... :(
I guess it's Loaden who should give a statement. It seems you are right, obviously.
Fixed in rev6983.
Title: Re: a bug in the expression solver (handling conditional preprocessor directive)
Post by: ollydbg on February 11, 2011, 08:29:06 am
Nice work! loaden
I'm currently testing a same shunting yard algorithm(directly infix expression, avoid the postfix generation).
see:
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/ConstExpression.h
and
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/ConstExpression.cpp

I think you don't need to generate a postfix, then calculate the postfix again.
I think you can avoid the "generate a postfix" stage, and calculate the value directly. you can see my code, it will be more faster.