[C++-sig] langbinding questions

[Jim Bosch]

Thanks...it sounds like I understand things better than I thought I did. 
  Though I'm still worried that I'm confusing which is the "accept" and 
which is the "visit" class somehow.  More questions/replies below.

>> 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.
>

I just meant a namespace-scope variable, static data member, or static 
function-scope variable.  Is there a good catch-all term for such variables?

>> 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?
>

In the sense that all the frontend classes seem to need to enumerate all 
the possible backends, because they each have a different module_builder 
class.  Some super-simplified code for what I'm imagining:

class frontend_function {
public:
   virtual visit(python_builder & b) = 0;
   virtual visit(lua_builder & b) = 0;
};

template <typename FunctionPointer>
class frontend_function_t : public frontend_function {
public:
   virtual visit(python_builder & b) {
     b.wrap_function(m_name, m_func);
   }
   virtual visit(lua_builder & b) {
     b.wrap_function(m_name, m_func);
   }
private:
   std::string m_name;
   FunctionPointer m_func;
};

class python_builder : public module_builder {
public:
   template <typename FunctionPointer>
   void wrap_function(std::string const & name, FunctionPointer p);
};

This isn't horrible, and "doesn't scale" is the wrong phrase, but it 
doesn't allow you to add new backends without modifying the core 
library, and I had (perhaps naively) assumed that was part of the design.

>> 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.
>

It's probably just a red-herring of some sort, but the section 3.2 of 
the above doc starts with "Module builders must be instances of a class 
derived from a CRTP base class".  I've looked at the langbinding code in 
the boost svn sandbox, and I'm it seem to be mostly utility code at the 
moment (though I admit I don't understand how a lot of it fits together, 
so maybe I'm missing the forrest for the trees).

Thanks!

Jim