Weird time results when compiling with clang v6 and gcc 7+:

Expression 41 of 440: "((cos(cos(tan(pi)))+a)/a)"; Progress: #####
[01] ExprTk               (    8.000 ns,       1.491183914425581625,      13.683879358191861186)
[02] ExprTkFloat          (    9.000 ns,       1.491183876991271973,      13.683879375457763672)
[03] FParser 4.5          (   15.900 ns,       1.491183914425581625,      13.683879358191861186)
[04] muparser 2.2.4       (36478.800 ns,       1.491183914425581625,      13.683879358191861186)
[05] muparser 2.2.4 (omp) (38305.600 ns,       1.491183914425581625,      13.683879358191861186)

CPU details:

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              20
On-line CPU(s) list: 0-19
Thread(s) per core:  2
Core(s) per socket:  10
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               85
Model name:          Intel(R) Xeon(R) W-2155 CPU @ 3.30GHz
Stepping:            4
CPU MHz:             1869.970
CPU max MHz:         4500.0000
CPU min MHz:         1200.0000
BogoMIPS:            6600.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            1024K
L3 cache:            14080K
NUMA node0 CPU(s):   0-19

 void  Error(EErrorCodes a_iErrc, 
                int a_iPos = (int)mu::string_type::npos, // <--- This line doesn't look safe
                const string_type &a_strTok = string_type() ) const;

std::string::npos is size_type, it's a 64-bit value in 64-bit mode. The highlighted line truncates it to 32-bit signed int. It's probably not causing any actual runtime errors, but looks bad and causes a host of compiler warnings (remember, it's in .h file so a warning is emitted for every .cpp that includes it).

What steps will reproduce the problem?
1. Set a mu::Parser's expression to one of the following:
1000*Part_0
1000.2*Part_0
0000.2*Part_0

2. Call mu::Parser::GetUsedVar()

3. 1000, 1000, and 0000 will be returned as variables for the cases listed 
above.

What is the expected output? What do you see instead?
I only expect to see Part_0 as a used variable.

-For the first case, muParser does not throw an exception, but it does say that 
1000 is a variable. I should say that it is a value.

-For the second case (1000.2*Part_0): I get the exception message: "Unexpected 
token ".2*Part_0*Part_1 " found at position 4."

-For the last case (000.2*Part_0): I get the exception message "Unexpected 
token ".2*Part_0*Part_1 " found at position 4."

muParser parses the expressions correctlywhen I use 999 and 999.2 in the 
expressions (instead of 1000 and 1000.2).

What version of the product are you using? On what operating system?
muParser 2.2.3.  I tried this with 2.2.4 taken from the svn repo and it also 
occurred. I'm on OSX version 10.7.5, and I am building muParser with the 
provided configure and make scripts. For my code, I'm compiling it with Apple 
LLVM 4.2 with C++11 support and linking to the libc++ std lib. I compiled 
muParser so that it also uses the same compiler settings as my code.

Please provide any additional information below.
I set some breakpoints in the muParser code to try and track it down. I tried 
to figure it out myself, but it's taking me a long time. Here's what I've got 
so far, and hopefully someone who knows the code better can take it from here:

In ParserBase::CreateRPN(), the line of code on line 1199:
opt = m_pTokenReader->ReadNextToken();

It returns an opt with the following state:
(mu::ParserBase::token_type) opt = {
  m_iCode = cmVAR
  m_iType = tpDBL
  m_pTok = 0x0000000100c038b8
  m_iIdx = -1
  m_strTok = "1000"
  m_strVal = ""
  m_fVal = 6.95322297490987e-310
  m_pCallback = {
    __ptr_ = 0x0000000000000000
  }
}

I believe that m_iCode should NOT be set to cmVAR, and should instead be set to 
cmVAL. I tried to dig deeper, but I didn't get very far.

Thanks for looking at this.

Original issue reported on code.google.com by [email protected] on 22 Aug 2013 at 11:40

I am trying to compile a Visual Studio project that requires symbolic differentiation in C++ wherein the parser is instantiated with a string expression. I have tried compiling muParser as either a static or shared library with and without the fix to the muParserFixes.h header file in #105 in conjunction with the Ev3 library compiled to either a static or shared library. The proposed fix does allow me to compile the muParser code and evaluate string expressions in the mu:: namespace, but does not aid in the effort to compile the Ev3 code with similar attempts to compile to either static or shared libraries.

What am I missing?

[Error messages when attempting to compile with Ev3 library.]

[Successful evaluation in mu:: namespace for muParser.]

Here is my Visual Studio info...

Microsoft Visual Studio Community 2022 Version 17.2.4 VisualStudio.17.Release/17.2.4+32602.215 Microsoft .NET Framework Version 4.8.04084

Installed Version: Community

Visual C++ 2022 00482-90000-00000-AA747 Microsoft Visual C++ 2022

ASP.NET and Web Tools 2019 17.2.392.13739 ASP.NET and Web Tools 2019

Azure App Service Tools v3.0.0 17.2.392.13739 Azure App Service Tools v3.0.0

C# Tools 4.2.0-4.22281.5+8d3180e5f00d42f0f0295165f756f368f0cbfa44 C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools 1.10 Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Cookiecutter 17.0.22089.1 Provides tools for finding, instantiating and customizing templates in cookiecutter format.

Linux Core Dump Debugging 1.0.9.32408 Enables debugging of Linux core dumps.

Microsoft JVM Debugger 1.0 Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

NuGet Package Manager 6.2.1 NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Python - Django support 17.0.22089.1 Provides templates and integration for the Django web framework.

Python - Profiling support 17.0.22089.1 Profiling support for Python projects.

Python - VC Project Support 17.0.21344.1 Provides support for launching C++ projects with Python debugging enabled.

Python with Pylance 17.0.22089.1 Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers.

Test Adapter for Boost.Test 1.0 Enables Visual Studio's testing tools with unit tests written for Boost.Test. The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test 1.0 Enables Visual Studio's testing tools with unit tests written for Google Test. The use terms and Third Party Notices are available in the extension installation directory.

TypeScript Tools 17.0.10418.2001 TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 4.2.0-4.22281.5+8d3180e5f00d42f0f0295165f756f368f0cbfa44 Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual C++ for Linux Development 1.0.9.32408 Visual C++ for Linux Development

Visual Studio IntelliCode 2.2 AI-assisted development for Visual Studio.

Building an application that depends on both muparser and Qt6 fails on Windows

the muparser library was built without UNICODE support while the Qt6 define UNICODE for compilation. the application imports the unicode (string_type->wstring) because of the compilation definitions imposed by Qt6, and links with mupasrer which was built without unicde (string_type->string), That result to a lot of errors of undefined reference.

auto_ptr should be replaced with unique_ptr;

Can we make these changes

--- include/muParserBase.h.orig	2018-09-05 20:00:43 UTC
+++ include/muParserBase.h
@@ -288,7 +288,7 @@ friend class ParserTokenReader; (private)
     mutable stringbuf_type  m_vStringBuf; ///< String buffer, used for storing string function arguments
     stringbuf_type  m_vStringVarBuf;
 
-    std::auto_ptr<token_reader_type> m_pTokenReader; ///< Managed pointer to the token reader object.
+    std::unique_ptr<token_reader_type> m_pTokenReader; ///< Managed pointer to the token reader object.
 
     funmap_type  m_FunDef;         ///< Map of function names and pointers.
     funmap_type  m_PostOprtDef;    ///< Postfix operator callbacks

--- include/muParserToken.h.orig	2018-09-05 20:01:07 UTC
+++ include/muParserToken.h
@@ -69,7 +69,7 @@ namespace mu
       TString m_strTok;   ///< Token string
       TString m_strVal;   ///< Value for string variables
       value_type m_fVal;  ///< the value 
-      std::auto_ptr<ParserCallback> m_pCallback;
+      std::unique_ptr<ParserCallback> m_pCallback;
 
   public:

--- src/muParserTest.cpp.orig	2018-09-05 20:00:19 UTC
+++ src/muParserTest.cpp
@@ -1258,7 +1258,7 @@ namespace mu
 
       try
       {
-        std::auto_ptr<Parser> p1;
+        std::unique_ptr<Parser> p1;
         Parser  p2, p3;   // three parser objects
                           // they will be used for testing copy and assignment operators
         // p1 is a pointer since i'm going to delete it in order to test if

--- src/muParserTokenReader.cpp.orig	2018-09-05 19:59:55 UTC
+++ src/muParserTokenReader.cpp
@@ -147,7 +147,7 @@ namespace mu
   */
   ParserTokenReader* ParserTokenReader::Clone(ParserBase *a_pParent) const
   {
-    std::auto_ptr<ParserTokenReader> ptr(new ParserTokenReader(*this));
+    std::unique_ptr<ParserTokenReader> ptr(new ParserTokenReader(*this));
     ptr->SetParent(a_pParent);
     return ptr.release();
   }

Fixes #29. At least libc++ started to remove std::auto_ptr from their implementation of the C++ standard library. In particular, Apple's clang-9.1.0 which uses libc++ by default refuses the existence of std::auto_ptr if compiled with std=c++17 and we are running into this issue in dealii/dealii#6125. Hence, it seems to be time to replace it by std::unique_ptr.

• LIB_SUFFIX is unused now
• MUPARSER_DLL controls the inclusion of the C interface and does not depend on BUILD_SHARED_LIBS
• MUPARSERLIB_EXPORTS should be only defined to export symbols for shared builds else we define MUPARSER_STATIC (TODO: export C++ symbols)
• no SHARED, DEBUG (only _DEBUG) definitions
• example2.c can be compiled now that MUPARSER_DLL is defined
• removed add_test as samples are blocking (TODO: add C&C++ tests)

Hello,

OpenTURNS, an open-source lib dedicated to the treatment of uncertainties, use 
MuParser for some study. By the way, thanks for your work! 
So, for some large study we would like to speed up a little bit the 
computation. So we would like to enable OpenMP inside muParser. 
We know that using a just in time parser would be much faster, but it would 
involve much more work. OpenMP in muParser is the first easy step to speed up 
our code.

I tried to enable OpenMP support on Linux (using autoconf). 
But using the revision 10 of http://muparser.googlecode.com/svn/trunk source, 
if I uncomment the line "#define MUP_USE_OPENMP" it does not enable OpenMP 
compilation  switch and the compilation fails.

I made a patch and the compilation using autoconf runs fine now.
The patch add an --enable-openmp feature (openmp is disabled by default).

  ./configure --enable-openmp
  make
  ...

My system is running on ubuntu 12.04 64bits.

Do you think the patch is good enough? I do not know if it will break 
compilation on other systems (windows ...) as I know only autoconf and cmake.
Could you consider merging this patch to muParser source code?

Beset regards,
Mathieu Souchaud

Original issue reported on code.google.com by [email protected] on 21 Dec 2013 at 5:41

Attachments:

• muparser_r10-openmp.patch

I came across a compiler warning regarding sprintf. On macOS 13, the function was deprecated in favor of vsprintf. This deprecation has affected multiple code bases, including VkFFT and GROMACS. Hopefully you can fix it early, as additional clients may face the compiler warning.

/Users/philipturner/Documents/GROMACS/gromacs/src/external/muparser/src/muParserDLL.cpp:201:3: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
                sprintf(s_tmpOutBuf, "%s", p->GetVersion().c_str());
                ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
/Users/philipturner/Documents/GROMACS/gromacs/src/external/muparser/src/muParserDLL.cpp:598:3: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
                sprintf(s_tmpOutBuf, "%s", p->GetExpr().c_str());
                ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
/Users/philipturner/Documents/GROMACS/gromacs/src/external/muparser/src/muParserDLL.cpp:935:2: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
        sprintf(s_tmpOutBuf, "%s", pMsg);
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
/Users/philipturner/Documents/GROMACS/gromacs/src/external/muparser/src/muParserDLL.cpp:953:2: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
        sprintf(s_tmpOutBuf, "%s", pToken);
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))

On our software I upgraded muParser to 2.3.2 and now have issues with a testcase, where an expression of size 9488 is too long due to the new 5000 characters limit. The part which generates the long expression is not from me, it is a complex 3D tensor rotation formula.

Is there a chance to exceed the 5000 limit or do we have to stick to the 2.2.6 version "forever"? Is there a build time variable I can change? Thanks!