The overarching characteristic of STLSoft is that it is lightweight. That sounds rather super, but what does it actually mean? Specifically, the STLSoft libraries share the following characteristics:

100% header-only - all components within the libraries are entirely defined within header files, meaning that users need only #include the requisite files to access the functionality.

Intersecting Conformance - similar, but not-identical, components from different projects (e.g. UNIX vs Win32) are structurally conformant (they share compatible syntax, and corresponding semantics, without being related by type) only to the degree of the intersection of identical functionality, rather than employing significant additional functionality to achieve total structural conformance. For example, though both the unixstl::filesystem_traits and winstl::filesystem_traits traits classes provide the stat() and fstat() operations, lstat() is provided only by unixstl::filesystem_traits.

Maximum Cohesion with Minimal Coupling - achieved by extensive use of generalising mechanisms, particularly shims, e.g. types that manipulate character strings are able to interact with arbitrary string types, not just char const* and std::string.

Very High Efficiency - Second only to Robustness, all components in the libraries are implemented with a view to maximum efficient. This is aided by the extensive use of efficient utility classes, such as auto_buffer, and scoped_handle.

It is important to note that STLSoft is not a framework. Each library component is as "thin" as possible to provide its given function. The intent is that STLSoft components are used as building blocks for writing higher level components - applications, classes, libraries, servers. STLSoft has been used extensively in the development of software in all these guises.

Projects delineate on technology area: the ACESTL project contains a number of libraries pertaining to the Adaptive Communications Environment (ACE), the UNIXSTL project contains a number of libraries pertaining to the UNIX operating system family, and so on.

Libraries delineate on technology area: the Performance library provides components that may be used in the instrumentation of code, the Windows Registry library contains components that can be used to manipulate the Windows registry, and so on.

What may not be as obvious is that a library may contain components from several different projects. For example, the Synchronisation library currently contains components from the , UNIXSTL project and WinSTL projects.

For all intents and purposes we can view the STLSoft libraries as a matrix of vertical context, the projects, and horizontal context, the libraries. A small subset of such a matrix might look as follows:

The STLSoft library distributions are located at http://stlsoft.org/downloads.html. Currently available are the latest official release, 1.8.9, and the latest beta for version 1.9.1.

Please note that version 1.9.1 brings with it a huge amount of refinement, including new components, a different directory structure and, last but not least, vastly improved documentation (of which you are currently looking at the latest revision).

Because the STLSoft libraries are 100% header-only their installation can require nothing more than selecting an appropriate directory and unpacking the distribution (making sure to preserve the directory structure). Use of the libraries then consists of nothing more than ensuring that the STLSoft distributions include directory is in the include path for your compiler(s) and including the required header files.

However, several of the dependent projects that are written by contributors to STLSoft assume the definition of an environment variable STLSOFT, whose value is the parent directory of the include directory, under which the project directories - include/stlsoft, include/acestl, include/comstl, and so on - reside. This facilitates the specification of include paths in dependent projects as -I$STLSOFT/include (UNIX) / -I%STLSOFT%\include (Windows). This is a good strategy generally, unless you choose to unzip the libraries under a directory included in your system INCLUDE paths.

For example, let's say you've unzipped the STLSoft distribution into D:\3Pty\STLSoft\1.9, such that you the following directory structure is evident:

In this case, you would define the environment variable STLSOFT with the value D:\3Pty\STLSoft\1.9. Now, when version 1.10 is released, you can unzip it into D:\3Pty\STLSoft\1.10, and change the definition of STLSOFT accordingly. In this way you make it possible (and simple!) to revert back to using version 1.9 should you need to do so.