> Daniel Wallin <[EMAIL PROTECTED]> writes: > > > At 18:03 2003-06-17, you wrote: > >>http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/16 > 73338 is more > >>recent and also relevant to your question. > >> > >>In short, I'd love to see luabind in Boost, and I'd hate > to see it > >>happen without substantial code sharing with > Boost.Python. > > > > I agree. It seems like a lot of code could be shared. > > For instance, the conversion system between > base<->derived should work > > exactly the same and we could probably plug in BPL's > system for this > > without much trouble. > > > > It would also be really nice if we could share most of > the front-end > > code (declaration of > > scopes, classes and functions). > > > > Note however that there are quite a few differences in > design, for instance > > for our scope's we have been experimenting with > expressions ala phoenix: > > > > namespace_("foo") > > [ > > def(..), > > def(..) > > ]; > > I considered this syntax but I am not convinced it is an > advantage. > It seems to have quite a few downsides and no upsides. Am > I missing > something?
For us it has several upsides: * We can easily nest namespaces * We like the syntax :) * We can remove the lua_State* parameter from all calls to def()/class_() What do you consider the downsides to be? > > > Also, we don't have a type-converter registry; we make > all choices on what > > converter to use at compile time. > > I used to do that, but it doesn't support > component-based-development > has other serious problems. Are you sure your code is > actually > conformant? When converters are determined at > compile-time, the only > viable and conformant way AFAICT is with template > specializations, and > that means clients have to be highly conscious of ordering > issues. I think it's conformant, but I wouldn't swear on it. We strip all qualifiers from the types and specialize on by_cref<..> by_ref<..> by_ptr<..> by_value<..> types. It works on all compilers we have tried it on (vc 6-7.1, codewarrior, gcc2.95.3+, intel). For us it doesn't seem like an option to dispatch the converters at runtime, since performance is a really high priority for our users. -- Daniel Wallin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost