Forum rules
Please don't start threads here asking for help. This forum is not for requesting guides, only for posting them. If you need help, the Editing forum is for you.
Graf Zahl wrote: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.
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.
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.
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.
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.
Graf Zahl wrote: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.
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.
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.
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.
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?
