You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As currently written, it seems impossible to use the library in a compiler in C++03 mode, this despite the library being otherwise a great addition to a C++ codebase as it should work similarly to the already available <random> utilities in C++03's TR1. This also given that for example I was made aware of this library in a blog entry recommending better random utilities for C++ yet in these circumstances the better clear winner against this is a competing C solution that compiles and can be used generically without issues.
Upon initial inspection of an attempted compile with GCC 5 without -std=c++11 switch, the problems that prevent the library from being compiled in C++03 mode can be categorized in three types:
Usage of auto to declare variables of types whose types are known or already named explicitly (eg.: in pcg_extras.hpp's operator<< for stuff like char (in a call to narrow) or fmtflags (in a call to member flags).
Usage of C++11 features that abbreviate or conditionate code, that can be easily backported such as static_assert or integral_constant; backporting to C++03 would probably require changing calling sites using them (such as the static assert in pcg_random line 692, which can be made into a macro if the test expression is moved into an enum). In some cases such as nullptr which even have an official backport this should be easily doable as most of these features are library-level solutions.
Usage of C++11 features that have no equivalent in a C++03 compiler, such as constexpr. These would probably require writing ad-hoc code to simulate the desired behaviour (some variables declared constexpr could be converted to enums, for example), or providing a more limited alternative.
It would be interesting to see a more involved case study of what backporting to C++03 would require; in particular, while I don't have problems trying to edit the headers myself to seek out a better compile, I am not qualified for and wouldn't venture into ensuring that the statistical properties of the utilities are preserved.
(Disclainer: am the author of cxxomfort, a general backports library for C++, and am using the backports myself for the compile tests, so my experience might not reflect an attempted backport "from scratch")
The text was updated successfully, but these errors were encountered:
As currently written, it seems impossible to use the library in a compiler in C++03 mode, this despite the library being otherwise a great addition to a C++ codebase as it should work similarly to the already available
<random>
utilities in C++03's TR1. This also given that for example I was made aware of this library in a blog entry recommending better random utilities for C++ yet in these circumstances the better clear winner against this is a competing C solution that compiles and can be used generically without issues.Upon initial inspection of an attempted compile with GCC 5 without
-std=c++11
switch, the problems that prevent the library from being compiled in C++03 mode can be categorized in three types:auto
to declare variables of types whose types are known or already named explicitly (eg.: in pcg_extras.hpp'soperator<<
for stuff like char (in a call to narrow) or fmtflags (in a call to member flags).static_assert
orintegral_constant
; backporting to C++03 would probably require changing calling sites using them (such as the static assert in pcg_random line 692, which can be made into a macro if the test expression is moved into an enum). In some cases such asnullptr
which even have an official backport this should be easily doable as most of these features are library-level solutions.constexpr
. These would probably require writing ad-hoc code to simulate the desired behaviour (some variables declared constexpr could be converted to enums, for example), or providing a more limited alternative.It would be interesting to see a more involved case study of what backporting to C++03 would require; in particular, while I don't have problems trying to edit the headers myself to seek out a better compile, I am not qualified for and wouldn't venture into ensuring that the statistical properties of the utilities are preserved.
(Disclainer: am the author of cxxomfort, a general backports library for C++, and am using the backports myself for the compile tests, so my experience might not reflect an attempted backport "from scratch")
The text was updated successfully, but these errors were encountered: