Add C++20 support for Deathmatch project

[TracerDS]

No description provided.

[G-Moris]

Doubtful, because of linux

[TracerDS]

Doubtful, because of linux

it compiled fine on linux, what are you on about?

[G-Moris]

Doubtful, because of linux

it compiled fine on linux, what are you on about?

It is possible that problems may arise in other linuxs, it may have already been solved, it is possible that this is so

[TracerDS]

Doubtful, because of linux

it compiled fine on linux, what are you on about?

It is possible that problems may arise in other linuxs, it may have already been solved, it is possible that this is so

If it compiles fine on x86_64-gcc-10 and arm-gcc-10 then it should compile for other modern compilers

[TheNormalnij]

If it compiles fine on x86_64-gcc-10 and arm-gcc-10 then it should compile for other modern compilers

It doesn't work like this

[TracerDS]

If it compiles fine on x86_64-gcc-10 and arm-gcc-10 then it should compile for other modern compilers

It doesn't work like this

I know, but if it matches the standard then it should work on most compilers that conform to the C++ standard.
There arent any major runtime changes (beside a fix). It should not have any implications

[TheNormalnij]

I know, but if it matches the standard then it should work on most compilers that conform to the C++ standard.
There arent any major runtime changes (beside a fix). It should not have any implications

All compilers have different standard realization + specific bugs

[TracerDS]

I know, but if it matches the standard then it should work on most compilers that conform to the C++ standard.
There arent any major runtime changes (beside a fix). It should not have any implications

All compilers have different standard realization + specific bugs

As for this, none of the supported compilers (github actions) present a bug so we should be fine.
The only thing that could potentially be troublesome is the [[maybe_unused]] but even that is supported by most clang and gcc compilers.
Nothing to worry about.

I'd also assume it was thoroughly tested before rolling out C++23 version 😛

[TheNormalnij]

As for this, none of the supported compilers (github actions) present a bug so we should be fine.
The only thing that could potentially be troublesome is the [[maybe_unused]] but even that is supported by most clang and gcc compilers.
Nothing to worry about.

You forgot about real-time bugs

[TracerDS]

You forgot about real-time bugs

As I said before, the only real implication would be the change from __attribute__((unused)) to [[maybe_unused]].
Every other change is just an explicit SString call

[tederis]

This PR is highly desirable. At least because another one PR (#3287) depends on it. I think C++20 in this module will be fine and does not cause any problems. I already have an experience with C++20 in MTA and everything is going well.

P.S. In theory there can be ABI inconsistency if some of STL structures get returned from Deathmatch module. But these potential points of inconsistency are easy to detect in most cases. At least, it can be certain that MSVC is stable enough.

[G-Moris]

Hello! Is there a problem with the support of other C++20 server modules?

[TracerDS]

Hello! Is there a problem with the support of other C++20 server modules?

With some, probably. But I didnt check. Lets just get C++20 support for the deathmatch first

[Pirulax]

Really should either use string_view or SString* here instead.

[TracerDS]

i.e. const std::string_view/SString* strXYZ = ... : ""/nullptr?

[TracerDS]

Im not interested in advancing this PR further anymore.
If someone wants to refresh it, feel free to do so.