CppModules » History » Revision 9
Revision 8 (hazzadous, 2009-04-08 00:26) → Revision 9/14 (hazzadous, 2009-04-12 00:43)
h1. Including C++ libraries and code within your lighttpd modules
h2. Seeing in to the plugin
To load compiled modules, lighttpd needs a few things. Its point of entry to your code is the plugin_init function, which will be responsible for setting up plugin info like name, version etc. as well as other hooks into your plugin like init, the handlers etc. To access plugin_init, lighttpd looks for the C style symbol in your binary ( i.e. mod_rewrite_plugin_init ). As we have to compile with C++ support, we need to tell the compiler explicitly to use the C style name for this function so lighttpd can access it.
h2. Setting up hooks
Once we can call plugin_init, and plugin has been passed into our module, we have to set up the hooks. Problem here is that these hooks in the plugin data structure are C style function pointers. There is no guarantee that it will have the same calling conventions as a C++ function pointer (will vary from compiler to compiler). To be totally accurate any function we choose to point these at should use the same calling conventions.
To tell your C++ compiler to use C symbol names and calling conventions, use extern "C" { /*...*/ } around the function prototypes for plugin_init and your hook functions. ( you can probably get away with omitting it from the hooks, but you may get unexpected results with some compilers. )
h2. Incompatibilities
Unfortunately there seem to be some type incompatibilities when using a C++ compiler and lighttpd 1.5. There are a few struct types in base.h that have variables of the same name. It doesn't seem practical to change these, as they are pretty omnipresent, and as enabling C++ support doesn't seem to be a priority I think its probably a good idea to create a C++ compatibility library to be included instead. See the included *_compat.hpp files for what I am working on at the moment. Place these in src/c++-compat along with base.h, plugin.h etc. (sorry for the hpp extension, but if no one else is interested, I'm keeping it that way.)
h2. Some helper classes
Of course to use C++ in your module you can do what you want, as long as your plugin_init has C linkage. However, I presume that if you are considering using C++ for your module, then a more C++ way of doing things would not be out of place. I see no reason not to supply such a thing given that it will probably attrach more C++ developers interested in lighttpd. However, anything like this will probably remain a 3rd party component for the foreseeable future. Attached are my initial contributions to the subject. If you are interested in working on it then I trust you can read the code in plugin.hpp, handler_helpers.hpp to see how things work. Otherwise, just look at mod_blank.hpp and mod_blank.cpp to see how things look to the module developer. It will not compile at the moment as I am working on datatype_helpers.hpp
h2. Unit Testing
I'm currently making a UTF for C++ modules using the Boost UTF. I know that some are adverse to the inclusion of boost dependencies, however, I assume that if you are wanting to utilize C++ features, then you also consider boost to be an excellent way of doing this. There is of course the testing included in lighttpd for testing some more high level code. What I'll do here is just offer things like test config_context etc to pass to your functions for testing.
[[CppHelperClasses]]