From: dalwan01 (dalwan01_at_[hidden])
Date: 2003-06-18 06:26:10
> Daniel Wallin <dalwan01_at_[hidden]> writes:
> > At 18:03 2003-06-17, you wrote:
> 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
> > 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
> It seems to have quite a few downsides and no upsides. Am
> I missing
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
> has other serious problems. Are you sure your code is
> 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
I think it's conformant, but I wouldn't swear on it.
We strip all qualifiers from the types and specialize on
types. It works on all compilers we have tried it on (vc
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk