Re: Implicit casting issues when binding to C++

  • From: "Janis Britals" <jbritals@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sat, 7 Jul 2012 11:46:54 +0200

Mike Pall wrote:

> An interim solution would be to use trace_abort() whenever you do
> a special conversion in the interpreter. Yep, this means those
> calls to Qt would never get compiled. Probably good enough for
> testing, though.

Actually it could be good enough for production even. You use those fancy
casts mostly in complex GUI code where the compiled speed is not that
important. And you can instruct your users to avoid implicit constructors
by  explicitly specifying them (i.e. write QLabel(QString("Text")) instead
of QLabel("Text")) wherever the speed is essential. This will effectively
lift the cast out of the lj_cconv_ct_ct function into the Lua code.

> Well, it won't make it into the source right now (too big of a
> change before the feature freeze in LuaJIT 2.0) and not in this
> state (not general enough).

I see your point. Of course, you need a solution that covers all possible
cases, and I didn't think that my hack was actually fit for inclusion in
LuaJIT baseline (it's just that - a hack). But in the process of doing it
I got the feeling that it would not be too difficult to make a proper
generalization (provided you can solve the JIT compiler issues - that's
where I must rely on your judgement, Mike)

> However, I might be tempted to include a general, lightweight
> mechanism to override or augment C type conversions. But without
> dragging in half of the C++ implicit type conversion logic into
> the FFI core. I'll need to think about it -- no promises.

That would be excellent and exactly what's needed. I found out that the
best way of binding to C++ is to implement most of the C++ "features"
(constructors/destructors, function overloading, etc. etc.) in pure Lua,
so if there was a way to hook into the conversion mechanism that could be
expanded on from Lua side, it would complete my bindings keeping in the
same style.

> Err, I'm not against covering C++. Actually it's mentioned in the
> LuaJIT Roadmap in the list of potential features for LuaJIT 2.1.

Whatever you can come up with, I'm all ears (and maybe even hands if it is
within my capabilities). In the meantime I'll go with my Lua version and
seeing the little monster it has become I think it'll take some time :)


Other related posts: