<h1>Per-Compiler Notes</h1>

Notes about setting up cxxomfort, and the support available, on different compilers and setups.

The notes take into consideration following the setup available in [Installation] for the testbed compilers.

<div style="width:100%; margin: 2em auto;"><span style="font-style: sans-serif;">
[#notes-gcc] -- [#notes-msvc] -- [#notes-clang] -- [#notes-dmc] -- [#notes-ow] -- <b>[#general|general notes]</b>


<hr/>

<a id="notes-gcc"></a>
<h2>GNU GCC</h2>

<h3>TR1 Implementation</h3>

For C++<11, GCC sets up <b>TR1</b> components as files in the include path and the features under the <tt>std::tr1</tt> namespace. Cxxomfort sets up the macro <tt>CXXO_namespace_tr1</tt> to the later value.

Unfortunately the TR1 headers are coded in such a way that it is not possible to add them to the <tt>#include</tt> search path. See for the local  report, bugzilla] for the associated bug and about stl_list.h] for more general information. The tl;dr of the problem is that adding TR1 to the <code>#include</code> path causes ambiguity errors in declarations that can not be solved without patching the <i>non</i>-TR1 headers themselves, such as <code>stl_list.h</code>.

Since GCC considers Tr1 "not worth fixing", which given its age makes sense, it is instead recommended to use a <b>TR1 forwarder</b> such as  which is the supported and tested-for configuration in GCC C++03 mode; or any other TR1 forwarder set up by the user.

As of 2019-01-01 it is undecided if Cxxomfort will package its own TR1 forwarder.

<b>Associated reports:</b>

  *  [/ticket?s=TR1]
  *  [5a9e81910ede7e3e1f77].


<h3>Short <tt>enum</tt> Types</h3>

GCC supports the <tt>-fshort-enums</tt> flag which allows enumeration types to use as a base types shorter than <tt>signed/unsigned int</tt>. Note that when this flag is enabled, the default implementation of typesafe enumeration types using <tt>library::typesafe_enum</tt> might change.

<div style="display:none;">User code can check the result of <tt>sizeof(cxxomfort::fix::short_enum)</tt> to determine if short enums are enabled or not.</div>


<h3>__typeof__</h3>

GCC >= 4.0 implements the <tt>__typeof__</tt> extension in all Standard modes, which returns the type corresponding to an expression: it is basically an earlier alternative to <tt>decltype</tt>.

Cxxomfort declares the <tt>CXXO_TYPEOF(expression)</tt> macro to return <tt>__typeof__</tt> of the expression in C++03 mode, or <tt>decltype</tt> of the expression in later Standards.


<hr/>
<a id="notes-msvc"></a>
<h2>Microsoft Visual C++ Compiler</h2>

<h3>TR1 Implementation</h3>

MSVC 2008 ships without a TR1, and thus is unsupported.

MSVC 2008 <b>SP1</b> ships with a TR1 implementation that is functional for Cxxomfort's requirements. The implementation uses the same header files as the normal C++ headers, as such MSVC does not require a TR1 forwarder or any other special treatment; also the features live in the <tt>std::tr1</tt> namespace. Cxxofort defines the macro <tt>CXXO_namespace_tr1</tt> to this later value so that features such as <tt>hash</tt> can be pointed to.

MSVC 2012 and later do not have a <tt>std::tr1</tt> namespace.

<h3>MSVC 2010 <tt>std::common_type</tt> </h3>

MSVC 2010 and 2010 SP1 ship with a broken implementation of <tt>std::common_type</tt> that is not variadic, and can only take two types. Because this means that the name <tt>common_type</tt> is used, Cxxomfort can not extend this feature to more template arguments.

Code wanting to transparently use <tt>common_type</tt> can instead use which will forward to the correct implementation (std or cxxomfort) depending on compiler version.

<h3>No typeof</h3>

MSVC < 2010 lacks any semblance to a <tt>__typeof__</tt> mechanism. As such, code using <tt>CXXO_TYPEOF</tt> or <tt>CXXO_DECLTYPE</tt> will fail to compile. Note there is an <tt>extras::</tt> feature that allows for an "auto" hack in MSVC 2008, but it is only a partial solution.


<hr/>
<a id="notes-clang"></a>
<h2>Clang</h2>

Most of the notes valid for GCC are also valid here.

<h3>clang-libc++</h3>

Cxxomfort has <b>not</b> been tested with Clang using libc++, and has no support for it as of the [check-in: b64fff24|last 2018 release].

<h3>Rvalue-References</h3>

Clang supports C++11 rvalue-references as an extension in C++03. Cxxomfort may or may not pick rvalue-reference constructors in C++03 when using Clang, but no guarantees are provided.


<hr/>
<a id="notes-dmc"></a>
<h2>Digital Mars</h2>

<h3>Lacking C++ Support</h3>

The compiler supports a limited subset of C++, lacking features such as inline struct initialization, template constructors and template conversion operators (see "Template Support" below). Because of this, as of latest 2018 releases of Cxxomfort <b>the library is not guaranteed to compile</b> beyond the Base featureset.


Digital Mars provides minimal support for the <tt>decltype</tt> feature, although it lacks some of the corrections from later revisions such as decltype 1.1. Cxxomfort defines the macros <tt>CXXO_TYPEOF</tt> and <tt>CXXO_DECLTYPE</tt> to use this feature.

<h3>Template Support</h3>


<hr/>
<a id="notes-ow"></a>
<h2>Watcom 1.9 / OpenWatcom (beta)</h2>

<h3>Lacking C++ Support</h3>

The compiler supports a limited subset of C++, lacking features such as inline struct initialization, template constructors and template conversion operators (see "Template Support" below). Because of this, as of latest 2018 releases of Cxxomfort <b>the library is not guaranteed to compile</b> beyond the Base featureset.


Watcom defines <tt>NULL</tt> as integral zero, and also lacks template conversion operators; as such, <tt>nullptr</tt> can not be implemented as per C++11 official backport. For this compiler, Cxxomfort defines <tt>nullptr</tt> to be integral zero, and <tt>std::nullptr_t</tt> as an empty type with an implicit conversion to integral zero.

<h3>Template Support</h3>


<hr/>

<a id="general"></a>
<h2>General Notes</h2>

<h3>Compiler Lacks Basic C++ Support</h3>

<h3>Template Support</h3>


<h3>type_name</h3>

Using the <tt>library::type_name</tt> and <tt>typeid_demangle</tt> features require typeid support and thus RTTI to be enabled.  (Though an assist using type index] is under study)

Note 2019-02-01: Removing the RTTI requirement for <tt>type_name<T></tt> on compilers that implement some sort of function-name reflection (such as <tt>__PRETTY_FUNCTION</tt>) is being considered.

<hr/>

→ <b>Proceed with the [Configuration]</b>