[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lqt: Qt bindings update
- From: Mauro Iazzi <mauro.iazzi@...>
- Date: Wed, 21 Jan 2009 00:24:31 +0100
2009/1/20 Peter Kümmel <syntheticpp@gmx.net>:
> I also think A_B_C isn't perfect, but more important is the fact that
> extracting namespaces from the header files works.
exactly.
however I just committed a change which makes namespaces work with the . syntax.
>
> 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.
Yes, the generator is too intricated right now.
I hope to change this sooner or later.
> 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
>
