m_nPosExpr incorrect value after Eval() or GetExprVar() about muparserx HOT 5 CLOSED

The current SVN development snapshot does not contain a method for retrieving 
the rpn. I see the rpn more as an implementation detail not meant for public 
access. In case of expression optimization there is no guarantee that tokens 
present in the rpn represent an actual expression token. They could also be the 
result of merging several tokens into a new one. Why do you need access to the 
rpn?

My apologies... I just checked our code vs. the latest SVN, and found out that 
we must have changed the library source to access the RPN.

Looks like we added:
const RPN* GetRPN() const {return &m_rpn;} in mpparserbase.h

Accessing the RPN is very useful to us. For instance, after we Eval() or 
GetExprVar(), we use the RPN to get all the constants / values etc found by the 
parser and their values. In this way we can use it as a parser too, not only to 
evaluate the expressions. In one instance we us the RPN to pre-process the 
expressions before Eval() (e.g. we use GetExprVar()) and then we change the 
expression and call Eval() after that. That's how we discovered the m_nPosExpr 
issue I mentioned above.

Is there a design reason why m_nPosExpr is shared across all tokens with same 
identity or just didn't come up because m_nPosExpr it's never really used by 
the engine? thank you

Thanks for the additional information. The expression position is really only 
ever used when emitting parsing erros. In those cases the parsing stops so 
there is no chance for invalidating it later on. You can change this behaviour 
easily by modifying two lines in TokenReader::IsVarOrConstTok. Just replace 
both occurences of

a_Tok = item->second 

with 

a_Tok = ptr_tok_type(item->second->Clone());

I added those lines to the current SVN head revision and I don't see an 
immediate problem with cloning the tokens instead of using the original one. 

Thank you very much, I will change the code as suggested and test it. I will 
report back if we find any issues. thanks again for your help and for a 
FANTASTIC library.

Closed, fixed in SVN head revision