Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Artifact ID: | 43dde6d8e6b50d7af8ba81fc685826d8d3f66f0811783755604c946c1827929a |
---|---|
Page Name: | Per-Compiler Notes |
Date: | 2019-02-03 14:51:23 |
Original User: | luismachuca |
Parent: | 8b954a8f2dc0b21f21f14ca97f7a8e311257af08d5e325e301411709a67c5b4f (diff) |
Next | 3154605e1dea56109f8a42a0a0113a180625112872955f5c64e1bcdd37d92a62 |
Per-Compiler Notes
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.
GNU GCC
TR1 Implementation
For C++<11, GCC sets up TR1 components as files in the tr1/ include path and the features under the std::tr1 namespace. Cxxomfort sets up the macro CXXO_namespace_tr1 to the later value.
Unfortunately the TR1 headers are coded in such a way that it is not possible to add them to the #include search path. See [8ee003badda1c6033919702ac729de7c00ceb6b1] for the local report, GCC bugzilla for the associated bug 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 stl_list.h
.
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; 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.
Associated reports:
- /ticket?s=TR1
- [5a9e81910ede7e3e1f77].
Short enum Types
GCC supports the -fshort-enums flag which allows enumeration types to use as a base types shorter than signed/unsigned int. Note that when this flag is enabled, the default implementation of typesafe enumeration types using library::typesafe_enum might change.
__typeof__
GCC >= 4.0 implements the __typeof__ extension in all Standard modes, which returns the type corresponding to an expression: it is basically an earlier alternative to decltype.
Cxxomfort declares the CXXO_TYPEOF(expression) macro to return __typeof__ of the expression in C++03 mode, or decltype of the expression in later Standards.
Microsoft Visual C++ Compiler
TR1 Implementation
MSVC 2008 ships without a TR1, and thus is unsupported.
MSVC 2008 SP1 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 std::tr1 namespace. Cxxofort defines the macro CXXO_namespace_tr1 to this later value so that features such as hash can be pointed to.
MSVC 2012 and later do not have a std::tr1 namespace.
MSVC 2010 std::common_type
MSVC 2010 and 2010 SP1 ship with a broken implementation of std::common_type that is not variadic, and can only take two types. Because this means that the name common_type is used, Cxxomfort can not extend this feature to more template arguments.
Code wanting to transparently use common_type can instead use cxxomfort::fix::common_type which will forward to the correct implementation (std or cxxomfort) depending on compiler version.
No typeof
MSVC < 2010 lacks any semblance to a __typeof__ mechanism. As such, code using CXXO_TYPEOF or CXXO_DECLTYPE will fail to compile. Note there is an extras:: feature that allows for an "auto" hack in MSVC 2008, but it is only a partial solution.
Clang
Most of the notes valid for GCC are also valid here.
clang-libc++
Cxxomfort has not been tested with Clang using libc++, and has no support for it as of the last 2018 release.
Rvalue-References
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.
Digital Mars
Lacking C++ Support
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 the library is not guaranteed to compile beyond the Base featureset.
decltype
Digital Mars provides minimal support for the decltype feature, although it lacks some of the corrections from later revisions such as decltype 1.1. Cxxomfort defines the macros CXXO_TYPEOF and CXXO_DECLTYPE to use this feature.
Template Support
Watcom 1.9 / OpenWatcom (beta)
Lacking C++ Support
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 the library is not guaranteed to compile beyond the Base featureset.
nullptr
Watcom defines NULL as integral zero, and also lacks template conversion operators; as such, nullptr can not be implemented as per C++11 official backport. For this compiler, Cxxomfort defines nullptr to be integral zero, and std::nullptr_t as an empty type with an implicit conversion to integral zero.
Template Support
General Notes
Compiler Lacks Basic C++ Support
Template Support
#pragma
type_name
Using the library::type_name and typeid_demangle features require typeid support and thus RTTI to be enabled. (Though an assist using compile-time type index is under study)
Note 2019-02-01: Removing the RTTI requirement for type_name<T> on compilers that implement some sort of function-name reflection (such as __PRETTY_FUNCTION) is being considered.
→ Proceed with the Configuration