Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Case Study for C++03? #47

Open
lmachucab opened this issue Dec 31, 2018 · 1 comment
Open

Support Case Study for C++03? #47

lmachucab opened this issue Dec 31, 2018 · 1 comment

Comments

@lmachucab
Copy link

lmachucab commented Dec 31, 2018

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")

@jwakely
Copy link

jwakely commented Jul 14, 2019

C++03 and TR1 are both ancient history.

What does "an official backport" for nullptr mean?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants