WheretIB / LuaDkmDebugger

Visual Studio C++ debugger extensions for Lua
MIT License
84 stars 32 forks source link

Add luabind support #19

Open Xottab-DUTY opened 3 years ago

Xottab-DUTY commented 3 years ago

Official repository: https://github.com/luabind/luabind

Forks: https://github.com/rpavlik/luabind https://github.com/OpenXRay/luabind-deboostified/

Documentation: https://github.com/luabind/luabind/wiki/Docs#implementation-notes

The classes and objects are implemented as user data in Lua. To make sure that the user data really is the internal structure it is supposed to be, we tag their metatables. A user data who's metatable contains a boolean member named __luabind_classrep is expected to be a class exported by luabind. A user data who's metatable contains a boolean member named __luabind_class is expected to be an instantiation of a luabind class.

This means that if you make your own user data and tags its metatable with the exact same names, you can very easily fool luabind and crash the application.

In the Lua registry, luabind keeps an entry called __luabind_classes. It should not be removed or overwritten.

WheretIB commented 3 years ago

Can you tell which specific part doesn't work or can be improved right now? Is script load not detected at all or do you just want to be able to explore these userdata object contents?

Xottab-DUTY commented 3 years ago

Yes, the second! It will be awesome to see the userdata contents. Currently, even if you assign a variable like this

function my_class:my_function()
    self.x = 0
end

you won't see the x in locals, because x belongs to the luabind's class and it is implemented using metatables.

WheretIB commented 2 years ago

How compatible is luabind-deboostified with luabind? I've tried the original and don't like the boost setup, but I'm worried that the custom version support will not help people who use the boost version.

Xottab-DUTY commented 2 years ago

I didn't find any functional difference in src/*.cpp, except some changes in weak_ref.cpp, but it's really hard to analyze public headers, because almost all of them were rewritten.

Xottab-DUTY commented 2 years ago

@WheretIB, was there any progress or decisions made?

brinkqiang commented 2 years ago

@Xottab-DUTY luabind is deprecated, sol2 outperforms the library in every way. I wrote an automated bind library based on sol2. You can take a look if you are interested. https://github.com/brinkqiang/dmsolpp

Xottab-DUTY commented 2 years ago

@Xottab-DUTY luabind is deprecated, sol2 outperforms the library in every way. I wrote an automated bind library based on sol2. You can take a look if you are interested. brinkqiang/dmsolpp

It doesn't outperform in every way. It doesn't support classes like luabind does. (luabind even support virtual functions that can be declared in C++ and overridden in Lua!) And we are stuck with the legacy Lua scripts that use luabind classes and which we cannot change. So, thank you, but no.

brinkqiang commented 2 years ago

@Xottab-DUTY Xottab-DUTY luabind even support virtual functions that can be declared in C++ and overridden in Lua.

    module.new_usertype<CCreature>(
        "CCreature"
        , sol::constructors<CCreature()>()
        , sol::meta_function::garbage_collect, sol::destructor([](CCreature& temp) { temp.~CCreature(); })
        , sol::base_classes, sol::bases<CObject>()
        , "SetHP", sol::make_reference<sol::function>(lua.lua_state(), &CCreature::SetHP)
        , "SetMP", sol::make_reference<sol::function>(lua.lua_state(), &CCreature::SetMP)
        , "GetHP", sol::make_reference<sol::function>(lua.lua_state(), &CCreature::GetHP)
        , "GetMP", sol::make_reference<sol::function>(lua.lua_state(), &CCreature::GetMP)

        );

use sol::make_reference

ForserX commented 2 years ago

+1