Compare `LuaRef`s referencing Lua functions in C++ code about luabridge3 HOT 10 CLOSED

LuaRef comparison operators will use lua_compare and will invoke metamethods. I'm not sure functions can be compared with that, and for sure they can't have a LuaRef::operator< which seems to be needed by std::set (it uses std::less<LuaRef> underneat). Maybe you get better results using std::unordered_set by also providing a KeyEqual comparator based on LuaRef::rawequal rather than LuaRef::operator== (which is selected by default by std:equal_to<LuaRef>).

I will see if i can make it work somehow.

from luabridge3.

If i replace your set with an unordered_set it works no problem. Is there a reason you need ordering ?

from luabridge3.

No, I don't need set specifically, to me it was just a convenient way to store unique functions without possibility to have duplicates, but this only works with that Function wrapper I wrote, which has that unique id field, which can be used in operator< as well. But yeah, I can use any other container, like unordered_set or list, I just need a way to compare functions to be able to find them in that container and delete when necessary.
So yeah, if you're able to compare LuaRef referencing functions on your side or you can provide more information about that KeyEqual / rawequal so I can use it in my code, that could already work well for me. In fact, if rawequal is able to compare functions in Lua style, i.e. using those addresses or whatever this is I described above, I mean function: 0000024a923ade90, that's good enough for me.

from luabridge3.

Hm, I just realized that if you wrote it works with unordered_set, this means comparison for equality works already, otherwise how unordered_set would check for item uniqueness, right? I just thought that error attempt to compare two function values appears in any attempt to compare functions, including equality. But if it's not, then I might have created an issue for nothing. Let me check that.

from luabridge3.

== works on functions, but < not

from luabridge3.

You can do this, but lua_pointer will return nullptr for trivial types:

struct LuaRefLess
{
    bool operator()(const luabridge::LuaRef& x, const luabridge::LuaRef& y) const
    {
        x.push();
        auto lhs = lua_topointer(x.state(), -1);

        y.push();
        auto rhs = lua_topointer(y.state(), -1);

        return lhs < rhs;
    }
};

TEST_F(LuaRefTests, SetComparatorOperatorLessThan)
{
    std::set<luabridge::LuaRef, LuaRefLess> eventHandlers;

    auto subscribe = [&eventHandlers](luabridge::LuaRef handler)
    {
        if (handler.isFunction())
            eventHandlers.insert(handler);
    };

    auto trigger = [&eventHandlers]
    {
        for (auto handler : eventHandlers)
            handler();
    };

    luabridge::getGlobalNamespace(L)
        .addFunction("subscribe", subscribe)
        .addFunction("trigger", trigger);

    runLua(R"(
        a = function()
            print('Hello')
        end
        b = a

        subscribe(a)
        subscribe(b)
        subscribe("wrong")

        subscribe(function()
            print('World')
        end)
    )");

    trigger();
}

from luabridge3.

Yep, I just checked and turns out there's no issue at all, looks like comparison for equality works already under the hood and thus I can delete LuaRef-functions from C++ container no problem. My bad, I misinterpreted the error, or rather haven't researched it enough. Additionally, I just checked in the intepreter and figured out this error comes from Lua itself, not from LuaBridge, as I assumed before, so yeah, this is how it is:

> f1 = function()end
> f2 = function()end
> f1 == f2
false
> f1 < f2
stdin:1: attempt to compare two function values
stack traceback:
        stdin:1: in main chunk
        [C]: in ?

Ok, thank you for your attention in any case, and I'm closing this issue then.

from luabridge3.

#65 < This could fix your issue and be more safe at the same time, as lua_compare might raise a lua error (and trigger the panic handler).

from luabridge3.

By looking at the changes I assume you compare pointer values there. I wanted to suggest the same, because initially I supposed pointers increase in value as function variables get initialized, but then I noticed it's not always the case, probably because of GC, so I started to think it's not that good idea as it seems that simple == is more reliable. But if you implemented it, I guess it can't hurt, because this should allow storing LuaRef in set, even in case if order of LuaRef being added to set won't match ordering inside of set because of that apparent address increment inconsistency.

from luabridge3.

I'm also not sure, but i also don't want that a call in c++ on luarefs will trigger the panic handler

from luabridge3.