example2 extended to work with UNICODE character set
Applied patch from Issue 9
muChar_t in muParserDLL.h was not set properly when UNICODE was used
muparser.dll did not build on UNICODE systems
Rev 2.2.4: 02.10.2014
explicit positive sign allowed
Fix for Issue 6 (https://code.google.com/p/muparser/issues/detail?id=6)
String constants did not work properly. Using more than a single one
Project Files for VS2008 and VS2010 removed from the repository
Fix for Issue 4 (https://code.google.com/p/muparser/issues/detail?id=4)
Fix for VS2013 64 bit build option
return type of ParserError::GetPos changed to int
OpenMP support enabled in the VS2013 project files and precompiled windows DLL's
Bulkmode did not evaluate properly if "=" and "," operator was used in the expression
Rev 2.2.3: 22.12.2012
build files for msvc2005, borland and watcom compiler removed
Bugfix for Intel Compilers added: The power operator did not work properly
with Intel C++ composer XE 2011.
Issue 3509860: Callbacks of functions with string parameters called twice
Issue 3570423: example1 shows slot number in hexadecimal
Fixes for compiling with the "MUP_MATH_EXCEPTIONS" macro definition:
division by zero in constant expressions was reported with the code "ec_GENERIC"
instead of "ecDIV_BY_ZERO"
throwing of "ecDOMAIN_ERROR" added to sqrt and log functions
Rev 2.2.2: 18.02.2012
Optimizer did'nt work properly for division
Rev 2.2.1: 22.01.2012
Optimizer bug in 64 bit systems fixed
Rev 2.2.0: 22.01.2012
Optimizer rewritten and improved. In general: more optimizations are
now applied to the bytecode. The downside is that callback Functions
can no longer be flagged as non-optimizable. (The flag is still present
but ignored) This is necessary since the optimizer had to call the
functions in order to precalculate the result (see Bugfixes). These calls
posed a problems for callback functions with side effects and if-then-else
clauses in general since they undermined the shortcut evaluation prinziple.
Infix operators where not properly detected in the presence of a constant
name starting with an underscore which is a valid character for infix
operators too (i.e. "-_pi").
Issue 3463353: Callback functions are called twice during the first call to eval.
This is a service release incorporating minor bugfixes.
Function atan2 added.
Issue 3438380: Changed behaviour of tellg with GCC >4.6 led to failures
in value detection callbacks.
Issue 3438715: only "double" is a valid MUP_BASETYPE
MUP_BASETYPE can now be any of:
Previousely only floating point types were allowed.
Using "int" is still not allowed!
Custom value recognotion callbacks added with AddValIdent had lower
priority than built in ones. Consequently hex value recognition
using IsHexVal would fail since the built in IsVal would read the "0"
from the hex prefix "0x".
Rev 2.0.0: 04.09.2011
This release introduces a new version numbering scheme in order to make future changes in the ABI
apparent to users of the library. The number is now based on the SONAME property as used by GNU/Linux.
Beginning with this version all version numbers will be SONAME compliant.
Project files for MSVC2010 added.
Bytecode parsing engine cleaned up and rewritten.
Retrieving all results of expressions made up of comma separate subexpressions is now possible with a new Eval overload.
Callback functions with fixed number of arguments can now have up to 10 Parameters (previous limit was 5).
new intrinsic binary operators: "&&", "||" (logical and, or)
A new bulkmode allows submitting large arrays as variables to compute large
numbers of expressions with a single call. This can drastically improve
parsing performance when interfacing the library from managed languages like
C#. (It doesn't bring any performance benefit for C++ users though...)
Project files for MSVC2003 removed
intrinsic "and", "or" and "xor" operators have been removed. I'd like to let
users the freedom of defining them on their own versions (either as logical or bitwise
Implementation for complex numbers removed. This was merely a hack. If you
need complex numbers try muParserX which provides native support for them.
User defined operators could collide with built in operators that entirely
contained their identifier. i.e. user defined "&" would not work with the built
in "&&" operator since the user defined operator was detected with a higher
priority resulting in a syntax error.
Detection of unknown variables did not work properly in case a postfix operator
was defined which was part of the undefined variable.
i.e. If a postfix operator "m" was defined expressions like "multi*1.0" did
not detect "multi" as an undefined variable.
Postfix operators sharing the first few characters were causing bogus parsing exception.