4 ms·

MSVC was a pain until the 2015 version. Now writing C99 is safe if you target it. Microsoft did immense harm to the industry though, by not supporting C99 until

by xvilka 7y ago

MSVC was a pain until the 2015 version. Now writing C99 is safe if you target it. Microsoft did immense harm to the industry though, by not supporting C99 until recently. Many Windows-only programmers I saw not even aware of C99 and C11 features, sigh... Anyway, there is no reason to use MSVC at all. Both Google and Mozilla switched[1][2] to use clang-cl[3], which is a drop-in replacement for MSVC cl. Moreover, it supports various sanitizers - ASAN, UBSAN, etc for Windows platform. MSVC didn't even have support for inline assembly! A piece of crap, not a compiler. Just use clang-cl instead. [1] http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chro... [2] https://blog.mozilla.org/nfroyd/2019/04/25/an-unexpected-benefit-of-standardizing-on-clang-cl/ https://blog.mozilla.org/nfroyd/2019/04/25/an-unexpected-ben... [3] https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html

asveikau 7y ago
Interesting that your third link says they now have partial support for SEH (__try). That was a very big missing Windowsism for a long time. I guess they never did C++/CX either, but that was a bit of a misadventure on MS's part and I don't see anybody pushing it anymore. (Maybe I just haven't been paying attention to those circles lately.) It's funny how many of the ambitious WinRT era initiatives accomplish buy-in at a rate outpaced by the diminishing relevance of the platform.
kazinator 7y ago
> Microsoft did immense harm to the industry though, by not supporting C99 until recently. That's overblown. I don't use C99 myself, other than the odd library function. I don't like most of the C99 and C11 features. I was following ISO C very closely in the time frame surrounding C99; but I lost interest in ISO C as such after that disappointment.
- cryptonector 7y ago
  Designated initializers are very important. As a maintainer of a codebase that has to support older Windows OSes and MSVC releases, I still suffer from not being able to use them. Really, GP is correct, MSFT did immense harm by not implementing more/all of C99 sooner. I'm still quite annoyed by that even now, even now that MSFT has finally started doing amazing things.
  - kazinator 7y ago
    > Designated initializers are very important. I use macros or functions to initialize structures. When a new member is added that must be initialized to a non-default value, I can add a parameter to the intializer, and then the compiler finds all the places where an argument must be added. I could easily work this gradually into an old code base that I have to maintain. Such an initializer macro can be implemented itself using designated initializers, but that is of low value; it's in one place, next to where the struct is declared. The designated initializer clearly wins if we have to declare a large, sparse array without executing code, and initialize just a few entries to nonzero which are not close to the beginning.
    - cryptonector 7y ago
      If you're using cscope/etags/an IDE then you want the field name to be visible where the assignment is made, otherwise finding your way around a codebase with many function dispatch tables can get painful.
      - kazinator 7y ago
        I have a macro or function name that occurs wherever the struct is initialized. struct point p = point_init(x, y); ctags will find the definition of point_init, and cscope all the occurrences. Random code throughout the program that is not related to the data type's module shouldn't be performing explicit low-level member-for-member initializations of the data type, even with a safer mechanism like designated initializers.
        cryptonector 7y ago
        Yes, but if you have a struct with many functions then you still have a problem. With designated initializers I can traverse all the paths through cscope alone.
        kazinator 7y ago
tom_ 7y ago
I actually prefer x64 VC++'s inline asm support to the gcc variety. C99 support has been OK since VS2012 in my experience. Library support was iffy in earlier versions, but anybody accustomed to actually writing multi-platform code could handle it. A bit of a silly situation, but, as always, if you need to target multiple systems, you just do what you have to. Luckily, you can now probably rely on VS2015 or better.

by xvilka 7y ago

asveikau 7y ago

Interesting that your third link says they now have partial support for SEH (__try). That was a very big missing Windowsism for a long time. I guess they never did C++/CX either, but that was a bit of a misadventure on MS's part and I don't see anybody pushing it anymore. (Maybe I just haven't been paying attention to those circles lately.) It's funny how many of the ambitious WinRT era initiatives accomplish buy-in at a rate outpaced by the diminishing relevance of the platform.

kazinator 7y ago

> Microsoft did immense harm to the industry though, by not supporting C99 until recently. That's overblown. I don't use C99 myself, other than the odd library function. I don't like most of the C99 and C11 features. I was following ISO C very closely in the time frame surrounding C99; but I lost interest in ISO C as such after that disappointment.

cryptonector 7y ago
Designated initializers are very important. As a maintainer of a codebase that has to support older Windows OSes and MSVC releases, I still suffer from not being able to use them. Really, GP is correct, MSFT did immense harm by not implementing more/all of C99 sooner. I'm still quite annoyed by that even now, even now that MSFT has finally started doing amazing things.
- kazinator 7y ago
  > Designated initializers are very important. I use macros or functions to initialize structures. When a new member is added that must be initialized to a non-default value, I can add a parameter to the intializer, and then the compiler finds all the places where an argument must be added. I could easily work this gradually into an old code base that I have to maintain. Such an initializer macro can be implemented itself using designated initializers, but that is of low value; it's in one place, next to where the struct is declared. The designated initializer clearly wins if we have to declare a large, sparse array without executing code, and initialize just a few entries to nonzero which are not close to the beginning.
  - cryptonector 7y ago
    If you're using cscope/etags/an IDE then you want the field name to be visible where the assignment is made, otherwise finding your way around a codebase with many function dispatch tables can get painful.
    - kazinator 7y ago
      I have a macro or function name that occurs wherever the struct is initialized. struct point p = point_init(x, y); ctags will find the definition of point_init, and cscope all the occurrences. Random code throughout the program that is not related to the data type's module shouldn't be performing explicit low-level member-for-member initializations of the data type, even with a safer mechanism like designated initializers.
      - cryptonector 7y ago
        Yes, but if you have a struct with many functions then you still have a problem. With designated initializers I can traverse all the paths through cscope alone.
        kazinator 7y ago

tom_ 7y ago

I actually prefer x64 VC++'s inline asm support to the gcc variety. C99 support has been OK since VS2012 in my experience. Library support was iffy in earlier versions, but anybody accustomed to actually writing multi-platform code could handle it. A bit of a silly situation, but, as always, if you need to target multiple systems, you just do what you have to. Luckily, you can now probably rely on VS2015 or better.