beltoforion / muparserx

A C++ Library for Parsing Expressions with Strings, Complex Numbers, Vectors, Matrices and more.
http://beltoforion.de/en/muparserx
BSD 2-Clause "Simplified" License
135 stars 60 forks source link

Add a generic Get to Value class #38

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Value class has functions with different names for returning values of 
different types which is awkward to use from generic code. I suggest adding a 
generic Get function which uses a correct existing function to return a value 
based on the functions template parameter. Something like:

template <class T> T Get(const T& given_value);

where T decides which existing function to call:

template<class T>
typename std::enable_if<
  std::is_integral<T>::value,
  T
>::type Get(const T& given_value) {
  return this->GetInteger(given_value);
}

template<class T>
typename std::enable_if<
  std::is_floating_point<T>::value,
  T
>::type Get(const T& given_value) {
  return this->GetFloat(given_value);
}

etc.

Original issue reported on code.google.com by ilja.j.h...@nasa.gov on 14 Jul 2014 at 5:58

GoogleCodeExporter commented 9 years ago
Sorry but no matter what you do muparserx cannot give you the type information 
you need at compile time. Strictly spoken the return type of muparser is Value. 
In most cases you can't process the value properly without first checking its 
type. You could also get a string or a matrix as the return value (wrapped in a 
Value). The return type is determined at runtime. Templates make their 
distinction at compile time. I don't see how this will fit together very well. 
A get function that is bound to fail at runtime when fed with the incorrect 
type doesn't seem to be of much use either.

I'm leaving the issue open for the moment but i don't see this as a defect. 
This is an inherent part of the design. 

Original comment by ib...@gmx.info on 14 Jul 2014 at 9:23

GoogleCodeExporter commented 9 years ago
In my case the return value is a specific type, otherwise it is an error, and 
it would be convenient if e.g. a Get<int> would do all the error checking and 
if ok return the value of .GetInteger() and throw otherwise, for example. It 
would be even better if the parser knew what type I want to be returned from 
the expression, and throw if the expression doesn't match, but I guess that 
isn't supported.

Original comment by ilja.j.h...@nasa.gov on 15 Jul 2014 at 1:46

GoogleCodeExporter commented 9 years ago
Closed since it's more of a feature request.

Original comment by ib...@gmx.info on 23 Nov 2014 at 11:18