That prototype started to grow and now it has some functionalities:
- The reflection of an interface can be created. This structure prepares the storage for the class methods. The reflection also
"prepares the storage for the class methods"? Does each object have a pointer to something like a virtual function table, and this "preparation of storage" is maybe a singleton with maybe a static vector of function pointer's which the object contains a pointer to?
In our first version (the one for GSoC, now we're modifying a lot of things) the storage is only a map that stores the different methods of the class. That methods are registered with a special function. Basically we want to have the type information for each method and identifiers to find then. Also we have a boost::function pointing to the real method.
stores an Info class (similar to the one in Boost.Extension) and an ID to select the interface. The type of the ID is a template argument.
- Different methods can be stored. The interface is the one suggested by Jeremy, where you define the type of the parameter ID and the type of the parameter itself with template arguments. The method info is stored in a multi-type map, similar to the factory map of Boost.Extension.
Could you provide a reference that explains Jeremy's interface a little more.
There are some mails to the list, but it's described in the docs too. The docs are in the SVN, and excuse for not being clear in the last mail, the SVN is Boost Sandbox SVN. Anyway we're now changing a bit the interface, but you can see there the main ideas, and some working examples.
- Finally, we want to call that methods. Two methods were proposed to do that (but only one is fully functional now):
. call a method defining its parameter and parameter ID types using the call method template arguments.
boost's fusion "fuses", somehow, compile time and runtime "calls". The compile time calls (returning types) are done with a nested apply template (IIRC). The run time calls are done with a static call function in some class template which uses the compile-time apply to get the type of the return. It sounds to me like you're doing something similar. Is that right?
I think it's more simple. We have the map with the methods, and functions to get their boost::function. Having that we can call the methods with a given instance and parameters.
. call a method using a parameter map. The parameter map is implemented, but Jeremy is working in the best way to find the method and invoke the function pointer.
We also have three examples (a basic one, another showing Boost.Extension integration and an example C++ interpreter prototype). Also we have a unit test checking the basic functionalities.
I'd be very interested in seeing this C++ interpreter.
It's just a prototype.. :) But you can see in the docs a section describing its current status, and with the new interface it could be more flexible.
[snip]
All is in the SVN with Jamfiles that compile everything.
I've looked at http://svn.boost.org/trac/boost/browser but can't find it. Could you be more specific?
Excuse me..! :) They're in the Boost Sandbox. Thanks for your interest. -- Mariano