On 24/04/2024 17:06, Bonita Montero wrote:
> Am 24.04.2024 um 13:23 schrieb David Brown:
>
>> That may be true - but I am entirely confident that you don't know it
>> is true.  You live in a little world where the only compiler is MSVC++
>> - you know nothing about the hundred other C++ compilers out there.
>> (I know more of them than you - and more importantly, I know my
>> knowledge is limited.)
>
> Any C++ compiler supports that since this is very common

That is clearly wrong. I am reasonably confident that my ancient copy
of a Microtek C++ compiler for the 68k supported type-punning in
practice (not by design, but simply because it did little in the way of
optimisation) - that does not imply that the compiler was very common.

What you are trying to say is that the most common C++ compilers support
it. I believe that is true, but I am not sure if they all /document/
that they support it - and if they don't document it as a guaranteed
feature, you are relying on luck. Can you point to where MSVC++
documents that type-punning unions are supported in C++?

> and you
> coudln't port a lot of code to compilers who wouldn't understand
> that. I've no problem using a union since this feature is required
> for any compiler to be conformant with a lot of software.

It is certainly the case that a large proportion of code is
non-portable, and uses extensions or platform-specific features. Mostly
it is for good reason - you are using Linux system calls, or Windows API
functions, or need MSVC "cdecl" or gcc "__attribute__" for some purpose.
That's fine.

What is /not/ fine, in my book, is /pointless/ non-portability.

I think it is quite uncommon to do type-punning using unions - type
punning is very rarely needed, no matter how it is done. And even if
some lazy or ignorant programmers do so, there is no good reason for
/you/ to do it or recommend it. You are no longer ignorant about the
issue - you now know it is non-portable. And surely you are not
suggesting that it is a good thing to be lazy rather than using
well-defined code?

On 24/04/2024 17:07, Bonita Montero wrote:
> Am 24.04.2024 um 13:14 schrieb David Brown:
>
>> As far as I know, the standards do not define the behaviour of casting
>> between function pointers and void pointers (or any object pointers).
>> The C standards are clear about the matter - it is not defined
>> behaviour.  But I don't know the C++ standards well enough to say.
>
> There's for sure no compiler which doesn't support that.
>

Incorrect.

On the AVR (which is supported by gcc), code pointers can have different
sizes from data pointers. The same goes for the msp430, depending on
the memory model you use. The same goes for DOS compilers - if you have
a memory model with 16-bit data pointers and 32-bit code pointers, they
are not interchangeable.

The C and C++ standards don't restrict this kind of thing just to be
awkward - they do so to make it clear that such mixing may be
non-portable, and is completely unnecessary in coding.

Am 24.04.2024 um 17:59 schrieb David Brown:

> That is clearly wrong.  I am reasonably confident that my ancient
> copy of a Microtek C++ compiler for the 68k supported type-punning in
> practice (not by design, but simply because it did little in the way of
> optimisation) - that does not imply that the compiler was very common.

It's a common pattern for decades and because of that any compiler does
support that.

Rest unread

Am 24.04.2024 um 18:02 schrieb David Brown:

> On the AVR (which is supported by gcc), code pointers can have different
> sizes from data pointers. ...
No one aliases code through a union.

On 24/04/2024 19:36, Bonita Montero wrote:
> Am 24.04.2024 um 18:02 schrieb David Brown:
>
>> On the AVR (which is supported by gcc), code pointers can have
>> different sizes from data pointers. ...
> No one aliases code through a union.
>

What are you talking about?

The point here was that function pointers and object pointers do not
have standards-defined conversion behaviour (that fact is indisputable).
You claimed that all compilers support it anyway - I gave a few
examples where it could be problematic. (As usual, your idea of "all
compilers" is that only modern MSVC is important, with perhaps a brief
nod to the existence of gcc and clang, only on x86-64.)

Discussions with you are always difficult - you haven't any idea what
you are talking about, beyond the world of x86-64 programming with MSVC
on Windows. But that never stops you making wild claims and
generalisations, then changing the goalposts whenever challenged.

So if you have something useful to say, or questions to ask, go ahead.
If you just want to spout nonsense about what "all compilers" do, and
recommend pointlessly non-portable code instead of easy, portable and
well-defined alternatives, please don't bother.

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 23.04.2024 14:44 Bonita Montero kirjutas:
>
>> Am 23.04.2024 um 13:31 schrieb Paavo Helde:
>>
>>> There is an old third-party library where some function pointers
>>> are casted to another type, then back to the original type before
>>> use.
>>> C++ standard says this is kosher, and there have never been any
>>> problems with actual behavior. Alas, different versions and compile
>>> modes of g++ still produce warnings. ...
>>
>> That's because of the danger that someone calls the function-pointer
>> to which you cast. Maybe you can cast through a void-pointer to sup-
>> press this warning. But for me casting to a function pointer of a
>> differnt type doesn't make sense at at..
>> I think you confront yourself to uncertainties which actually never
>> happen.
>
> The function pointers are cast to a single type so that they can be
> stored in a common lookup array. I could use a union there, but this
> would mean additional work with no real benefit, as the hypothetical
> "someone" could just as easily mess up the unions than the casting.

That depends on how the code is written. The code can be written
so that making a mistake with the unions is both difficult and
unlikely. To be continued downthread...

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 24.04.2024 10:36 Bonita Montero kirjutas:
>
>> Am 23.04.2024 um 20:33 schrieb Paavo Helde:
>>
>>> The function pointers are cast to a single type so that they can be
>>> stored in a common lookup array. ...
>>
>> Then you'd need additional information to distinguish the different
>> types. If you have sth. like that you could take a variant<>.
>
> Right, the varying part is the number of arguments, which is
> explicitly declared and stored in the array as well (n_pars below). If
> you are interested, the current code (no warnings any more here,
> thanks to Markus!) looks like below. Not sure if changing to a variant
> or void(*)() would make the code better, looks like then I would need
> to add extra casts to all the lines in the table which currently do
> not need any casts.
>
> #include <math.h>
>
> typedef double (*Func)(double);
>
> struct formu_item {
> const char *name;
> Func f; /* pointer to function*/
> int n_pars; /* number of parameters (0, 1, 2 or 3) */
> int varying; /* Does the result of the function vary
> even when the parameters stay the same?
> varying=1 for e.g. random-number generators. */
> };
>
> typedef void (*VoidFunc)();
> typedef double (*DoubleFunc_0_args)();
> typedef double (*DoubleFunc_2_args)(double, double);
>
> Func FuncCast2(DoubleFunc_2_args fp) {
> return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
> }
> Func FuncCast0(DoubleFunc_0_args fp) {
> return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
> }
> double pi() {
> return 3.1415926535897932384626433832795029;
> }
>
> static const formu_item ftable_static[TABLESIZE]=
> {
> {"exp", exp,1,0},
> {"ln", log,1,0},
> {"sin", sin,1,0},
> {"cos", cos,1,0},
> {"tan", tan,1,0},
> {"asin", asin,1,0},
> {"acos", acos,1,0},
> {"atan", atan,1,0},
> {"atan2", FuncCast2(atan2),2,0},
> {"abs", fabs,1,0},
> {"sqrt", sqrt,1,0},
> {"pi", FuncCast0(pi),0,0},
> //...
> }

The code below uses no casting, and encapsulates the constructors
for 'formu_item's so that the functions are guaranteed to be in
sync with the discriminating member of the struct. The names and
types of members in formu_item have been changed slightly in some
cases, but except for that it should drop in to the existing code
pretty easily. The final function shows how to invoke a function
in the table safely.

I have added a few bits of running commentary.

Code compiles cleanly (if I haven't made any editing mistakes)
with -pedantic -Wall -Wextra, under c++11, c++14, and c++17.

union FuncU {
double (*zero)();
double (*one)( double );
double (*two)( double, double );
double (*three)( double, double, double );

constexpr FuncU( double (*f)() ) : zero( f ) {}
constexpr FuncU( double (*f)( double ) ) : one( f ) {}
constexpr FuncU( double (*f)( double, double ) ) : two( f ) {}
constexpr FuncU( double (*f)( double, double, double ) ) : three( f ) {}

// a member for each kind of function, and
// a constructor for each of the different function kinds

};

typedef enum {
A_ZERO, A_ONE, A_TWO, A_THREE,

// I use an enum rather than an int

} FKind;

struct formu_item {
const char *name;
FKind n_pars;
bool varying;
FuncU fu;
};

// next is the core idea - have a type-safe constructor
// for each of the different kinds of functions

constexpr formu_item
zero_f( const char *name, bool varying, double (*f)() ){
return { name, A_ZERO, varying, FuncU( f ) };
}

constexpr formu_item
one_f( const char *name, bool varying, double (*f)( double ) ){
return { name, A_ONE, varying, FuncU( f ) };
}

constexpr formu_item
two_f( const char *name, bool varying, double (*f)( double, double ) ){
return { name, A_TWO, varying, FuncU( f ) };
}

typedef double (*Fdouble3)( double, double, double );

constexpr formu_item
three_f( const char *name, bool varying, Fdouble3 f ){
return { name, A_THREE, varying, FuncU( f ) };
}

#include <math.h>

static double pi(){
return 3.1415926535897932384626433832795029;
}

static const formu_item ftable_static[]= {
one_f( "exp", 0, exp ),
one_f( "ln", 0, log ),
one_f( "sin", 0, sin ),
one_f( "cos", 0, cos ),
one_f( "tan", 0, tan ),
one_f( "asin", 0, asin ),
one_f( "acos", 0, acos ),
one_f( "atan", 0, atan ),
two_f( "atan2", 0, atan2 ),
one_f( "abs", 0, fabs ),
one_f( "sqrt", 0, sqrt ),
zero_f( "pi", 0, pi ),

// the function table. Note that if the supplied function
// doesn't match the associated constructor then there will
// be a compilation error

};

double
invoke_formula( unsigned k, double a, double b, double c ){
unsigned n = sizeof ftable_static / sizeof ftable_static[0];
if( k >= n ) return 0. / 0.; // k too large => NaN

switch( ftable_static[k].n_pars ){
case A_ZERO: return ftable_static[k].fu.zero();
case A_ONE: return ftable_static[k].fu.one( a );
case A_TWO: return ftable_static[k].fu.two( a, b );
case A_THREE: return ftable_static[k].fu.three( a, b, c );
}

return -1. / 0.; // table messed up => infinity
}

On 4/24/2024 3:10 PM, Tim Rentsch wrote:
> Paavo Helde <eesnimi@osa.pri.ee> writes:
>
>> 24.04.2024 10:36 Bonita Montero kirjutas:
>>
>>> Am 23.04.2024 um 20:33 schrieb Paavo Helde:
>>>
>>>> The function pointers are cast to a single type so that they can be
>>>> stored in a common lookup array. ...
>>>
>>> Then you'd need additional information to distinguish the different
>>> types. If you have sth. like that you could take a variant<>.
>>
>> Right, the varying part is the number of arguments, which is
>> explicitly declared and stored in the array as well (n_pars below). If
>> you are interested, the current code (no warnings any more here,
>> thanks to Markus!) looks like below. Not sure if changing to a variant
>> or void(*)() would make the code better, looks like then I would need
>> to add extra casts to all the lines in the table which currently do
>> not need any casts.
>>
>> #include <math.h>
>>
>> typedef double (*Func)(double);
>>
>> struct formu_item {
>> const char *name;
>> Func f; /* pointer to function*/
>> int n_pars; /* number of parameters (0, 1, 2 or 3) */
>> int varying; /* Does the result of the function vary
>> even when the parameters stay the same?
>> varying=1 for e.g. random-number generators. */
>> };
>>
>> typedef void (*VoidFunc)();
>> typedef double (*DoubleFunc_0_args)();
>> typedef double (*DoubleFunc_2_args)(double, double);
>>
>> Func FuncCast2(DoubleFunc_2_args fp) {
>> return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
>> }
>> Func FuncCast0(DoubleFunc_0_args fp) {
>> return reinterpret_cast<Func>(reinterpret_cast<VoidFunc>(fp));
>> }
>> double pi() {
>> return 3.1415926535897932384626433832795029;
>> }
>>
>> static const formu_item ftable_static[TABLESIZE]=
[...]

For some damn reason this makes me think of this older code:

https://groups.google.com/g/comp.lang.c/c/8X_an3MpDYQ/m/TYw70DcnBQAJ

https://pastebin.com/raw/f52a443b1

25.04.2024 01:10 Tim Rentsch kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> writes:
>
[...]
>> static const formu_item ftable_static[TABLESIZE]=
>> {
>> {"exp", exp,1,0},
>> {"ln", log,1,0},
>> {"sin", sin,1,0},
>> {"cos", cos,1,0},
>> {"tan", tan,1,0},
>> {"asin", asin,1,0},
>> {"acos", acos,1,0},
>> {"atan", atan,1,0},
>> {"atan2", FuncCast2(atan2),2,0},
>> {"abs", fabs,1,0},
>> {"sqrt", sqrt,1,0},
>> {"pi", FuncCast0(pi),0,0},
>> //...
>> }
>
> The code below uses no casting, and encapsulates the constructors
> for 'formu_item's so that the functions are guaranteed to be in
> sync with the discriminating member of the struct. The names and
> types of members in formu_item have been changed slightly in some
> cases, but except for that it should drop in to the existing code
> pretty easily. The final function shows how to invoke a function
> in the table safely.

Indeed. Somehow I was convinced that when providing multiple
constructors, the compiler would fail with ambiguity errors because all
of these functions like sin() are overloaded in C++. But it seems the
compiler figures it out nicely.

>
> I have added a few bits of running commentary.
>
> Code compiles cleanly (if I haven't made any editing mistakes)
> with -pedantic -Wall -Wextra, under c++11, c++14, and c++17.

This is not exactly true, when compiling with VS2022 I get two compile
errors:

if (k >= n) return 0. / 0.; // k too large => NaN

1>C:\Test\ConsoleTestVS2022\ConsoleTest2022\main.cpp(97,18): error
C2124: divide or mod by zero

But that's fully another topic.

Thanks for the demo code!
BR

Am 24.04.2024 um 21:18 schrieb David Brown:

> The point here was that function pointers and object pointers do not
> have standards-defined conversion behaviour (that fact is indisputable).

But you can alias other type-combinations for sure.

Wouldn't that be more convenient ?

static vector<pair<char const *, function<double ( double, double,
double )>>> fns;
fns.reserve( 12 );
fns.emplace_back( "exp", +[]( double num, double, double ) ->
double { return exp( num ); } );
fns.emplace_back( "ln", +[]( double num, double, double ) -> double
{ return log( num ); } );
fns.emplace_back( "sin", +[]( double num, double, double ) ->
double { return sin( num ); } );
fns.emplace_back( "cos", +[]( double num, double, double ) ->
double { return cos( num ); } );
fns.emplace_back( "tan", +[]( double num, double, double ) ->
double { return tan( num ); } );
fns.emplace_back( "asin", +[]( double num, double, double ) ->
double { return asin( num ); } );
fns.emplace_back( "acos", +[]( double num, double, double ) ->
double { return acos( num ); } );
fns.emplace_back( "atan", +[]( double num, double, double ) ->
double { return atan( num ); } );
fns.emplace_back( "atan2", +[]( double x, double y, double ) ->
double { return atan2( x, y ); } );
fns.emplace_back( "abs", +[]( double num, double, double ) ->
double { return abs( num ); } );
fns.emplace_back( "sqrt", +[]( double num, double, double ) ->
double { return sqrt( num ); } );
fns.emplace_back( "pi", +[]( double, double, double ) -> double {
return 3.14; } );

Am 25.04.2024 um 11:19 schrieb Bonita Montero:
> Wouldn't that be more convenient ?
>
>     static vector<pair<char const *, function<double ( double, double,
> double )>>> fns;
>     fns.reserve( 12 );
>     fns.emplace_back( "exp", +[]( double num, double, double ) ->
> double { return exp( num ); } );
>     fns.emplace_back( "ln", +[]( double num, double, double ) -> double
> { return log( num ); } );
>     fns.emplace_back( "sin", +[]( double num, double, double ) ->
> double { return sin( num ); } );
>     fns.emplace_back( "cos", +[]( double num, double, double ) ->
> double { return cos( num ); } );
>     fns.emplace_back( "tan", +[]( double num, double, double ) ->
> double { return tan( num ); } );
>     fns.emplace_back( "asin", +[]( double num, double, double ) ->
> double { return asin( num ); } );
>     fns.emplace_back( "acos", +[]( double num, double, double ) ->
> double { return acos( num ); } );
>     fns.emplace_back( "atan", +[]( double num, double, double ) ->
> double { return atan( num ); } );
>     fns.emplace_back( "atan2", +[]( double x, double y, double ) ->
> double { return atan2( x, y ); } );
>     fns.emplace_back( "abs", +[]( double num, double, double ) ->
> double { return abs( num ); } );
>     fns.emplace_back( "sqrt", +[]( double num, double, double ) ->
> double { return sqrt( num ); } );
>     fns.emplace_back( "pi", +[]( double, double, double ) -> double {
> return 3.14; } );

Or somewhat simpler:

vector<pair<char const *, double (*)( double, double, double )>> fns;
fns.reserve( 12 );
fns.emplace_back( "exp", +[]( double num, double, double ) ->
double { return exp( num ); } );
fns.emplace_back( "ln", +[]( double num, double, double ) -> double
{ return log( num ); } );
fns.emplace_back( "sin", +[]( double num, double, double ) ->
double { return sin( num ); } );
fns.emplace_back( "cos", +[]( double num, double, double ) ->
double { return cos( num ); } );
fns.emplace_back( "tan", +[]( double num, double, double ) ->
double { return tan( num ); } );
fns.emplace_back( "asin", +[]( double num, double, double ) ->
double { return asin( num ); } );
fns.emplace_back( "acos", +[]( double num, double, double ) ->
double { return acos( num ); } );
fns.emplace_back( "atan", +[]( double num, double, double ) ->
double { return atan( num ); } );
fns.emplace_back( "atan2", +[]( double x, double y, double ) ->
double { return atan2( x, y ); } );
fns.emplace_back( "abs", +[]( double num, double, double ) ->
double { return abs( num ); } );
fns.emplace_back( "sqrt", +[]( double num, double, double ) ->
double { return sqrt( num ); } );
fns.emplace_back( "pi", +[]( double, double, double ) -> double {
return 3.14; } );

So this takes no CPU-time at all:

static pair<char const *, double (*)( double, double, double )>
const fns[] =
{
{ "exp", []( double num, double, double ) -> double { return
exp( num ); } },
{ "ln", []( double num, double, double ) -> double { return
log( num ); } },
{ "sin", []( double num, double, double ) -> double { return
sin( num ); } },
{ "cos", []( double num, double, double ) -> double { return
cos( num ); } },
{ "tan", []( double num, double, double ) -> double { return
tan( num ); } },
{ "asin", []( double num, double, double ) -> double { return
asin( num ); } },
{ "acos", []( double num, double, double ) -> double { return
acos( num ); } },
{ "atan", []( double num, double, double ) -> double { return
atan( num ); } },
{ "atan2", []( double x, double y, double ) -> double { return
atan2( x, y ); } },
{ "abs", []( double num, double, double ) -> double { return
abs( num ); } },
{ "sqrt", []( double num, double, double ) -> double { return
sqrt( num ); } },
{ "pi", []( double, double, double ) -> double { return 3.14; } }
};

25.04.2024 12:48 Bonita Montero kirjutas:
> So this takes no CPU-time at all:
>
>     static pair<char const *, double (*)( double, double, double )>
> const fns[] =
>     {
>         { "exp", []( double num, double, double ) -> double { return
> exp( num ); } },
>         { "ln", []( double num, double, double ) -> double { return
> log( num ); } },
>         { "sin", []( double num, double, double ) -> double { return
> sin( num ); } },
>         { "cos", []( double num, double, double ) -> double { return
> cos( num ); } },
>         { "tan", []( double num, double, double ) -> double { return
> tan( num ); } },
>         { "asin", []( double num, double, double ) -> double { return
> asin( num ); } },
>         { "acos", []( double num, double, double ) -> double { return
> acos( num ); } },
>         { "atan", []( double num, double, double ) -> double { return
> atan( num ); } },
>         { "atan2", []( double x, double y, double ) -> double { return
> atan2( x, y ); } },
>         { "abs", []( double num, double, double ) -> double { return
> abs( num ); } },
>         { "sqrt", []( double num, double, double ) -> double { return
> sqrt( num ); } },
>         { "pi", []( double, double, double ) -> double { return 3.14; } }
>     };

Looks cleaner, but for using with the current code the correct number of
arguments would still be needed to stored separately, as this is the
only thing which tells the expression evaluator how many arguments to
pop out of the operand stack.

Current usage goes about like this:

switch(ftable[*rcode].n_pars) {
case 0:
*bufp++ = (*BackCast0(ftable[*rcode++].f))();
break;
case 1:
x = *--bufp;
*bufp++ = ftable[*rcode++].f(x);
break;
case 2:
y = *--bufp;
x = *--bufp;
*bufp++ = (*BackCast2(ftable[*rcode++].f))(x,y);
break;
case 3:
z = *--bufp;
y = *--bufp;
x = *--bufp;
*bufp++ = (*BackCast3(ftable[*rcode++].f))(x,y,z);
break;
}

BackCast* are just another function pointer casts, e.g.

DoubleFunc_2_args BackCast2(Func fp) {
return reinterpret_cast<DoubleFunc_2_args>(reinterpret_cast<VoidFunc>(fp));
}

With your proposal this code could be indeed shortened and there would
be no need for casts ;-)

switch(ftable[*rcode].n_pars) {
case 3:
z = *--bufp;
[[fallthrough]];
case 2:
y = *--bufp;
[[fallthrough]];
case 1:
x = *--bufp;
} *bufp++ = ftable[*rcode++].f(x,y,z);

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 25.04.2024 01:10 Tim Rentsch kirjutas:
>
>> Paavo Helde <eesnimi@osa.pri.ee> writes:
>
> [...]
>
>>> static const formu_item ftable_static[TABLESIZE]=
>>> {
>>> {"exp", exp,1,0},
>>> {"ln", log,1,0},
>>> {"sin", sin,1,0},
>>> {"cos", cos,1,0},
>>> {"tan", tan,1,0},
>>> {"asin", asin,1,0},
>>> {"acos", acos,1,0},
>>> {"atan", atan,1,0},
>>> {"atan2", FuncCast2(atan2),2,0},
>>> {"abs", fabs,1,0},
>>> {"sqrt", sqrt,1,0},
>>> {"pi", FuncCast0(pi),0,0},
>>> //...
>>> }
>>
>> The code below uses no casting, and encapsulates the constructors
>> for 'formu_item's so that the functions are guaranteed to be in
>> sync with the discriminating member of the struct. The names and
>> types of members in formu_item have been changed slightly in some
>> cases, but except for that it should drop in to the existing code
>> pretty easily. The final function shows how to invoke a function
>> in the table safely.
>
> Indeed. Somehow I was convinced that when providing multiple
> constructors, the compiler would fail with ambiguity errors because
> all of these functions like sin() are overloaded in C++. But it seems
> the compiler figures it out nicely.

As it turns out I may have complicated the question by using
<math.h> rather than <cmath>. However, upon trying again with
<cmath> and with both <math.h> and <cmath> I learned that
overload resolution is indeed smart enough to figure out which
function matches. I expect this works because exact matches
always take precedence.

>> I have added a few bits of running commentary.
>>
>> Code compiles cleanly (if I haven't made any editing mistakes)
>> with -pedantic -Wall -Wextra, under c++11, c++14, and c++17.
>
> This is not exactly true, when compiling with VS2022 I get two compile
> errors:
>
> if (k >= n) return 0. / 0.; // k too large => NaN
>
> 1>C:\Test\ConsoleTestVS2022\ConsoleTest2022\main.cpp(97,18): error
> C2124: divide or mod by zero

How strange. In C it would work (and it does work under gcc
and clang). Apparently the C++ standard is fuzzier about what
is required for floating-point constant expressions.

> But that's fully another topic.

Right. Also I expect the limitation is easy to get around, if
that is important (and here it really wasn't).

> Thanks for the demo code!

You are most welcome. I am definitely a proponent of avoiding
casts whenever possible.

Am 25.04.2024 um 21:22 schrieb Paavo Helde:
> 25.04.2024 12:48 Bonita Montero kirjutas:
>> So this takes no CPU-time at all:
>>
>>      static pair<char const *, double (*)( double, double, double )>
>> const fns[] =
>>      {
>>          { "exp", []( double num, double, double ) -> double { return
>> exp( num ); } },
>>          { "ln", []( double num, double, double ) -> double { return
>> log( num ); } },
>>          { "sin", []( double num, double, double ) -> double { return
>> sin( num ); } },
>>          { "cos", []( double num, double, double ) -> double { return
>> cos( num ); } },
>>          { "tan", []( double num, double, double ) -> double { return
>> tan( num ); } },
>>          { "asin", []( double num, double, double ) -> double { return
>> asin( num ); } },
>>          { "acos", []( double num, double, double ) -> double { return
>> acos( num ); } },
>>          { "atan", []( double num, double, double ) -> double { return
>> atan( num ); } },
>>          { "atan2", []( double x, double y, double ) -> double {
>> return atan2( x, y ); } },
>>          { "abs", []( double num, double, double ) -> double { return
>> abs( num ); } },
>>          { "sqrt", []( double num, double, double ) -> double { return
>> sqrt( num ); } },
>>          { "pi", []( double, double, double ) -> double { return 3.14;
>> } }
>>      };
>
> Looks cleaner, but for using with the current code the correct number of
> arguments would still be needed to stored separately, ...

And how about that:

struct fn_t
{
char const *what;
size_t nParams;
double (*fn)( double, double, double );
};
static fn_t const fns[] =
{
{ "exp", 1, []( double num, double, double ) -> double { return exp(
num ); } },
{ "ln", 1, []( double num, double, double ) -> double { return log(
num ); } },
{ "sin", 1, []( double num, double, double ) -> double { return sin(
num ); } },
{ "cos", 1, []( double num, double, double ) -> double { return cos(
num ); } },
{ "tan", 1, []( double num, double, double ) -> double { return tan(
num ); } },
{ "asin", 1, []( double num, double, double ) -> double { return asin(
num ); } },
{ "acos", 1, []( double num, double, double ) -> double { return acos(
num ); } },
{ "atan", 1, []( double num, double, double ) -> double { return atan(
num ); } },
{ "atan2", 2, []( double x, double y, double ) -> double { return
atan2( x, y ); } },
{ "abs", 1, []( double num, double, double ) -> double { return abs(
num ); } },
{ "sqrt", 1, []( double num, double, double ) -> double { return sqrt(
num ); } },
{ "pi", 1, []( double, double, double ) -> double { return 3.14; } }
};