The official "ZDoom on Linux" thread.

[_mental_]

Not again... Does anyone have an idea how MSVC can be forced to reject these that doesn't necessitate changing nearly everything that has to do with FStrings?

I tried to use Clang front-end with Microsoft code generator but this will definitely require some changes to make it work.
Anyway here is PR with a fix for mentioned errors.

[Blzut3]

Not on Windows to explore, but VS has the warning as C6284 going back to VS2005.

[dpJudas]

Not on Windows to explore, but VS has the warning as C6284 going back to VS2005.

Perfect. That means either "#pragma warning (error: 6284)" or linker argument /we6284 will cause that to generate an error always.

[Graf Zahl]

I doubt it. The problem here is that VC automatically selects the supplied 'operator char*' conversion operator to deal with this argument. If that was left out you'd get a warning, I believe.

[Blzut3]

I'd have to check, but the documentation that I've read suggests that that's not the case. Ultimately FString has exactly one member a char* (which is actually an offset pointer to FStringData) so when passed to printf as a POD it should "just work" as a string.

Edit: For example here's someone on stackoverflow that appears to be getting a crash in VC trying to add a char* operator to std::string.

[dpJudas]

Actually, sadly Graf is right. Did a test after his posting and it indeed didn't create any warning or error.

[Rachael]

This probably sounds like a stupid idea, but maybe we should switch to MinGW-64 for primary compiling, and for testing. Development work can still be done in MSVC++ and it has too many features to just be thrown to the side, but portability is being thrown to the side by such little use of GCC except in non-Windows environments. And perhaps require all submissions to be tested with both. MSVC++ could probably still be the primary compiler for releases and devbuilds, though.

[Graf Zahl]

MinGW is a mess for Windows development. The current code base doesn't even compile with it because the headers it comes with are too outdated.
All you'd achieve with such a requirement is to kill the project. Visual Studio is easy to set up. MinGW can be a problem even for experienced people.

MSVC comes with a Clang frontend, but I have no idea how that can be made to work with CMake and then only for the files that do not depend on MS compiler features.

[Blzut3]

because the headers it comes with are too outdated.

While I agree with the rest of the post, but just so you know: MinGW-w64 is not the same as MinGW in this regard. I don't recall any significant changes being required for w64 to work (in fact I think it was just fixing an ifdef), but vanilla required a bit of work (certainly doable since that's the only way to do C++11/14 on Win98 which I already did). The system I did these changes on wasn't set up to commit so I didn't get around to submitting the fixes.

[Rachael]

Well it was an idea. I just thought having some sort of standardized compiler across all platforms would help, and GCC is readily available.

[dpJudas]

Requiring a specific compiler rather than the platform default (msvc for windows, gcc for linux, clang for mac) is imho going to cause more problems than it solves.

I think a better solution might be to use C++11 "Args.." instead of C's "...". That will allow the Format function to know the type of its input where it can add GetChars automatically for all compilers before passing it on to a lower level format function.

[Graf Zahl]

I have to admit that this is a feature I know nothing about. How would that work?

[dpJudas]

Here's an example of how it could be done: https://gist.github.com/dpjudas/6f501e7 ... 00bf481dc0 - it does require some patching to the existing Format function on FString to behave like FormatNextArg, but once that is done pretty much any type can be auto-converted by adding them to the list of template specializations. I.e. a DVector3 could automatically expand itself to a "{ 123.456, 432.423 543.2 }" string and so on.

[Graf Zahl]

I wonder how bad the object code will be for something like that...

[dpJudas]

Probably not something you'd want to do in a time critical drawer function, but I think a good modern optimizing compiler would probably inline it all as each of those functions are rather small. I'm very happy I wasn't hired to code this C++11 feature in a compiler, that's for sure.