Lighttpd

There's no need for multiple APIs. Mostly, you should be able to just extern "C" your module_init, and the headers.

There are some C++ compatibility issues in 1.5, though: base.h declares member variables with the same name as a structure name. I'd recommend renaming struct http_req, request, physical, response and stat_cache (at least) to request_t, etc; although C allows this name aliasing, it's not a great thing to do.

Other than that, add AC_PROG_CXX to configure.in.

Thanks for the info peto, I'll look into the base.h issues. I'm just looking at skeleton hpp, cpp's much like the mod_skeleton.c, and try to push as much shared functionality (ie. populating the plugin config) into a shared base. I'll have a look over the weekend.

since you do need exceptions for production C++ code

I guess Trolltech disagrees... Qt is build without exceptions.

Sure I'll use .h if you want. Using vim with 4 space tabs here. I'm using tabs as opposed to spaces for alignment, which could be the problem.

I'll use boost for now. It does what I want. I can remove dependencies later. If you can enlighten me as to your views on boost it would be most appreciated.

For some reason, I did not think of using p_d to identify the plugin object. This removes a lot from my plugin_base. I'm now sure how safe it is to be using pointers to static member functions.

The main reason for the complexity is that I wanted to hide as much as possible from derived plugins. So all that the plugin developer would need was to specify which handlers he has with the handlers typedef, and Plugin would deal at compile time, with the code to set the plugin data structure. Where as with your code, as you say, it would be setting all the handlers to run your virtual functions. I'm not sure how much of a performance hit this would have, or whether the compiler can optimise these calls out.

Other functions that are almost always there I have added as virtual functions. The set_defaults for instance. When I was looking at mod_lvhost, the set_defaults had a lot of boiler plate code, things that I wasn't interested in. This I was hoping would also be movable in to Plugin or plugin_base such that we need only specify the mappings "config-option" -> data member and their defaults either as data, or as a function of the other config options, and actual filling is done behind the scenes.

Mostly this is just me playing. If you think something like your example is more appropriate, I'm happy to go with that.

static member functions are just normal function in a separate namespace.

and just as a sidenote: although we may fix C++ compatibility issues, i don't think we will add c++ code upstream; i recommend adding a wiki page with the details.

Although it will work most of the time, really it should be an extern "C" free function. Depends on calling convention compatibilities.

Sure, no problems. I'll start a wiki page.

If you write C++ code like C--using malloc instead of new, and not using ctors--then you can get away without exceptions. But, try main() { while(1) new int¹⁰²⁴⁰⁰; } with -fno-exceptions; it'll rudely abort() when it runs out of memory. (I had some recollection of new returning NULL on OOM when exceptions are disabled, but that's not what's happening.)

Much of Boost encourages template hell, which leads to bloated code that's hard to debug and usually hard to understand.

I'm sure the overhead of setting callbacks that you're not using will be miles below the noise floor.

The main reason for the complexity is that I wanted to hide as much as possible from derived plugins

But what you're really doing is creating an entirely new API. I don't think that's necessary--the existing API isn't complex at all, so all it's doing is making it harder for people using one API to understand code on the other, and creating a lot more work to maintain it over time, as the main API evolves.

Also, module authors are generally writing code that's tightly tied to the server itself: to figure out what's going on I usually need to trace back into the server code itself, to figure out how to make it do what I want. Having a complex layer standing between my code and the server makes that harder.

Although it will work most of the time, really it should be an extern "C" free function. Depends on calling convention compatibilities.

I'm fairly sure that you can't have different calling conventions for an extern "C" function and static member functions. That would imply that they aren't compatible types, and the compiler wouldn't allow the assignment in the first place; C++ is pretty strict about not performing questionable implicit casts, and I've never seen so much as a warning doing this. It would also imply that there's a way to declare "pointer-to-extern-C-function" vs. "pointer-to-static-member-function", but there isn't.

I consider failed allocs always fatal, so i have no problem with abort(); and that is btw. exactly what glib is doing too.