+ * You probably should read @libevent documentation to get started or at least
+ * just for reference, although @eventxx is pretty simple so you can jump right
+ * into the \ref Example section (or the example list) and write a working
+ * program without much trouble.
+ *
+ * This wrapper was designed to be used just like @libevent, but with C++ style
+ * syntax sugar (or poison, depends on your point of view ;) and goodies. The
+ * main difference to libevent is you always have to instance a
+ * eventxx::dispatcher to get an event loop. There is no implicit global event
+ * loop. This adds just an extra line of code for single threaded applications
+ * and makes things much more simpler, so I hope nobody complains about it ;).
+ * See eventxx::dispatcher documentation for more details.
+ *
+ * You can use use the same plain functions callbacks @libevent use or the other
+ * kind of function objects (see @ref events section for details on event
+ * types).
+ *
+ * @eventxx uses @ref exceptions to report errors. All functions have exception
+ * specifications, so it's easy to find out what to expect. See @ref exceptions
+ * section for more detail.
+ *
+ * A @c timespec abstraction is provided as eventxx::time for convenient
+ * argument passing. Even more, it's a @c timespec itself, with some convenient
+ * methods for accessing the attributes with pritier names. And even more,
+ * @eventxx is such a direct mapping that all eventxx::event's are @libevent
+ * event structs too, so theoretically you can pass a eventxx::event to
+ * @libevent C functions without much trouble. eventxx::dispatcher is the only
+ * class that is not derived from @libevent struct (@c event_base) because this
+ * struct it's not defined on the libevent header (just declared).
+ *
+ * Maybe you shouldn't know this implementation details to keep the abstraction,
+ * but this is a basic design goal of this wrapper so there is not much chance
+ * that this changes in the future (but use this knowledge with care, you have
+ * been warned ;).
+ *
+ *
+ * @section Example
+ *
+ * @code
+ * #include <eventxx>
+ * #include <iostream>
+ * #include <csignal>
+ *
+ * struct handler
+ * {
+ * eventxx::dispatcher& d;
+ * int i;
+ * handler(eventxx::dispatcher& d): d(d), i(0) {}
+ * void operator() (int signum, short event)
+ * {
+ * if (i < 5) std::cout << "keep going...\n";
+ * else
+ * {
+ * std::cout << "done!\n";
+ * d.exit();
+ * }
+ * }
+ * };
+ *
+ * void sighandler(int signum, short event, void* data)
+ * {
+ * int& i = *static_cast< int* >(data);
+ * std::cout << ++i << " interrupts, ";
+ * }
+ *
+ * int main()
+ * {
+ * eventxx::dispatcher d;
+ * handler h(d);
+ * eventxx::csignal sigev(SIGINT, sighandler, &h.i);
+ * eventxx::signal< handler > e(SIGINT, h);
+ * d.add(sigev);
+ * d.add(e);
+ * d.dispatch();
+ * return 0;
+ * }
+ * @endcode
+ *
+ * You can see more examples on the test directory of the distribution or on the
+ * examples related page.
+ *
+ *
+ * @section Status
+ *
+ * This library has not been widely used yet, so it lacks proper testing.
+ * Because templates are not even compiled when they are not used, don't have to
+ * be surprised if you catch a piece of code that doesn't compile. The library
+ * has no support for buffered events yet. It doesn't support the HTTP stuff,
+ * and probably never will because that has nothing to do with event handling.
+ *
+ * If you notice that when using @eventxx your program leaks some memory, don't
+ * blame me, blame @libevent :) @libevent has a known bug on @c event_base_free()
+ * that makes it assert always, so @c event_base_free() is unusable, unless you
+ * patch your libevent (for example, using this <a
+ * href="http://monkeymail.org/archives/libevent-users/2006-April/000141.html">patch</a>
+ * written by Mark D. Anderson, and who knows why it's not still applied). If
+ * you do so, you can compile your programs with @c -DEVENT_BASE_FREE_FIX so
+ * @c event_base_free() gets called in the eventxx::dispatcher @link
+ * eventxx::dispatcher::~dispatcher() destructor @endlink.
+ *
+ * That said, I think it's still pretty usable anyways. If something is broken
+ * it would be really easy to fix because @eventxx is just a simple wrapper
+ * around @libevent. So, please try it out, and if you have any problems,
+ * <a href="mailto:llucax+eventxx@gmail.com">drop me an
+ * e-mail</a> and and I'll fix it ASAP (or provide a patch and you will be my
+ * best friend ;).
+ *
+ * Patches to support buffered events are welcome too.
+ *
+ *
+ * @author Leandro Lucarella <llucax+eventxx@gmail.com>