lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

I also think A_B_C isn't perfect, but more important is the fact that
extracting namespaces from the header files works.

With a simple binding, like slb, and a simplified generator we could
easily change such things. At the moment only Mauro knows the generator
code good enough to change it.

Peter



Anders Backman wrote:
Mmm, but I really really dislike the A_B_C syntax, when Lua supports tables which gives a much more intuitive interface... 

Tolua syntax is: NAMESPACE.CLASS:method()

I very much prefer that.
Im not sure what syntax slb had for namespaces...?
I noticed than some of the other template-based bindings where using a similar (_) notion. 

I also like the:


What about destruction? Who is responsible for deallocating objects?
Tolua has:
B= a.class:new(); // you are explicitly responsible for deallocating this local B=a.class:new_local(); // it will be deallocated when B goes out of scope
which is also something I like, because it works with reference counting (:new() is used, and then the object is given to a ref_ptr in c++ which owns the object). 

/Anders
On Tue, Jan 20, 2009 at 9:11 PM, Peter Kümmel <syntheticpp@gmx.net <mailto:syntheticpp@gmx.net>> wrote: 

    Peter Kümmel wrote:

        Anders Backman wrote:

            Well in most cases for us, namespaces are crucial.
            For example a class named Vec3 can be found in multiple
            places in our framework (once in the SceneGraph and once in
            the Physics), but its just one place where it can pop up.

            So some kind of support of Namespaces would be nice...ideas?


        Hi Anders,

        I've pushed some code to demonstrate the namespace support of lqt.
        Calling cmake with -Dnoqt will suppress the Qt binding and will bind


    Sorry, =1 is missing:

    cmake ../lqt -Dnoqt=1


        the to classes in test/noqt:

        namespace n1 { class F; } and
        namespace n2 { class F; }

        At the moment the code doesn't run but you will see that the binding
        of lqt can handle namespaces in principle. There are two lua
        classes:

        extern "C" LQT_EXPORT int luaopen_n1_LQT_F (lua_State *L) {
           lqtL_createclass(L, "n1_LQT_F*", lqt_metatable_3, lqt_base_3);
           return 0;
        }

        and

        extern "C" LQT_EXPORT int luaopen_n1_LQT_F (lua_State *L) {
           lqtL_createclass(L, "n2_LQT_F*", lqt_metatable_3, lqt_base_3);
           return 0;
        }

        which could be used like this (but first we must fully free the
        code from the
        Qt stuff):

        require 'noqt'

        n1 = n1_LQT_F.new();
        n2 = n2_LQT_F.new();

        print(n1:foo());
        print(n2:foo());


        Peter



            /Anders

            On Mon, Jan 19, 2009 at 10:45 PM, Mauro Iazzi
            <mauro.iazzi@gmail.com <mailto:mauro.iazzi@gmail.com>
            <mailto:mauro.iazzi@gmail.com
            <mailto:mauro.iazzi@gmail.com>>> wrote:

               2009/1/18 Anders Backman <andersb@cs.umu.se
            <mailto:andersb@cs.umu.se> <mailto:andersb@cs.umu.se
            <mailto:andersb@cs.umu.se>>>:
               >  Ok, great, one step further, at least one left:
               >  Now I added -i  ${BINDING_HEADER}/${BINDING_HEADER}
               >  Which generates:
               >
               >  #ifndef LQT_HEAD_agxStream_LQT_EndOfArchiveException
               >  #define LQT_HEAD_agxStream_LQT_EndOfArchiveException
               >  #include "lqt_common.hpp"
               >  #include "libname/libname" <<<<
               >  #include "lqt_qt.hpp"

               I assume this is the behaviour you wanted, correct?

               >  // But then this libname depends on another namespace
            which is
               then tried to
               >  be included with:
               >  #include <otherlib>
               >  // which is not correct. Not quite sure where this
            comes from...
               >  // Either it should not be there at all, or it should be
               <otherlib/otherlib>
               >  class LQT_EXPORT
            lqt_shell_otherlib_LQT_EndOfArchiveException : public
               >  agxStream::EndOfArchiveException {
               >
               >  /Anders

               I think this comes from a trick we added to speed up
            compilation of Qt
               bindings. Instead of including the original header, the
            class includes
               an header containing the name of the class. It works for
            Qt. I'll add
               a switch to turn off this behaviour.

               Namespaces are not considered. I don't even know how lqt
            behaves with
               namespaces. And I don't know how much time it would need
            to get them
               working. I think some not-so-clean workaround could be
            found, if you
               need it.
-- __________________________________________ 
            Anders Backman, CTO  Algoryx Simulation AB
            Uminova Science Park, Box 7973,  SE-907 19
            Umeå,  Sweden
            anders@algoryx.se <mailto:anders@algoryx.se>
            <mailto:anders@algoryx.se <mailto:anders@algoryx.se>>
            http://www.algoryx.se
            Cell: +46-70-392 64 67





--
__________________________________________
Anders Backman, CTO  Algoryx Simulation AB
Uminova Science Park, Box 7973,  SE-907 19
Umeå,  Sweden
anders@algoryx.se <mailto:anders@algoryx.se> http://www.algoryx.se
Cell: +46-70-392 64 67