D 2019-02-03T19:21:09.910
L Per-Compiler\sNotes
P 6ef4b8c52753476931a465604b22bb26883df1b2d606f5f26e7fd1582a6eeb47
U luismachuca
W 8569
<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|GNU GCC] -- [#notes-msvc|MSVC] -- [#notes-clang|CLang] -- [#notes-dmc|Digital Mars] -- [#notes-ow|Open Watcom] -- <b>[#general|general notes]</b>
</span></div>
<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 <tt>tr1/</tt> 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 [8ee003badda1c6033919702ac729de7c00ceb6b1] for the local report, [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36428|GCC bugzilla] for the associated bug and [http://lists.gnu.org/archive/html/adonthell-general/2011-07/msg00006.html|report 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 <tt>[http://chiselapp.com/user/lmachucab/repository/tr1_fwd|tr1_fwd]</tt>, 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 <b><tt>[Features/Fixes|cxxomfort::fix::common_type]</tt></b> 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.
<h3><tt>decltype</tt></h3>
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) and the proper base classes for the <tt>istream</tt> and <tt>ostream</tt> families. Because of this, as of latest 2018 releases of Cxxomfort <b>the library is not guaranteed to compile</b> beyond the Base featureset.
<h3>basic_istream, basic_ostream</h3>
Watcom 1.9 only supports the <tt>istream</tt> and <tt>ostream</tt> classes as sole classes, not templated on char type, and they inherit from <tt>ios</tt> rather than <tt>basic_ios</tt>; hence code that depends on prototypes for <tt>basic_istream</tt> or <tt>basic_ostream</tt> will fail to compile.
As of latest 2018 release Cxxomfort does not make any attempt to provide a <code>basic_[i/o]_stream</code>.
<h3>No TR1 Support</h3>
Watcom 1.9 / 2.0 beta has no support for C++ TR1 or its headers. As such <tt><array>, <cstdint>, <tuple>, <type_traits></tt> all required by Cxxomfort are missing.
A future version of Cxxomfort will include a set of supplemental headers to add to the compiler's search path.
<h3><tt>nullptr</tt></h3>
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><tt>#pragma</tt></h3>
When using the macro <tt>CXXOMFORT_NOTICES</tt> to enable compilation logs, Cxxomfort makes use of <tt>#pragma</tt>s in order to emit the messages. It is implementation-defined by each compiler whether those notices are interpreted to be compilation messages or compilation warnings (which show in the build logs). As such, when setting <tt>CXXOMFORT_NOTICES</tt> on a project that uses such options as "treat warnings as errors", <b>compilation should be expected to fail</b>.
<h3>type_name</h3>
Using the <tt>library::type_name</tt> and <tt>typeid_demangle</tt> features require [https://en.cppreference.com/w/cpp/language/typeid|typeid support] and thus RTTI to be enabled. (Though an assist using [http://brotherst-code.blogspot.com/2015/10/how-to-get-typeindex-without-rtti.html|compile-time 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>
Z 40643db1f8d673b2908a540bcd07d02b