Using C++20 for mission development

[Vagabond]

I spent some time debugging why when setting Outpost2DLL to C++20, my missions were not compiling. In the process, I discovered the following.

In MSVC's flavor of C++, there is a compiler flag named permissive. By default, prior to MSVC's implementation of C++20, it was set to be 'more permissive' which allowed several non-standards compliant behavior to compile. In particular, it allows temporary binding to non-constant references being passed into functions (Which I do all the time since it is convenient when scripting even if not compliant C++).

I had known for a while that MSVC was more permissive than other compilers, which can be nice in reducing the barrier to learning the basics, but super annoying when it doesn't compile in other environments. I didn't realize it was controllable by a flag.

Since the permissive flag is set by default prior to MSVC C++20, you unset it by adding `/permissive-`. I was considering recommending generally setting it for our utility projects that get cross-compiled such as OP2Utility. However, since MSVC's version of C++20 doesn't set it by default, it will sort itself out naturally when projects are updated. Just be ready to correct some compiler errors when updating projects to C++20 that are not compiled using alternate compilers. OP2Utility is likely compliant, since it has a Linux automated build, it was just annoying to rework the code post push to GitHub.

I would like to update Outpost2DLL, OP2Helper, HFL, and the Level Template to all use by C++20 if there are no concerns from the community. The downside is if anyone with an existing mission updates to the latest copy post update, they may have to correct some compiler errors. They are not overly helpful to human reading, but an LLM/harness will understand what is going on quickly. The errors I encountered were fairly trivial to correct with low risk of adding a bug once I recognized what was going on.

Another option would be to set `/permissive` when updating to C++20 which would allow the non-standard behavior to persist. While missions are typically compiled for Windows, I would tend to prefer the 'pain' upfront to keep the C++ code written closer to universal.

A third option could be to just update to C++17 for now.

I'll wait a couple of days before changing anything to see if anyone has concerns/thoughts.

Also, in this post: https://forum.outpost2.net/index.php?topic=6456.msg89813, I mentioned Outpost2DLL was not compliant with C++20. This is wrong, I just assumed it wasn't compliant based on the stack of warnings that popped immediately when switching instead of digging into the details... apologies. Hooman even called me out, and I waited a month to investigate... 

[Arklon]

Vagabond, I am happy you are still alive!

We ran into similar issues with PyOP2 while backporting it to WinXP. We were able to get C++20 to work, surprisingly.

Regarding /permissive- , in MSVC C++20 there were a couple major changes.

For OP2 missions, the most annoying thing was non const correctness in the OP2 SDK, like

Code: [Select]

class BuildingGroup { void Setup(LOCATION& mine, LOCATION& smelter, MAP_RECT& smelterArea) }

In a lot of mission code, people would write

Code: [Select]

Setup({32, 32}, {64, 64}, ...)

That's not allowed in nonpermissive mode anymore, since "mine"/"smelter"/etc are non-const reference params. Unfortunately due to export name mangling, you can't just change the SDK header defs to add "const" or else Windows import symbol names can break. That's partly why I started making TethysAPI.

There were also major changes to how the C preprocessor works in MSVC nonpermissive mode, but I don't think that affected OP2 missions much.

If you have build error logs, we'd be happy to look through them!