Abstract
The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts.
My proposal has two parts:
- Bring Boost.Extensions [1] to completion and enhance it
As I will say in the next sections, I wanted to add to Boost a library that allows an application to have dynamic plugins/extensions within an infrastructure.
A member of the Boost mailing list told me about a library by Jeremy Pack called Extension. Jeremy and I agreed that the best approach would be to complete and enhance this library. In short, the completion consists in preparing the library to be sent for review in Boost. The enhancements are several, and will be described later.
- Implement Reflection [2] using Extensions functionality
The Extensions functionality is the perfect platform to implement Reflection in C++. I've analyzed several papers about this topic and having Extensions complete will be great to start building this new features. Also, the Boost Community showed a great interest saying that it would be a great addition to Boost. Discussing Reflection with Jeremy we agreed that it could be very useful to use the dynamic (run-time) method loading features in Extensions to give reflection functionality to normal C++ classes. I'll detail this point later.
Proposal history
Last year, I've been working in a GIS project. It needed a very open architecture, and our decision was to implement some kind of software plugin infrastructure. This project was being written in C++ and with a very intensive use of Boost. At that point, I checked out if Boost had a Plugin Library.... without results.
So I designed and implemented an original infrastructure. It was useful and I've learnt a lot during the development. Also I've noted its pros/cons.
Since that time, I have been thinking about adding an Extensions library to Boost, because I really like Boost philosophy, and I use it very frequently (nowadays I'm using it in at least three C++ projects, and advocating its use to my colleagues).
Luckily, Summer of Code 2007 was about to start. Then I tried to get in touch with the boost community. Since early March I've been discussing my ideas in the lists with positive feedback. They showed a lot of interest and, as I said before, quickly pointed me out that there was some work done in that area. With more luck, Jeremy contacted me very quickly.
We started to work together that week. I started to review his approach and he checked some of my old code. Obviously, his approach is simpler, more concrete and really clean. He told me that my code was very clear too, comparing it with another libraries.
Then, we started to set the concrete goals for the project. The result of that work is this proposal.
Detailed objectives
Objectives could be split in two parts. My first goal is to bring to completion Boost.Extensions and then explore Reflection functionalities.
Some of the improvements that are needed to complete Boost.Extensions (in order to submit it for revision) were addressed in our work with Jeremy. I think that some more will appear when we start the work.
Then the actual tasks of this part are:
- Preprocessor techniques to remove template redundancy. Nowadays some parts of the library
are duplicated because the use of variable-arguments templates. The idea is to use the preprocessor library to avoid this. I've done it in another project, so I think that it'll be easy (but costly).
- Provide (optionally) automatic closing of unneeded linked libraries. We think that
this feature is important for many people to justify adding it in the standard library. Also, it can be added with 'convenience' functions quite smoothly - just as smoothly as directly adding the functionality.
- Various integrations with other Boost libraries for convenience (like boost::function).
- Finish up documentation.
- Write lots of more unit tests, as well as larger tests.
- Submit to Boost for review.
Having that complete, I'll focus on the Reflection part. My main idea is allow the C++ programmer to access a meta-level infrastructure where he/she can load new classes/methods at run-time and get information about them.
For that purpose I need to define an API that allows exporting methods and then the infrastructure to load them on demand. The difference with the Extensions approach is that in this part this methods won't be a virtual function declared in a base class. I mean, you should export the methods that could be used to access this meta-level and then Extensions will have the responsibility of loading the necessary dynamic shared objects. Additionally, this will allow creating objects that aren't derived of any class of the executable; instead they are loaded on demand from a linked library.
A possible use of this API could be, for example, the development of a C++ 'interpreter'.
Another interesting line of work could be having the ability to compile code at runtime and use it ( i.e. compile it into a linked library and link to it at runtime). If bjam was required to be in the path, and BOOST_BUILD_PATH was all set up, this just might work well.
I know that this objectives are big but really interesting. I'll detail in the schedule and deliverables section what I want to achieve for sure, and what could be developed if the time allows me.
Schedule
- Weeks in the interim period between being accepted as student and program start
Try to get more and more feedback from the community and try to detail the
plan with Jeremy and my mentor. Maybe some prototype could be done if I have spare time.
- Week 1
Do a careful study of Boost.Extensions. I've checked it out, but I need a deep understanding before starting. Get in touch with my mentor (as with Jeremy I'm in touch nowadays). See carefully the requirements to review the library.
- Weeks 2 - 4
First tasks, 1. to 3., and task 5. Initial unit tests will be written.
- Weeks 5 - 6
Finish the first part (tasks 4. to 6.), submitting the library to boost for revision.
- Weeks 7 - 8
Explore reflection and do the first prototypes of the functionalities. Make some units tests along the development.
- Weeks 9 - 10
Go on with reflection, trying to fit it as a working and useful library.
- Weeks 11 - 12
Fix bugs. Document. Make more unit tests. According to the remaining time add some functionalities of the other optional tasks. Plan the future after-program work.
References
[1] Boost.Extension: http://sourceforge.net/projects/boost-extension/
[2] Some reflection ideas: http://www.vollmann.com/pubs/meta/meta/meta.html
[3] Boost mailing list
