As a side note, the module can still be improved with a series of fixup
optimizations which include pvar handling (token should include an un-evaluated
pv_spec_p struct) in order to avoid expression parsing at runtime. I should put
this on the TODO list :)
A couple of quick ideas related to the pull request:
* Reverse Polish notation is HIDEOUS. Humans hate it and parsers love it. I
have some doubts about the module exposing a function that takes non-intuitive
inputs. Building code on top of existing code (i.e. enhancing math_eval with
maintaining proper operator priorities), and hiding the internal logic would be
a better approach.
* it looks like parsing will fail with "math_rpn("2 1 1 +*", "$var(res)")"
(maybe I'm wrong!)
* please use tabs for code indenting! (you can configure your editor afterwards
for 2-char-wide tabs)
* try to be consistent with existing code. Not "for ( i.." but "for (i...". Not
"if(..." but "if (...")
To better understand reason 1), I give you the following exercise:
Convert "1 + exp(10, 5) - 2 * 2" in RPN. How long did it take you? :)
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/144#issuecomment-29552893_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
