The cxxomfort library should hardly require configuration depending on the compiler and system you use. However as of 2017 only GCC 4.6 ≤ < 6.0 and MSVC 2008 / 2010 are *officially* tested for. More information will be added here as more compilers are tested.
General configuration procedure
- Add the cxxomfort/ path to your compiler/project's
If your compiler does NOT provide TR1:
(I'm looking at you, MSVC 2008 Express)
You might be able to get past it by installing a third party TR1, such as Boost's, provided it supports at least array, tuple and type_traits. Such configurations are not supported officially and not tested for, however.
To add the path to a compile command, use the
g++ [...options] -I /path/to/include/cxxomfort/ [...sources]
In C++03 mode only:
GCC incorporates the TR1 headers (
<array> etc) in the
tr1/ subdirectory. Unfortunately, because of the way the headers themselves are coded, they don't work when they are added to the compiler
#include search path. See GCC bugzilla and report about stl_list.h for more general information. The tl;dr of the problem is that adding TR1 to the
#include path causes ambiguity errors in declarations that can not be solved without patching the non-TR1 headers themselves, such as
Since GCC considers Tr1 "not worth fixing", which given its age makes sense, it is instead recommended to use a TR1 forwarder such as tr1_fwd, which is the supported and tested-for configuration in GCC C++03 mode. Alternatively, one can use an alternative Tr1 implementation such as Boost.Tr1.
Alternative: Patching system headers note
If one does not wish to add further dependencies to the project, and due to the way the TR1 headers are themselves coded, the fallback to skirt around the issue is to make sure that code that uses the ambiguous symbols (in
stl_list.h among others) is somehow made to see only the base implementation required and not the TR1 one.
There are two ways around this issue detailed in the following issue: (link pending):
stl_list.hand other such files to refer to the namespace or object by full name, or...
- Make sure that the system headers affected such as
<list>are #included into the project before
cxxomfort/cxxomfort.hpp- or before any other cxxomfort header except the ones described in "Base Features", that is
cxxomfort/base.hppand a few others.
Of note however, trying this is NOT recommended and not supported.
Configuring with clang
-I switch to add to the compiler path:
clang [...options] -I /path/to/include/cxxomfort/ [...sources]
For the most part this will be setup and work exactly as it does in GCC; however, it might be necessary to patch a couple of header files from the tr1/ implementation if using clang alongside GCC 4.6 or earlier (more specifically, to deal with the declarations of some of the new
cmath functions). Patching the libraries or providing other fallbacks falls outside the scope of this document.
Configuring with MSVC
-I switch to add to the compiler path:
cl.exe [...options] -I /path/to/include/cxxomfort/ [...sources]
If your version of MSVC comes without
<stdint.h> (such as the Express version of MSVC 2008), you can simply copy another version. Among other alternatives you can take any of these sources and save it in the VC include directory as
- Copy one of the various alternative stdint.h sources like the ones described here or here.
- Download the "portable stdint.h" described here (
pstdint.h) and save it as stdint.h.
- Copy the version of pstdint.h already included in cxxomfort (under
(The following information applies only to MSVC 2008)
MSVC 9 (2008) Express does not ship with a tr1 implementation, thus lacks, among the most important features, a
<type_traits> implementation. This is partly solved by cxxomfort providing its own type traits, but this should not be relied upon by client programs. cxxomfort code using features from
<functional> will most likely fail to compile without an alternative TR1 implementation.
Some sources say the MSVC9 Feature Pack can be installed to provide a working tr1 implementation; however this can not be installed in 2008 Express and thus Feature Pack setup is not tested or coded for; if using Express, it is up to you to provide a working TR1 implementation via boost, stlport or similar (tests were run via a pared down version of Boost.Tr1).
On the other hand, MSVC 2008 Express SP1 comes with a partial, but working for our purposes, TR1 implementation.