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
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
