#define has a more functional role than expected

[zaimoni]

Contrary to what one might expect from style guides, they actually have some architectural uses. Snap impression when viewing grep results on July 12 2020 was:

• catacurses.h/cpp : this is an inherited minimum-core implementation of the curses library, extended with partial tileset support. Example "correct cleanup" would be maintaining a local fork of PDCurses (license is public domain); this adds defines, as the relevant standards are for a C library.

** we have some "closely correlated macros" that reasonably can treated the same as this.

• source code correctness: This is a combination of recent macros for automating declaration and definition, and model configuration.

** examples of model configuration: construction.cpp, crafting.cpp, itypedef.cpp, missiondef.cpp, mtypedef.cpp, mutation_def.cpp. trapdef.cpp, veh_typedef.cpp. A "correct fix" for these is direct conversion to loading from JSON files.

* examples of automating declaration and definition: c_bitmap.h, enum_json.h . "correct fix" usually does not exist, even though they interfere with IDE source code browsing tools: the alternatives are intentionally sabotaging formal verification, or reimplementing the C preprocessor and doing the preprocessing as an extra build step (which is predicted to not* play nice with the build system)

*** set_vector.h has wrappers for a particular archaic idiom that, before upgrade to C++11, was actually undefined behavior. They would be made irrelevant by converting model configuration to external JSON files; this is an example of a "correct fix"

• Unusual debugging build mode option control: example item.cpp . No "correct fix" possible without ditching the debugging option being kept compiled out. These defines are kept commented out when not in use (and should not be committed to the repository as "defined").

• Include guards. No "correct fix" as long as replacement options are typically either less standardized (e.g., #pragma once) or have specification issues (C++20 modules)

• proxy for inline functions: replacement by inline functions or template functions are examples of a "correct fix". Template parameter packs are an option for a "correct fix"

• proxy for integerlike constants: archaism preference for C enumerations as a "correct fix" (note that there is a compiler warning about unscoped enumerations, but scoped enumerations are C++-specific and the marketing for them doesn't make a clear case for value-added.) Isolated constants have a defensible "correct fix" as (inline) static constexpr const variables. [Yes, looks redundant but the standard committee couldn't make up its mind...they already flip-flopped once (C++11 - C++14 - C++17).]

[zaimoni]

For something that isn't formally standardized, #pragma once has very widespread support. In particular, OpenXCom Extended Plus ( https://github.com/MeridianOXC/OpenXcom ) uses #pragma once instead of include guard defines. Cf. https://en.wikipedia.org/wiki/Pragma_once for where this extension actually works.

Contrary to my initial impression above, I'm now ok with eliminating all include guard macros in favor of #pragma once.

[hirdrac]

I generally use include guards in my own code but pragma once is fine as well.

[zaimoni]

The variadic setup macros (often targeting varargs constructors) generally look like they should be using C++17 initializer-lists after de-macroing. I'm fine with this replacement strategy (and have used it where it eliminated debugmsg calls at source).

Theoretically, this could be made obsolete by modding support, but I think it should be possible to do C++ configuration for core game and JSON configuration for mod content at the same time.

Aside: think I may have been unclear how the release cycle works (I announced 0.2.3 on Bay12 and reddit, but only did a wiki update to the release schedule here). Intent was to provide a ~6 week window for high-risk changes before switching to making the game stable for release. I can push out the high risk window end date, if useful.