Thursday, August 30, 2007

I finally have the redesigned functionality for reflection. It's not done certainly, but the following will compile and work correctly. I'll be committing this to the SVN repository soon.

Here's how it works:

/////////////////////////////////////
// In your code that reflects some class out:

class MyClass {
public:
  int myFunction();
}
// For terseness
using namespace boost::reflections;
generic_reflector * exportMyClass() {
  reflector * myClassReflector =
  new reflector;
  // reflect an arg-less constructor
  myClassReflector->reflect_constructor();
  // reflect the member function
  // with some info about it
  // note that like boost::extensions,
  // the info parameter is templated
  // with a string as the default
  myClassReflector->reflect_method(&MyClass::myFunction, "myFunction");
  return myClassReflector;
}


///////////////////////////////
// Now in the code that will use the reflection
// (This code could be in a DLL, or the top code could be in a DLL etc)
using namespace boost::reflections;
  int main(int argc, char * argv[]) {
  // A reflection must be created with a pointer
  // to a generic_reflector
  // The reflection will destroy the generic_reflector
  reflection myReflection(exportMyClass());
  // Create an instance with a default constructor
  instance inst = myReflection.get_constructor().call();
  // Find the function with an int return value and
  // info of "myFunction" and call it.
  function func =
       myReflection.get_method("myFunction");
  // Call func on inst
  func(inst);
}



////////

Thursday, August 23, 2007

One conversation from the Boost Mailing list contained a lot of the rationale behind both libraries. The basic design goals were the following, in order of importance:

  1. Cross-platform (this is Boost - it has to be)
  2. Concise, natural interface (no macros, etc.)
  3. Minimization of dependencies on other Boost libraries
  4. Separation of optional features of the library from the primary headers
  5. Performance
Number 3 was difficult, and we've decided to probably require inclusion of Boost.Preprocessor. Constructors or other functions with many arguments require a lot of template code that is much easier to just generate using Boost.Preprocessor. Boost.Function will probably be required as well.

For some of the original discussion on some of these design decisions, see the discussion that began with Mariano's interest in writing a plugin library for the Google Summer of Code:

Current Progress

Mariano Consoni has been working on both Boost.Extension and Boost.Reflection over the summer. Our current status on these two projects:

1 - Boost.Extension is mostly complete. One piece of functionality that I have not finished is the ability to automatically close shared libraries that do not currently have any loaded plugins. The main obstacles here are preserving the current Boost.Extension syntax and overcoming some platform irregularities (on Mac OS X there are two types of dynamically linked library with very different properties - bundles and dylibs).

2 - I am currently working with the code that Mariano wrote for Boost.Reflection to make it a bit more generic and do some cleanup and performance tuning.