2010-08-28 15 views
8

Zrobiłem kilka testów używając próbki spirit mini_c. Niestety nie zachowuje pierwszeństwo operatora zgodnie z oczekiwaniami:Priorytet operatorów w impulsie :: duch?

int main() 
{ 
    return 3 > 10 || 3 > 1; 
} 

rozpoznawaną 0.

return (3 > 10) || (3 > 1); 

powrotów 1

Próbowałem przenieść definicję "||" i „& &” na samej górze w konstruktorze

template <typename Iterator> 
expression<Iterator>::expression(

ale to niczego nie zmienia. Jak to naprawić. Używam boosta 1.3.38.

+0

nigdy nie używałem Boost.Spirit, ale ja nie zobacz, jak wszystko, co ona definiuje, może mieć tutaj znaczenie. Nie masz nic oprócz prymitywów i nie możesz przeciążać wbudowanych operatorów. –

+0

Mam inne pytanie dotyczące tej próbki. Może ty też możesz w tym pomóc? http://stackoverflow.com/questions/3591533/implementing-not-in-boostspirit-mini-c –

Odpowiedz

7

Potwierdzony, jest to błąd w przykładzie mini_c związanym z priorytetem operatora. Wprowadziłem poprawkę do SVN, która będzie dostępna w Boost V1.45. Oto, co zmieniło się w mini_cb.hpp pliku nagłówka:

stary kod:

equality_expr = 
    relational_expr 
    >> *( ("==" > relational_expr  [op(op_eq)]) 
     | ("!=" > relational_expr  [op(op_neq)]) 
     ) 
    ; 

relational_expr = 
    logical_expr 
    >> *( ("<=" > logical_expr  [op(op_lte)]) 
     | ('<' > logical_expr   [op(op_lt)]) 
     | (">=" > logical_expr  [op(op_gte)]) 
     | ('>' > logical_expr   [op(op_gt)]) 
     ) 
    ; 

logical_expr = 
    additive_expr 
    >> *( ("&&" > additive_expr  [op(op_and)]) 
     | ("||" > additive_expr  [op(op_or)]) 
     ) 
    ; 

nowy kod:

equality_expr = 
    logical_expr 
    >> *( ("==" > logical_expr  [op(op_eq)]) 
     | ("!=" > logical_expr  [op(op_neq)]) 
     ) 
    ; 

logical_expr = 
    relational_expr 
    >> *( ("&&" > relational_expr  [op(op_and)]) 
     | ("||" > relational_expr  [op(op_or)]) 
     ) 
    ; 

relational_expr = 
    additive_expr 
    >> *( ("<=" > additive_expr  [op(op_lte)]) 
     | ('<' > additive_expr  [op(op_lt)]) 
     | (">=" > additive_expr  [op(op_gte)]) 
     | ('>' > additive_expr  [op(op_gt)]) 
     ) 
    ; 
+0

Wielkie dzięki. Próbowałem tego samego, ale zapomniałem zmodyfikować parametry wewnątrz definicji. –

+1

Witaj Hartmut. Dziś - 1 1/2 lat później dowiedziałem się, że kod nadal nie jest poprawny: "==" i "&&" muszą być ostatecznie ocenione - PO "==" i "! =", Nie wcześniej. –