Save time. Save effort. Let s11n save your data, man.
Project powered by:


Note that this code is no longer maintained, as it was rewritten from scratch for s11n 1.2.x. That doesn't mean that this code doesn't work, but does mean that it has been obsoleted. If you are interested in the "latest thinking" on implementing a classloader in C++, grab libs11n and see the files: src/s11n/factory*.hpp and (for DLL support) src/plugin/*.?pp.

libclass_loader is a rather non-conventional classloader, taking advantage of relatively recent C++ techniques which were not possible only a few years ago to provide an easy-to-use, non-intrusive, linkage-agnostic and 100% type-safe classloading toolkit.

You can find a paper describing this general model of C++ classloader on our Papers page.

Download from:

The downloads page.

Development Status:

Officially Beta, but quite stable and usable. There is still some experimentation to do, but the client-side interface is about as close to "1.0" as it is likely to ever be.

Primary features

  • Provides a flexible, easy-to-use, project-neutral approach to classloading.
  • Any classes can be made loadable, the primary implication being that third-party (i.e., uneditable) classes can be made classloadable. e.g., it can load Qt or GTK objects just as easily as it can your classes.
  • It is inherently immune to name collisions, symbol-name snafus and mis-casts from void pointers, all of which are potential problem-points for conventional classloaders.
  • It sports compile-time type-safe classloading without the use of a single cast, neither in client code nor in the library. Quite non-intuitively, this 100%-effective type-safety also applies to classes loaded via DLLs. (Please RTFM before saying that compile-time type safety for classes loaded at runtime is not possible! ;)
  • Enforces no arbitrary linking conventions on classloadable classes. i.e., clients are free to link their classes as standalone or multi-class DLLs, into their main application, or (almost) however they wish (there are some caveats when building them as static libraries, due to the way "unused symbols" are ignored when linking them). Likewise, loading classes is handled identically, regardless of their linkage.
  • Not restricted to using strings as lookup keys: the key type is defined as a template parameter. This is useful for, e.g., mapping Enum entries to classes.
Minor features:
  • The cllite interface encapsulates most classloading features into a simpler interface, and eases the loading of DLLs, including support for mapping class names to DLL names using client-side logic via functors.
  • Comes with an abundance of documentation, in the form of API docs and a library manual.
  • Designed primarily with ease-of-use and non-intrusivity [is that a word?] in mind.
  • Classloaders can optionally use shared instances of the classes they serve, which is sometimes useful when when using class_loader as, e.g., an event handler dispatcher.
  • Uses only standard C++ constructs, no compiler-specific extensions.
  • DLL loading internally uses lt_dlopen(), if available, otherwise dlopen(), so it should be portable to most Unix-like systems.
  • Fairly small: only a couple significant classes, a handful of methods, and a small number of internal helper classes. However, as it is template-based, compile times and object/binary file sizes will suffer.
It may be worth noting that many of these features are only possible because the toolkit is firmly rooted in the 21st century, not restricted to historical conventions and antiquated practices. This frees it up to take advantage of features which, until relatively recently, were not available to users of lower-level languages like C++. For example, the seemingly impossible feat of no-casts-required, compile-time type-safety for classes loaded via DLLs.


  • The phoenix class, available on the downloads page.
  • Recent, ISO-conformant C++ compiler. Only tested with with GNU gcc 3.{2,3,4}.x, and will not work with gcc 2.9x. Based solely on what i've read, i think MSVC++ 7.0 and lower are also out of the question.
  • GNU versions of most common Unix system tools, like make, find, bash, etc.
  • Only tested on Linux systems. Your mileage may vary on other OSes. That said, it uses no Linux-specific source code but the build tree itself is very GNU-centric.
  • Either libdl or libltdl. These are used for opening DLLs, and are pre-installed on all modern Unix-like environments, including Cygwin. (That said, i have been unable to link this library under Cygwin, for reasons beyond my comprehension. Help?)
A more detailed list of requirements is given in the library manual, available in the download tarball.