Goals that influence the design of this library.

• The API should be well documented and tested. Every public symbol is documented with doxygen and includes all pertinent information about what it does, how it relates to other parts of the library, restrictions and caveats, etc. This kind of information is not evident from the C++ interface itself and is often omitted in other libraries' documentation.

• The library should be easy to use yet highly configurable. Common things should be simple and terse, but less common things should still be possible without significant work. Users should not have to worry about who owns what objects–the library uses reference counting pointers to control deallocation. The library should use a consistent naming scheme. It should avoid extensive use of templates since they're a common cause of difficulty for beginners.

• The library should be familiar to experienced C++ programmers. It should use the facilities of the C++ language, C++ idioms, and an object oriented design. The API should not look like a C library being used in a C++ program, and the library should not be concerned about being used in languages that are not object oriented.

• The library should be safe to use. Errors should be handled in clear, recoverable, and predictable ways. The library should make every attempt to avoid situations where the user can cause a non-recoverable fault due to misunderstanding the API.

• Functionality is more important than efficiency. Every attempt is made to have an efficient implementation, but when there is a choice between functionality and efficiencey, functionality wins.