Re: Implicit casting issues when binding to C++
- From: Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 9 Jul 2012 17:47:39 +0100
On Mon, Jul 9, 2012 at 12:16 PM, Janis Britals <jbritals@xxxxxxxxx> wrote:
> I agree about the usefulness of implicit casting. My implementation in FFI
> was to look up the conversion function in the metatype of the argument when
> the supplied type was different from what was expected and then to call it.
> Usually it would be the corresponding implicit C++ constructor. Thanks to
> the awsome efficiency of FFI it would take just marginally more cycles than
> the same implicit conversion in C++ itself! There is no "slowdown" to speak
> of. The only thing is that that needs support from FFI core, so I'm really
> hoping that sometime in the near future Mike will come up with his
> "lightweight generalized conversion extension" he talked about in his post.
> Until then I have to rely on my little hack, which I hope to get straight
> now with the help of Mike's comments.
What I have been doing is, rather than looking up a conversion
function in the metatype, is if the argument is not of the expected
type to pass it to that type as an initialiser. Now that we have __new
you can put all the work about how to convert to the type in the __new
method.
ie
if not ffi.istype(QString, arg) arg = QString(arg) end
You could also have the __new constructor simply return stuff
unchanged if it is the right type already, in which case you can wrap
all accesses in the type constructor, which is pretty readable, and
the hit will optimise stuff out.
Justin
Other related posts:
