Hi Jim,
Sorry this is so late. Sick, work, sick, work... you know how it can
be.
on Sun Jan 15 2012, Jim Bosch <talljimbo-AT-gmail.com> wrote:
> I've been trying to wrap my head around some Boost.Langbinding
> concepts as part of my (slow, but not dead) work on an eventual
> Boost.Python v3. I've got some questions - and if there are others who
> I should be sending this email to, please let me know and/or forward.
Yeah, you should send it to the langbinding list and/or Cc: Daniel
Wallin.
> As I understand it, the basic idea is:
>
> 1) We build a language-agnostic front-end "module definition" data
> structure that gets stored in a static object.
I don't know what you mean by "static object," but the rest is dead on.
> 2) That data structure hides all the type information somehow
Hides it at compile-time; represents it at runtime.
> - I'm imagining a polymorphic non-template base class with templated
> derived classes, or something equivalent. But I get the sense that
> this may be an incorrect assumption.
I don't know why; sounds like a classic type erasure pattern.
> 3) We pass in a target-language-specific "module builder" to the
> "module definition", which goes through itself and calls visit member
> functions on the "module builder", which in turn creates the
> target-language wrapper.
That sounds right.
> I can see, roughly, how this would work if there's only one module
> builder class (i.e. one target language). The polymorphic classes in
> the module definition would have virtual functions that just take a
> module_builder instance, and then they can call templated visit member
> functions on the module_builder.
>
> But I don't think that model is what was intended - it doesn't scale
> well to multiple target languages,
In what way?
> and it doesn't explain why the module_builder classes in the proposal
> (I'm looking here:
http://www.boostpro.com/writing/oopsla04.html) use
> CRTP.
I don't see any CRTP. There's some prototype code in SVN that might explain
details such as module_builder's template parameter.
> I'm also confused (probably in a related way) about the type of the
> arguments to the module_builder::visit functions; somebody has to do
> the target-language specific dirty work of creating a wrapped
> backend::function<B> from an arbitrary C++ function pointer or other
> callable, and I would have expected that to be a job for the
> module_builder, not the front-end element that is calling
> module_builder::visit.
yep. Seems like a bug in that doc. I expect the module_builder to
visit frontend:: thangs. Maybe, though, I had the idea that things in
the backend:: namespace should encompass everything the backend has to
process. It's clearly not templatized on the backend language and
therefore not specific to the back-end at all.
> Note that I'm not trying to implement all of Boost.Langbinding, or
> even most - I'm just trying to understand it so I can write a more
> future-friendly Boost.Python.
Thanks for asking, Jim.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding