Lua Wrapper Class - Exposing c++ static methods to Lua through a DLL












1















I finally got into a problem that I can't find a solution here. I'm using a Lua Wrapper Class found in here http://lua-users.org/wiki/CppConvenientLuaWrapperClass. We've been able to expose a complete API plus more other funcionalities like serial communication and on.



The concept behind this Lua Wrapper is that you expose every method before compiling so when you're running your programm all methods will be added to the Lua Stack and in that way you can execute them. The idea now is to build kind of a Dll in order to complete this process of exposing methods. This way you won't needed to release a version with all exposed methods instead you load them trough multiple dll files.



I've tried to create another table and register other methods in that table, but with that, previous exposed methods stop working.



The other way around I can think of, is to create a dll but in C that contains all desirable methods and load it directly to Lua. But I think the other way would be better.



Have you been able to do something similar ? Am I having some wrong concept?



Thanks



Humm... I really don't want to change our wrapper at this time. I think I could manage to do it, sort of. Instead of adding a new table for the plugin functions, I've added a new sub-table tha will contain the functions names and cClosures to be called from Lua.
So at the end we should have:



application.functionName()
application.plugin.functionName()


Even if it work this way it will do fine.
Now I wonder how can we reference the lua_settable when exposing the functions to be added to application[plugin][pluginFunction] instead of aplication[pluginFunction]?!
This is how the normal functions are exposed:



//mState is a pointer to a Lua_State
lua_pushstring( mState, functionName );

//methodDesc is a pointer to an object that describes the function arguments/returns
lua_pushlightuserdata( mState, methodDesc );

//exposeMethodProxy is the method that is responsible for conneting lua c-calls to the c-functions
lua_pushcclosure( mState, exposedMethodProxy, 1 );

//mMethodTableIndex is a member variable that contains the index of the table tha hold all exposed functions
lua_settable( mState, mMethodTableIndex );


Any ideas on how I could achieve adding the cclosures not to the main table(at mMethodTableIndex) as mainTable[functionName] but at maintable[plugin][functionNane].?










share|improve this question

























  • wxLua does the same thing - you could take a look at their code to see how they did it.

    – finnw
    Feb 13 '13 at 14:19











  • Humm thanks, I'll give a look

    – MRodrigues
    Feb 14 '13 at 14:07
















1















I finally got into a problem that I can't find a solution here. I'm using a Lua Wrapper Class found in here http://lua-users.org/wiki/CppConvenientLuaWrapperClass. We've been able to expose a complete API plus more other funcionalities like serial communication and on.



The concept behind this Lua Wrapper is that you expose every method before compiling so when you're running your programm all methods will be added to the Lua Stack and in that way you can execute them. The idea now is to build kind of a Dll in order to complete this process of exposing methods. This way you won't needed to release a version with all exposed methods instead you load them trough multiple dll files.



I've tried to create another table and register other methods in that table, but with that, previous exposed methods stop working.



The other way around I can think of, is to create a dll but in C that contains all desirable methods and load it directly to Lua. But I think the other way would be better.



Have you been able to do something similar ? Am I having some wrong concept?



Thanks



Humm... I really don't want to change our wrapper at this time. I think I could manage to do it, sort of. Instead of adding a new table for the plugin functions, I've added a new sub-table tha will contain the functions names and cClosures to be called from Lua.
So at the end we should have:



application.functionName()
application.plugin.functionName()


Even if it work this way it will do fine.
Now I wonder how can we reference the lua_settable when exposing the functions to be added to application[plugin][pluginFunction] instead of aplication[pluginFunction]?!
This is how the normal functions are exposed:



//mState is a pointer to a Lua_State
lua_pushstring( mState, functionName );

//methodDesc is a pointer to an object that describes the function arguments/returns
lua_pushlightuserdata( mState, methodDesc );

//exposeMethodProxy is the method that is responsible for conneting lua c-calls to the c-functions
lua_pushcclosure( mState, exposedMethodProxy, 1 );

//mMethodTableIndex is a member variable that contains the index of the table tha hold all exposed functions
lua_settable( mState, mMethodTableIndex );


Any ideas on how I could achieve adding the cclosures not to the main table(at mMethodTableIndex) as mainTable[functionName] but at maintable[plugin][functionNane].?










share|improve this question

























  • wxLua does the same thing - you could take a look at their code to see how they did it.

    – finnw
    Feb 13 '13 at 14:19











  • Humm thanks, I'll give a look

    – MRodrigues
    Feb 14 '13 at 14:07














1












1








1








I finally got into a problem that I can't find a solution here. I'm using a Lua Wrapper Class found in here http://lua-users.org/wiki/CppConvenientLuaWrapperClass. We've been able to expose a complete API plus more other funcionalities like serial communication and on.



The concept behind this Lua Wrapper is that you expose every method before compiling so when you're running your programm all methods will be added to the Lua Stack and in that way you can execute them. The idea now is to build kind of a Dll in order to complete this process of exposing methods. This way you won't needed to release a version with all exposed methods instead you load them trough multiple dll files.



I've tried to create another table and register other methods in that table, but with that, previous exposed methods stop working.



The other way around I can think of, is to create a dll but in C that contains all desirable methods and load it directly to Lua. But I think the other way would be better.



Have you been able to do something similar ? Am I having some wrong concept?



Thanks



Humm... I really don't want to change our wrapper at this time. I think I could manage to do it, sort of. Instead of adding a new table for the plugin functions, I've added a new sub-table tha will contain the functions names and cClosures to be called from Lua.
So at the end we should have:



application.functionName()
application.plugin.functionName()


Even if it work this way it will do fine.
Now I wonder how can we reference the lua_settable when exposing the functions to be added to application[plugin][pluginFunction] instead of aplication[pluginFunction]?!
This is how the normal functions are exposed:



//mState is a pointer to a Lua_State
lua_pushstring( mState, functionName );

//methodDesc is a pointer to an object that describes the function arguments/returns
lua_pushlightuserdata( mState, methodDesc );

//exposeMethodProxy is the method that is responsible for conneting lua c-calls to the c-functions
lua_pushcclosure( mState, exposedMethodProxy, 1 );

//mMethodTableIndex is a member variable that contains the index of the table tha hold all exposed functions
lua_settable( mState, mMethodTableIndex );


Any ideas on how I could achieve adding the cclosures not to the main table(at mMethodTableIndex) as mainTable[functionName] but at maintable[plugin][functionNane].?










share|improve this question
















I finally got into a problem that I can't find a solution here. I'm using a Lua Wrapper Class found in here http://lua-users.org/wiki/CppConvenientLuaWrapperClass. We've been able to expose a complete API plus more other funcionalities like serial communication and on.



The concept behind this Lua Wrapper is that you expose every method before compiling so when you're running your programm all methods will be added to the Lua Stack and in that way you can execute them. The idea now is to build kind of a Dll in order to complete this process of exposing methods. This way you won't needed to release a version with all exposed methods instead you load them trough multiple dll files.



I've tried to create another table and register other methods in that table, but with that, previous exposed methods stop working.



The other way around I can think of, is to create a dll but in C that contains all desirable methods and load it directly to Lua. But I think the other way would be better.



Have you been able to do something similar ? Am I having some wrong concept?



Thanks



Humm... I really don't want to change our wrapper at this time. I think I could manage to do it, sort of. Instead of adding a new table for the plugin functions, I've added a new sub-table tha will contain the functions names and cClosures to be called from Lua.
So at the end we should have:



application.functionName()
application.plugin.functionName()


Even if it work this way it will do fine.
Now I wonder how can we reference the lua_settable when exposing the functions to be added to application[plugin][pluginFunction] instead of aplication[pluginFunction]?!
This is how the normal functions are exposed:



//mState is a pointer to a Lua_State
lua_pushstring( mState, functionName );

//methodDesc is a pointer to an object that describes the function arguments/returns
lua_pushlightuserdata( mState, methodDesc );

//exposeMethodProxy is the method that is responsible for conneting lua c-calls to the c-functions
lua_pushcclosure( mState, exposedMethodProxy, 1 );

//mMethodTableIndex is a member variable that contains the index of the table tha hold all exposed functions
lua_settable( mState, mMethodTableIndex );


Any ideas on how I could achieve adding the cclosures not to the main table(at mMethodTableIndex) as mainTable[functionName] but at maintable[plugin][functionNane].?







c++ dll methods lua






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 8:02









Cœur

18.6k9110150




18.6k9110150










asked Feb 13 '13 at 13:21









MRodriguesMRodrigues

1,0461316




1,0461316













  • wxLua does the same thing - you could take a look at their code to see how they did it.

    – finnw
    Feb 13 '13 at 14:19











  • Humm thanks, I'll give a look

    – MRodrigues
    Feb 14 '13 at 14:07



















  • wxLua does the same thing - you could take a look at their code to see how they did it.

    – finnw
    Feb 13 '13 at 14:19











  • Humm thanks, I'll give a look

    – MRodrigues
    Feb 14 '13 at 14:07

















wxLua does the same thing - you could take a look at their code to see how they did it.

– finnw
Feb 13 '13 at 14:19





wxLua does the same thing - you could take a look at their code to see how they did it.

– finnw
Feb 13 '13 at 14:19













Humm thanks, I'll give a look

– MRodrigues
Feb 14 '13 at 14:07





Humm thanks, I'll give a look

– MRodrigues
Feb 14 '13 at 14:07












1 Answer
1






active

oldest

votes


















1














I'm not sure, you're clear on what you want to do. A typical way to extend lua is to write a DLL with a single method that uses the Lua API to register your C++ types and C functions. To conviniently bind C++ functions and classes, you could use LuaBridge. An example of such binding is here: https://github.com/d-led/xerceslua



The header for the DLL of the xerceslua module contains only one function:



#include <lua.hpp>
void register_xerceslua (lua_State* L);


inside the implementation LuaBridge is used to bind to C++:



#include "xerceslua_lib.h"

#include <lua.hpp>
#include <LuaBridge.h>

void register_xerceslua (lua_State* L) {
...
luabridge::getGlobalNamespace(L)
.beginNamespace("xerces")
.addVariable("version",&version,false)
...


in Lua you can then access the exposed C++ API:



assert(require 'xerceslua')

local parser=xerces.XercesDOMParser()
parser:loadGrammar("Employee.dtd",xerces.GrammarType.DTDGrammarType)


You can use Lua both as an embedded scripting language, where you can execute lua from within your software, or you could use it as an extensible scripting language, extending it using the method shown above. Both are valid, but you have to consider, what exactly you are trying to do.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f14854555%2flua-wrapper-class-exposing-c-static-methods-to-lua-through-a-dll%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    I'm not sure, you're clear on what you want to do. A typical way to extend lua is to write a DLL with a single method that uses the Lua API to register your C++ types and C functions. To conviniently bind C++ functions and classes, you could use LuaBridge. An example of such binding is here: https://github.com/d-led/xerceslua



    The header for the DLL of the xerceslua module contains only one function:



    #include <lua.hpp>
    void register_xerceslua (lua_State* L);


    inside the implementation LuaBridge is used to bind to C++:



    #include "xerceslua_lib.h"

    #include <lua.hpp>
    #include <LuaBridge.h>

    void register_xerceslua (lua_State* L) {
    ...
    luabridge::getGlobalNamespace(L)
    .beginNamespace("xerces")
    .addVariable("version",&version,false)
    ...


    in Lua you can then access the exposed C++ API:



    assert(require 'xerceslua')

    local parser=xerces.XercesDOMParser()
    parser:loadGrammar("Employee.dtd",xerces.GrammarType.DTDGrammarType)


    You can use Lua both as an embedded scripting language, where you can execute lua from within your software, or you could use it as an extensible scripting language, extending it using the method shown above. Both are valid, but you have to consider, what exactly you are trying to do.






    share|improve this answer




























      1














      I'm not sure, you're clear on what you want to do. A typical way to extend lua is to write a DLL with a single method that uses the Lua API to register your C++ types and C functions. To conviniently bind C++ functions and classes, you could use LuaBridge. An example of such binding is here: https://github.com/d-led/xerceslua



      The header for the DLL of the xerceslua module contains only one function:



      #include <lua.hpp>
      void register_xerceslua (lua_State* L);


      inside the implementation LuaBridge is used to bind to C++:



      #include "xerceslua_lib.h"

      #include <lua.hpp>
      #include <LuaBridge.h>

      void register_xerceslua (lua_State* L) {
      ...
      luabridge::getGlobalNamespace(L)
      .beginNamespace("xerces")
      .addVariable("version",&version,false)
      ...


      in Lua you can then access the exposed C++ API:



      assert(require 'xerceslua')

      local parser=xerces.XercesDOMParser()
      parser:loadGrammar("Employee.dtd",xerces.GrammarType.DTDGrammarType)


      You can use Lua both as an embedded scripting language, where you can execute lua from within your software, or you could use it as an extensible scripting language, extending it using the method shown above. Both are valid, but you have to consider, what exactly you are trying to do.






      share|improve this answer


























        1












        1








        1







        I'm not sure, you're clear on what you want to do. A typical way to extend lua is to write a DLL with a single method that uses the Lua API to register your C++ types and C functions. To conviniently bind C++ functions and classes, you could use LuaBridge. An example of such binding is here: https://github.com/d-led/xerceslua



        The header for the DLL of the xerceslua module contains only one function:



        #include <lua.hpp>
        void register_xerceslua (lua_State* L);


        inside the implementation LuaBridge is used to bind to C++:



        #include "xerceslua_lib.h"

        #include <lua.hpp>
        #include <LuaBridge.h>

        void register_xerceslua (lua_State* L) {
        ...
        luabridge::getGlobalNamespace(L)
        .beginNamespace("xerces")
        .addVariable("version",&version,false)
        ...


        in Lua you can then access the exposed C++ API:



        assert(require 'xerceslua')

        local parser=xerces.XercesDOMParser()
        parser:loadGrammar("Employee.dtd",xerces.GrammarType.DTDGrammarType)


        You can use Lua both as an embedded scripting language, where you can execute lua from within your software, or you could use it as an extensible scripting language, extending it using the method shown above. Both are valid, but you have to consider, what exactly you are trying to do.






        share|improve this answer













        I'm not sure, you're clear on what you want to do. A typical way to extend lua is to write a DLL with a single method that uses the Lua API to register your C++ types and C functions. To conviniently bind C++ functions and classes, you could use LuaBridge. An example of such binding is here: https://github.com/d-led/xerceslua



        The header for the DLL of the xerceslua module contains only one function:



        #include <lua.hpp>
        void register_xerceslua (lua_State* L);


        inside the implementation LuaBridge is used to bind to C++:



        #include "xerceslua_lib.h"

        #include <lua.hpp>
        #include <LuaBridge.h>

        void register_xerceslua (lua_State* L) {
        ...
        luabridge::getGlobalNamespace(L)
        .beginNamespace("xerces")
        .addVariable("version",&version,false)
        ...


        in Lua you can then access the exposed C++ API:



        assert(require 'xerceslua')

        local parser=xerces.XercesDOMParser()
        parser:loadGrammar("Employee.dtd",xerces.GrammarType.DTDGrammarType)


        You can use Lua both as an embedded scripting language, where you can execute lua from within your software, or you could use it as an extensible scripting language, extending it using the method shown above. Both are valid, but you have to consider, what exactly you are trying to do.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 13 '13 at 15:45









        Dmitry LedentsovDmitry Ledentsov

        3,0001123




        3,0001123
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f14854555%2flua-wrapper-class-exposing-c-static-methods-to-lua-through-a-dll%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            The Sandy Post

            Danny Elfman

            Pages that link to "Head v. Amoskeag Manufacturing Co."