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

C++20-ify #267

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

C++20-ify #267

wants to merge 19 commits into from

Conversation

voidanix
Copy link
Member

Includes #248 as it is pretty much required to not get spammed with
warnings: please review (and possibly merge) that one first.

This PR bumps the C++ version requirement to C++20 and starts using some
features provided by it: more refactorings thanks to the new version will
be coming later.

Because I am pretty sure that some people would absolutely be against this
(ahem) due to high compiler requirements, I propose creating a cpp-next
branch so that users who want to contribute with modern code that takes
advantage of newer versions can do so, by pushing PRs against that branch.

CI will likely fail as the provided compilers are too old: all changes were
tested locally against GCC 13 and Clang 16.

voidanix and others added 19 commits May 4, 2023 19:21
Also introduces a new "inrange" function, useful for future refactorings
to std::vector
The mattrig macro expands the mw argument at one point into:

if (curmat != MAT_WATER ? S_SPLASH2 : S_SPLASH1 >= 0)

Co-authored-by: Robert Alm Nilsson <[email protected]>
There should be no reason to overwrite this as the C++ spec already
specifies it. Compilers nowadays also gift us a dedicated warning for this
kind of situation (-Wzero-as-null-pointer-constant).

Remove it and specify <cstddef> to still make NULL accessible.
This usage of volatile has been deprecated since C++20: use std::atomic
in its place.
Enable new language features that allow everyone to write better, safer and
faster C++ code (and not let the game die).
As of C++17, we can specify whether we want our switch cases to
fall-through or not (in presence of a break statement): specifying these
avoids unnecessary compiler warnings and makes the code clearer as to what
it is doing.

Specify the fallthrough attribute where needed and replace the comments
that specify its explicit usage.
As of C++17, the STL already provides us with std::clamp which in turn
makes the implementation here provided redundant and possibly broken:
remove the implementation here defined and use the one provided by
<algorithm>.
As of C++20, the STL already provides us with mathematical constants that
make the macro-fied ones used in tools redundant and possibly inaccurate:
remove our definitions of the macros and use the constants defined in the
<numbers> header.
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

Successfully merging this pull request may close these issues.

1 participant