Export Member variable ( type Object) fail

Issue #7 invalid
Oscar Zhao
created an issue

Using OOLUA_MGET_MSET, I successfully exported member variables with basic types, int, double, string, for example. However, when I export a member variable (an object, Computer::m_mouse, m_mouse is an instance of class Mouse), error occurs. I presume that, if I proxied "Mouse", I can use its instance as parameters or return value. Was I using it incorrectly? (The attachment is the test code, Error messange is as following: "

1>e:\work\libs\trunk\include\oolua\stack_get.h(121) : error C2440: 'static_cast' : cannot convert from 'lua_Integer' to 'Mouse'
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>        e:\work\libs\trunk\include\oolua\stack_get.h(117) : while compiling class template member function 'void OOLUA::INTERNAL::LUA_CALLED::get_basic_type<T,is_integral,is_convertable_to_int>::get(lua_State *const ,int,T &)'
1>        with
1>        [
1>            T=Mouse,
1>            is_integral=1,
1>            is_convertable_to_int=1
1>        ]
1>        e:\work\libs\trunk\include\oolua\stack_get.h(136) : see reference to class template instantiation 'OOLUA::INTERNAL::LUA_CALLED::get_basic_type<T,is_integral,is_convertable_to_int>' being compiled
1>        with
1>        [
1>            T=Mouse,
1>            is_integral=1,
1>            is_convertable_to_int=1
1>        ]

Comments (7)

  1. Liam Devine repo owner

    Oscar thank you taking the time of packaging the source files and reporting your problem. I must apologise as I feel the error is probably my fault, due to not having released the repo version or its accompanying documentation. However, even if I had this problem could still be encountered by a user so I will update the documenation as I do not make it explict in the public member section of the issue you are having here.

    OOLua does not support overloading, besides for constructors, so the names given to OOLUA_MGET_MSET in the second and third parameters must be different. This allows for the names to be something like get_mouse and set_mouse instead of set_m_mouse. In your attached code, you have used the same names for both parameters in all calls to the macro. I am not currently at a dev machine, but I would have thought this would have resulted in more many more error messages which I can presume you have pruned for this error report.

    I will leave this issue open until I have had a chance to sit down at a dev machine, as I am concerned about the error message you show. However, if in the mean time you make the above adjustion then please do report back your result.

    Thanks

  2. Oscar Zhao reporter

    Actually, the problem has nothing to do with override, I will talk about it at last. First, your answer helps in an unexpected way. I just modified all the "OOLUA_MGET_MSET(member_var)" to "OOLUA_MGET_MSET(member_var, member_var, member_var)" after reading the source code, and did not do the test yet. You remind me of that.
    Second, the error I met is not about override. I have reverted the code to "OOLUA_MGET_MSET(member_var)" revision, the same error is reported Third, I have another question about override. I used bson in my project. the class bson::bo has an overloaded member function called "append", and I want to proxy them. However, I do not know how. I will attach a screenshot later. Finally, thank you for your timely reply. Expecting help... OOLua.jpg

  3. Liam Devine repo owner

    I assume that this means the code works as expected for the single and multiple parameter macro.

    This is off topic and would be better suited to the mailing list for a query or this tracker for a bug. The minimal version OOLUA_FUNC(appendBool), expressive version or expressive with renaming should all be fine but the expressive and miminal can not be both present. Could you expand on the problem you are seeing?

  4. Oscar Zhao reporter

    Perhaps I didn't describe my question clearly. The problem I met is described in the "second", which is the problem of exporting member variables with self-defined type. The attachment will state my question (the "second") much more precisely, The "third" described another question, (not the obvious mistake you saw)later I would like to write another test to state the question. I'm sorry not to explain myself clearly....

  5. Log in to comment