4 ms·
Honestly, I blame MSVC for a lot of lost momentum when adopting new standards, given it takes them more than 4 years implementing those features. Ofc, this isn'
by spookie 2y ago
Honestly, I blame MSVC for a lot of lost momentum when adopting new standards, given it takes them more than 4 years implementing those features. Ofc, this isn't the case for C++11 today, but a lot of projects were started prior to 2015.
And don't get me started on C itself. Jesus Christ.
- pjmlp 2y agoThey certainly aren't to blame for the state of C and C++ adoption on UNIX, Sony and Nintendo, and embedded. They are the only C++ compiler that properly supports all C++20 modules use cases, while clang still doesn't do Parallel STL from C++17, for example. They support C17 nowadays, where many embedded folks are slowly adopting C99. And the UNIX story outside clang and GCC is quite lame, most still stuck in C++14, catching up to C++17. Likewise, consoles, C++17.
- spookie 2y agoI wouldn't say they "support" C17. Perhaps with a big asterisk. Even with C11, they implemented _parts_ of the standard, but didn't ship some of its libs (threads come to mind). Same deal in C17. Any hopes of porting over standard compliant C code to MSVC are met with lots of additional porting work. Also, if we do move the discussion outside GCC and Clang, then I don't know what to say man. Why not use GCC or Clang? Are there many UNIX out there not having either? Seems unlikely.