Moving this to the C++-sig as it's a more appropriate forum... "dalwan01" <[EMAIL PROTECTED]> writes:
>> Daniel Wallin <[EMAIL PROTECTED]> writes: >> >> > At 18:03 2003-06-17, you wrote: >> >>http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338 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 IMO, it optimizes for the wrong case, since namespaces are typically flat rather than deeply nested (see the Zen of Python), nor are they represented explicitly in Python code, but inferred from file boundaries. > * We like the syntax :) It is nice for C++ programmers, but Python programmers at least are very much more comfortable without the brackets. > * We can remove the lua_State* parameter from > all calls to def()/class_() I'm not sure what that is. We handle global state in Boost.Python by simply keeping track of the current module ("state") in a global variable. Works a treat. > What do you consider the downsides to be? In addition to what I cited above, a. since methods and module-scope functions need to be wrapped differently, you need to build up a data structure which stores the arguments to def(...) out of the comma-separated items with a complex expression-template type and then interpret that type using a metaprogram when the operator[]s are applied. This can only increase compile times, which is already a problem. b. You don't get any order-of-evaluation guarantees. Things like staticmethod() need to operate on an existing function object in the class' dictionary [http://www.boost.org/libs/python/doc/v2/class.html#class_-spec-modifiers] and if you can't guarantee that it gets executed after a def() call you need to further complicate your expression template to delay evaluation of staticmethod() I guess these two are essentially the same issue. >> > 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. How do people define specialized converters for particular types? > It works on all compilers we have tried it on (vc 6-7.1, > codewarrior, gcc2.95.3+, intel). Codewarrior Pro8.x, explicitly using the '-iso-templates on' option? All the others support several common nonconformance bugs, many of which I was exploiting in Boost.Python v1. > 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. What we're doing in Boost.Python turns out to be very efficient, well below the threshold that anyone would notice IIUC. Eric Jones did a test comparing its speed to SWIG and to my great surprise, Boost.Python won. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
