4 ms·
> when writing high-performance manually vectorized code The point was not about manually vectorized loops in particular. Why is that a problem if you are manu
by jfkebwjsbx 6y ago
> when writing high-performance manually vectorized code
The point was not about manually vectorized loops in particular. Why is that a problem if you are manually doing it, though?
> Security and compatibility has higher priority.
In commercial games, not really.
As for "compatibility", I am not sure what you mean.
> gcc and clang don't deliver their C runtime libraries with windows updates.
AFAIK you can use Windows libraries just fine. No need for using a different libc.
> Also, debugging and crash diagnostic is much easier with MSVC.
AFAIK, Clang can produce debugging info that you can use with VS.
I don't work on the environment, but it is what I have read here.
- Const-me 6y ago> Why is that a problem if you are manually doing it, though? Here’s couple examples: https://github.com/Const-me/DtsDecoder/blob/master/Utils/ApplyVolume.hpp https://github.com/Const-me/DtsDecoder/blob/master/Utils/App... https://github.com/Const-me/SimdIntroArticle/blob/master/FloodFill/Vector/PixelComparer.hpp https://github.com/Const-me/SimdIntroArticle/blob/master/Flo... I would like to use lambdas instead of classes, but can’t, due to that defect of C++. > In commercial games, not really. In commercial games too. While they don’t care about security, they do care about compatibility and crash report diagnostics. > As for "compatibility", I am not sure what you mean. A windows update shouldn’t break stuff. A software or a game should run on a Windows released at least 10 years in the future. > Clang can produce debugging info that you can use with VS. According to marketing announcements. This page however https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html only says “mostly complete” and also “Work to teach lld about CodeView and PDBs is ongoing”. PDB support is not about VC compatibility, it’s about Windows compatibility really: the debugger engine is a component of OS, even of the OS kernel. WinDbg is merely a GUI client for that engine, visual studio is another one. Overall, in my experience, the platform-default compilers cause the least amount of issues. On Windows this means msvc, on Linux gcc, on OSX clang. Technically gcc and clang are very portable. Practically, when you’re using a non-default toolset, you’re a minority of users of that toolset, e.g. the bugs you’ll find will be de-prioritized.