[GSoC] Boost.Extension/Reflection final status
As you surely know, I've been working during GSoC in a project called Boost.Extension/Reflection. Now that GSoC is finished, I'm sending this email to summarize my work in the last three months. The first part was Boost.Extension. It's a library to load dynamic plugins (in the form of .so or .dlls) to C++ programs. The library had been started by Jeremy Pack prior to GSoC, and our goal was to finish it and prepare for revision. We (almost) finished the library , just remaining some minor details that Jeremy addressed. We think that we are asking a revision soon. Then we moved to Boost.Reflection part. This part is about making a library (from scratch) that allows C++ to acquire Reflection features. For reflection we mean ways to know about its structure, meta-information for the classes and its methods. The first step in the process was to read some papers about reflection in C++ (and about the paradigm itself). After that, I started to implement some of the Jeremy's ideas. 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 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. - 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. . 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. That's the code. Besides that we've docs. We have an introduction, a general description and two tutorials. The first tutorial is about the first example, and the second is about the Boost.Extension integration example. Also we have a section describing the C++ interpreter prototype. All is in the SVN with Jamfiles that compile everything. There are a lot of things to do/improve. But I think that we achieved the basic objective of having a solid base. Having that we have time to improve and complete. After GSoC finish, Jeremy has been hacking the code a lot and we have important changes, including the library interface. Now we have to stabilize the new branch and then update the docs, tests and examples. We're looking forward to improve Boost.Reflection in order to prepare it for revision at some point. Thanks to the community for their help and suggestions during the program. Bye! -- mariano
On 09/03/07 08:10, Mariano Consoni wrote: [snip]
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?
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.
- 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?
. 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. [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?
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
On 09/03/07 13:43, Mariano Gabriel Consoni wrote: [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.
More specifically, here: http://svn.boost.org/trac/boost/browser/sandbox/boost/reflection ;)
Thanks for your interest.
and thank you for the work.
As Mariano said, the interface is changing very slightly (I'm teasing apart some of the interdependencies). I'd recommend checking out the examples folders in svn.boost.org/trac/boost/browser/sandbox/libs/extensions and libs/reflections. For the modified reflection interface, check out basic_test.cpp in libs/reflections/test, which shows some of that code. I'm just working on getting the modified version Boost.Extension submitted. I've made RTTI even more optional - you only need to use it if you wish to store constructors for many different types of interfaces in the same data structure. If you are not, no RTTI is necessary. In general, even if you wish to store many different types of interfaces in the same data structure, you can avoid RTTI by defining your own type info - integers perhaps. There is an example showing how this is done. I believe we should be ready for an initial review of the library in about one month - once this refactoring is done and the documentation has been modified. Jeremy Pack On 9/3/07, Larry Evans <cppljevans@cox-internet.com> wrote:
On 09/03/07 13:43, Mariano Gabriel Consoni wrote: [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.
More specifically, here:
http://svn.boost.org/trac/boost/browser/sandbox/boost/reflection
;)
Thanks for your interest.
and thank you for the work.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
As Mariano said, the interface is changing very slightly (I'm teasing apart some of the interdependencies). I'd recommend checking out the examples folders in svn.boost.org/trac/boost/browser/sandbox/libs/extensions and libs/reflections. For the modified reflection interface, check out basic_test.cpp in libs/reflections/test, which shows some of that code. I'm just working on getting the modified version Boost.Extension submitted. Thanks Jeremy; however, I'm having trouble using bjam --v2 in the doc
On 09/03/07 17:09, Jeremy Pack wrote: directory: <-------- cut here -------- Welcome to the Emacs shell /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ bjam --v2 gcc.jam:init-link-flags:toolset,condition= gcc , <toolset>gcc-4.1 gcc.jam:init-link-flags:toolset,condition= gcc , <toolset>gcc-4.3_v warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pbin/gcc-4.1/debug>reflection.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-reflection.xml.XML { reflection.qbk.QUICKBOOK } } error: created from ./reflection error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-reflection.xml.XML { reflection.qbk.QUICKBOOK } } error: created from ./reflection error: added properties: <python-debugging>off ... several more error lines ... /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/boost-build.jam:43: in module scope from module /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ echo $BOOST_BUILD_PATH /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2 /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ which bjam /home/evansl/prog_dev/boost-svn/ro/trunk/tools/jam/src/bin.linuxx86/bjam /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $
-------- cut here -------- Any ideas what I'm doing wrong?
TIA. -Larry
That problem is new - I saw it start showing up only a week ago, and I haven't made changes to those files for quite some time. What platform are you using? I had the same error on a Mac, but got the docs working fine on Ubuntu. Either way, I am going to submit the html files to the sandbox again soon. Sorry! For now, I'd recommend checking out the examples, or trying to read the .qbk files. Expect the regenerated html files to be checked in sometime within the next week. Jeremy On 9/3/07, Larry Evans <cppljevans@cox-internet.com> wrote:
As Mariano said, the interface is changing very slightly (I'm teasing apart some of the interdependencies). I'd recommend checking out the examples folders in svn.boost.org/trac/boost/browser/sandbox/libs/extensions and libs/reflections. For the modified reflection interface, check out basic_test.cpp in libs/reflections/test, which shows some of that code. I'm just working on getting the modified version Boost.Extension submitted. Thanks Jeremy; however, I'm having trouble using bjam --v2 in the doc
On 09/03/07 17:09, Jeremy Pack wrote: directory:
<-------- cut here -------- Welcome to the Emacs shell
/home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ bjam --v2 gcc.jam:init-link-flags:toolset,condition= gcc , <toolset>gcc-4.1 gcc.jam:init-link-flags:toolset,condition= gcc , <toolset>gcc-4.3_v warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Python location is not configured warning: the Boost.Python library won't be built Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pbin/gcc-4.1/debug>reflection.xml error: previous virtual target { quickbook%quickbook.quickbook-to-boostbook-reflection.xml.XML { reflection.qbk.QUICKBOOK } } error: created from ./reflection error: another virtual target { quickbook%quickbook.quickbook-to-boostbook-reflection.xml.XML { reflection.qbk.QUICKBOOK } } error: created from ./reflection error: added properties: <python-debugging>off ... several more error lines ... /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/boost-build.jam:43: in module scope from module
/home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ echo $BOOST_BUILD_PATH /home/evansl/prog_dev/boost-svn/ro/trunk/tools/build/v2 /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $ which bjam /home/evansl/prog_dev/boost-svn/ro/trunk/tools/jam/src/bin.linuxx86/bjam /home/evansl/prog_dev/boost-svn/ro/sandbox/libs/reflection/doc $
-------- cut here -------- Any ideas what I'm doing wrong?
TIA. -Larry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 09/03/07 19:54, Jeremy Pack wrote:
That problem is new - I saw it start showing up only a week ago, and I haven't made changes to those files for quite some time.
What platform are you using? Linux debian:
$ uname -a Linux debian 2.6.18-5-686 #1 SMP Thu Aug 30 02:19:07 UTC 2007 i686 GNU/Linux HTH [snip]
On 09/03/07 19:54, Jeremy Pack wrote:
That problem is new - I saw it start showing up only a week ago, and I haven't made changes to those files for quite some time. I'm trying to understand the problem by deciphering:
http://svn.boost.org/trac/boost/browser/sandbox/boost-build.jam?rev=39081 However, I see that file has: $(.boost-build-file:D)/../boost yet I see no definition of .boost-build-file. Would you please explain what that is. I'm guessing it's simply the absolute filename of the boost-build.jam file; however, I couldn't find any boost.build documentation supporting that conclusion. Also, that conclusion seems wrong because that would mean $(.boost-build-file:D)/../boost would be pointing to the wrong directory since the reflective boost header files are in the boost directory directly below where boost-build.jam is located.
Larry, I've seen other people post to the list about the problem. Could you post this under a more descriptive subject? This seems to be affecting the documentation of some other libraries as well. Also, I'm describing the progress of the libraries (Boost.Reflection and Boost.Extension) at boost-extension.blogspot.com, just to keep the details all in one spot. Jeremy Pack On 9/4/07, Larry Evans <cppljevans@cox-internet.com> wrote:
On 09/03/07 19:54, Jeremy Pack wrote:
That problem is new - I saw it start showing up only a week ago, and I haven't made changes to those files for quite some time. I'm trying to understand the problem by deciphering:
http://svn.boost.org/trac/boost/browser/sandbox/boost-build.jam?rev=39081
However, I see that file has:
$(.boost-build-file:D)/../boost
yet I see no definition of .boost-build-file. Would you please explain what that is. I'm guessing it's simply the absolute filename of the boost-build.jam file; however, I couldn't find any boost.build documentation supporting that conclusion. Also, that conclusion seems wrong because that would mean $(.boost-build-file:D)/../boost would be pointing to the wrong directory since the reflective boost header files are in the boost directory directly below where boost-build.jam is located.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Jeremy Pack -
Larry Evans -
Mariano Consoni -
Mariano Gabriel Consoni