Duktape VS sol2

Fast math optimizations can break code like this by breaking isNaN.

I was porting a C++ project to a certain platform - and that platform enabled a -ffast-math equivalent by default in Release (but not Debug) builds! This broke duktape, a JS engine said project embedded, in some nasty and subtle ways. Instead of storing a number/pointer/??? (8 bytes) + type tag (4? bytes) for each dynamically typed JS value, duktape can bit-pack values into a single 8 byte "double" value by storing object/string handles as NaN values - this isn't an uncommon trick for dynamically typed scripting stuff:

https://github.com/svaarala/duktape/blob/c3722054ea4a4e50f48...

Naturally, the -ffast-math equivalent broke isNaN checks, which caused random object/string handles to be mistakenly reinterpreted as "numbers" - but only in Release builds, for this one particular platform, in one rarely taken branch, so neither QA nor CI caught it, leading to hours of manufacturing a repro case, stepping through an absurd amount of code, and then finally looking at the default build rules and facepalming.

Cursing the platform vendor under my breath, I overrode the defaults to align with the defaults of every other config x platform combination we already had: no fast math. If you want those optimizations, use SSE-friendly NaN-avoiding intrinsics - or, if you must use the compiler flags, ensure you do so consistently across build configs and platforms, perhaps limited to a few TUs or modules if possible. This allows you to have a chance at using your Debug builds to debug the resulting "optimizations".

Sure. For example, DukTape is an implementation of Javascript designed to be embedded in other projects. Google's V8 Javascript engine (used in Chrome), can also be embedded, see Node.Js for example.

- Duktape (4.8k stars)

Here is link number 2 - Previous text "Sol"

Sol for fast lua embedding

Have you considered using sol2? https://github.com/ThePhD/sol2 Or if you don't want to switch over, you can at least look at their code and see how they handle this.

It is half of a pun as I was inspired by [sol3](https://github.com/ThePhD/sol2) which is a lua c++ wrapper. Sol means sun and the julia c-api prefixes all it's functions with jl, luna means moon so it is pronounced "jay luna"

So far, it has been cumbersome to embed it into C-language projects, because it's C-interface is hard to use and poorly documented. Because of this, many choose to just use python or lua instead.

If you want to be portable I'd recommend C++ and Lua, I used those for years and it runs on everything and there's this most amazing wrapper API which was a huge inspiration

Off topic, but this is the author of my favourite Lua C++ binding library (https://github.com/ThePhD/sol2). Great guy!

I mean, if you could tell from my original post, I like C++ templates. The point is not to constantly write templates in your calling code, the point is to architect a library with templates that affords flexibility and dynamism so that the calling code is easy to write, read, and reason about. Consider, for example, the sol2[0] example usage code vs the actual source code itself[1].

0. https://github.com/ThePhD/sol2

Very interesting article!

Unfortunately, it doesn't mention Lua, which in my opinion has one of the most elegant C APIs that I have seen. It is entirely stack based, which means you only need to work with primitive types, such as numbers, C strings and user provided opaque pointers. As a consequence, you never have to care about memory management because Lua doesn't even let you access the actual Lua objects.

You want to create a table (= Lua's dictionary/array hybrid) and set a field "foo" to 5? lua_newtable() creates a new table and pushes it onto the stack. Then you push "foo" with lua_pushstring() and 5 with lua_pushnumber(). Finally you call lua_settable(), which pops the key and value from the stack, checks if the top of the stack contains a table, and if yes, sets the given field to the given value. The actual table structure is never exposed!

This kind of stack manipulation might seem unusual and a bit unweildy, but what you get is safety. If you mess up the stack or perform illegal operations, Lua will call an error handler, but the VM should never crash. The stack API can be seen as the fundamental layer upon which people can create nice abstractions for their host language of choice. Examples are "sol2" for C++ (https://github.com/ThePhD/sol2) or "lupa" for Python (https://github.com/scoder/lupa)

The public API is contained in "lua.h": https://github.com/lua/lua/blob/master/lua.h. "lauxlib.h" offers some useful helper functions: https://github.com/lua/lua/blob/master/lauxlib.h

For comparison, this is Python's "Limited" C API: https://docs.python.org/3/c-api/stable.html#stable

If you want to learn more about Lua's C API, have a look at section 4 in https://www.lua.org/manual/5.4/manual.html

Next to some already said examples: sol2 v3.0 https://github.com/ThePhD/sol2 - a Lua to C++ "header only" bridge...