This library is maintained by several developers, and in order it to have a
consistent design, look and feel, a few guidelines need to be followed:
The code is indented with spaces, 4 spaces per tab.
Namespace braces on the same line, all other braces - on the next line,
with the same indent. At the closing brace for a namespace, there is a
comment with the namespace name.
Namespaces don't increase the level of indentation. In all other cases
braces increase the level of indentation.
Member/base initialization list for constructors on the same line, if it's
small (1-2 members) or 1 member/base per line. Colon is left on the signature
No leading commas (i.e. if on multiple lines, initialization list and arguments
have commas at the end of line, not at the beginning).
Data member names start with m_, unless the enclosing struct only has public
data members (i.e. the intention of the struct is to enclose some data
with no further logic).
Template parameters are named in CamelCase, other symbol names follow C++
style (lower-case, with underscores).
All non-public headers should be placed into
directory. All non-public names should reside in the
namespace. All non-public macro names should start with
All public names should reside in the
namespace. Nested namespaces are also possible. All public macro names
should start with
User-definable config macros should start with
component selection, if any),
does not include macros the library defines itself as a result of various
compatibility checks (these count as non-public ones).
Every header includes
The config header contains all configuration macros, but no auto-linking
code. If the built library appears, the auto-linking machinery and macros
will be in a separate header, which will be included only by those components
that need it.
Every header includes
before any code (as the last include) and
after all code. These two files are for warning and ABI management.
All move semantics is implemented through Boost.Move.
All platform-specific code that depends on library configuration and can
have different ABIs should be enclosed in a nested inline namespace that
corresponds to the configuration. This gives a basic protection from the
library misconfiguration in the user's application.