An easy way to overload functions about luabridge3 HOT 14 CLOSED

Yes this is definately possible, but it will also add more complexity to the method resolution.

I have it planned for the future, after i stabilise the API of the Stack push and get to make them safe to be used from c++.

from luabridge3.

I don't think you will need to change anything, just adding this template "overload" function. I will try to develop something. But if you thing it is not necessary this moment, you can close this.

from luabridge3.

I was just saying, that before i can look into overloads i need to first solve one problematic issue i have with LuaBridge which is unsafety of C++ calls it does, so many code paths leads to a lua_error() call which will call the panic handler when called from C++ and ends up raising an exception or worse having lua to call std::abort when exceptions are not enabled (we return from the panic handler). Once i've stabilized this PR #37 i will look into optional function overloads.

In that regard, there is an interesting discussion in this very very old (but still valid solution) vanilla LuaBridge ticket > vinniefalco/LuaBridge#9

from luabridge3.

I pushed a WIP branch for initial work on the overloaded functions and method support #38

It's based on the new push / get methods (#37) so you might have some issues dropping it in as it contains some breaking changes in the Stack api, and for now i've exposed only the Namespace and Class addOverload methods taking lambdas (it's not possible atm to mix and match function pointers, lua_CFunctions and lambdas in the same call to addOverload).

I decided to do a separate method in order to not overweight the normal addFunction methods with additional data (function arity) that is needed to exclude methods with non matching number of arguments (arity is not needed for simple functions, but it's needed for overloads).

    int x = 100;

    luabridge::getGlobalNamespace(L)
        .addOverload("test",
            [x](int v) -> int {
                return v + x;
            },
            [x](std::string v) -> int {
                return v.size() ? int(v[0]) : x;
            });

    runLua("result = test (255)");
    ASSERT_TRUE(result().isNumber());
    EXPECT_EQ(355, result<int>());

    runLua("result = test ('')");
    ASSERT_TRUE(result().isNumber());
    EXPECT_EQ(100, result<int>());

    runLua("result = test ('0')");
    ASSERT_TRUE(result().isNumber());
    EXPECT_EQ(48, result<int>());

from luabridge3.

Very fast solution :-)
I will test it as soon as possible.

The "problem" of separate method is you need to do for StaticFunction too, Namespace, Class and all variations. A lot of new methods may be me necessary. Instead of nested method option like addFunction(addOverload(...)).

May be name addOverload not the best IMO. Could be addOverloadFunction and addOverloadStaticFunction.

from luabridge3.

Yes i agree, but this is the first iteration. I'm working on unifying all the overloads into a single template overload that can catch all of them. I came up with this (for namespace bound functions):

    template <class... Functions>
    auto addFunction(const char* name, Functions... functions)
        -> std::enable_if_t<(detail::is_callable_v<Functions> && ...), Namespace&>
    {
        static_assert(sizeof...(Functions) > 0);

        assert(name != nullptr);
        assert(lua_istable(L, -1)); // Stack: namespace table (ns)

        if constexpr (sizeof...(Functions) == 1)
        {
            ([&]
            {
                detail::push_function(L, std::move(functions));
                rawsetfield(L, -2, name);

            } (), ...);
        }
        else
        {
            // create new closure of try_overloads with new table
            lua_createtable(L, static_cast<int>(sizeof...(Functions)), 0); // reserve space for N overloads

            int idx = 1;

            ([&]
            {
                lua_createtable(L, 2, 0); // reserve space for: function, arity
                lua_pushinteger(L, 1);
                lua_pushinteger(L, static_cast<int>(detail::function_arity_excluding_v<Functions, lua_State*>));
                lua_settable(L, -3);
                lua_pushinteger(L, 2);
                detail::push_function(L, std::move(functions));
                lua_settable(L, -3);

                lua_rawseti(L, -2, idx);
                ++idx;

            } (), ...);

            lua_pushcclosure_x(L, &detail::try_overload_functions, 1);
            rawsetfield(L, -2, name);
        }

        return *this;
    }

This allows to use a single method for registering both single functions, lambdas, CFunctions, and mixed overloads for all the above.

.addFunction("name",
     &functionPointer,
     &functionPointerToLuaCFunction,
     [] {}, // non capturing lambda
     +[] {}, // non capturing lambda decayed to function pointer
     [capturing] {} // capturing lambda
);

For classes it will be a bit more complicated as we have the const and the non-const table, and depending on the constness of the object, or first argument of the function (which should be the self pointer), we need to register in one or both tables, and we might need to push 2 tables and 2 try_overload_functions in both.

from luabridge3.

Awesome!
I am very happy with the replacement of Sol2 to Luabridge3. This was the missing feature.

Also I am working in overload resolution by C++ side. I don't know if in terms of performance what is the best. I will publish here if success.

from luabridge3.

I have some ideas that can speed up prioritising the most fitting overloads by using a similar technique to jni where the signature is encoded in string format (see https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html#wp276)

from luabridge3.

Yes overload resolution on c++ side is something i thought about as well and could be a path we investigate, but was a bit more convoluted in term of storage and retrieval, and depending if the methods are reused or not it will generate much more template instantiations.

from luabridge3.

I have been progressing a lot, we now have support in Namespace and Class, where addFunction addStaticFunction and addConstructor (the version taking functors) are allowed to take a single function or overloads passed in with a single function, supporting lua_CFunction, function pointers, member function pointers, capturing and non capturing lambdas and in general anything that is copyable and callable (std::function to name one example) !

I have not been benchmarking much, what i got is pretty usable already and i'm happy with it. Later will try to put up a benchmark and maybe investigate how we could speed up the storage and resolution by doing it in c++ land

from luabridge3.

It is important to do it work first. After could try to improve performance as you said.

What are the plans to merge master branch?

from luabridge3.

I have plan to merge as soon as possible, but i would really like to write even more unit tests.

For now https://github.com/kunitoki/LuaBridge3/blob/f6adba327a19967b21857252369423ea4b4ece07/Tests/Source/OverloadTests.cpp is covering a wide variety of use cases already, but it's never too bad to add more checks, especially in an area like that.

For example i found that because of this code in the Stack https://github.com/kunitoki/LuaBridge3/blob/master/Source/LuaBridge/detail/Stack.h#L981-L1005 where we actually convert the argument to string (lua_tolstring is converting to string anything, even calling __tostring if defined!), even if it's not of type string, an overload with a std::string argument at index N will basically "eat" any type passed in from lua at index N during overload resolution. I would say this is wrong and during function call / overload resolution, the behaviour of the Stack should be strict (but this means adding more flags, complexity).

from luabridge3.

Wow! Nice work :-) I use my own 'manualbind' now, which is a quite different beast, however it's great to see LuaBridge still being given some love :-D

from luabridge3.

Manualbind... sounds like a lot of work 🤣

from luabridge3.