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
The key element to configure this library is to make sure that TR1 (for C++03 mode) is supported correctly and the headers work in a manner similar to how they work in C++11:
- For C++03: The TR1 headers must be able to be
#included directly - by name only (such as
#include <array>instead of
#include <tr1/array>). Make sure adequate support for TR1 is enabled and the TR1 path is added to the compiler/project's
- 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]
(The following information applies only to C++03 mode)
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 an 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 way 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 priject before
cxxomfort/cxxomfort.hpp- but after
Of note however, trying this is NOT recommended and not supported; the alternative is offered here only so that it is available in extreme cases where it can not be done.
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 so 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]
(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.