3 ms·

If msvc would support a more modern C, i predict a lot of people would use this instead of C++. (Thanks Herb)

flohofwoe 6y ago
C11 support is on the roadmap since a few weeks ago: https://developercommunity.visualstudio.com/idea/387315/add-c11-support.html https://developercommunity.visualstudio.com/idea/387315/add-... I hope this also means the MSVC team had a change of mind regarding this very unfortunate blog post which IMHO did more damage to C than anything else in the last 20 years: https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
- andi999 6y ago
  Your first link: that would be great, but somehow I can only find a statement that a c11 complient preprocessor is in the roadmap. Can you point me to something specific?
  - flohofwoe 6y ago
    I can't sorry, since I'm not part of the MSVC team. The news that the MSVC preprocessor is C11 compliant made the round long before this specific ticket got the "Roadmap" tag slapped on though (which was on 20-Jul-2020). I guess we need to wait for the first results to show up in MSVC or a statement from MS.
- pjmlp 6y ago
  And rightfully so, C code has no place in modern secure computing besides UNIX kernel clones, and legacy code.
  - deleted 6y ago
    [deleted]
  - flohofwoe 6y ago
    Security should be provided by a sandbox technology. Is it wise to implement the sandbox in C (or C++, because that really doesn't make a difference)? Probably not. For most other use cases it's fine to use "unsafe languages".
    - pjmlp 6y ago
      Sandoxes don't prevent security exploits due to internal memory corruption of the sandbox.
      - flohofwoe 6y ago
        But bad actors won't use memory-safe languages either ;) The purpose of the sandbox is to keep the damage contained, no matter if this damage was intended or not.
        pjmlp 6y ago
        The less memory unsafe languages get used the better, regardless of sandboxing. Here C++ has an edge over C, because it offers the language features for memory safe array and string manipulation, and most C++ compilers do offer bounds checking support, enabled by default in debug mode, and selectively in release if one so wishes. Ideally, Swift, Rust, Ada, .NET Native would have replaced all use cases, but we are far from that ideal, so 2nd best solution, C++ for the time being. Note that Apple and Google also reduce to the minimum the usage of C, and equally advocate C++ instead, alongside their managed languages for their OSes. So yeah, you get C11 in the box, pity that the OS APIs are a mix of C++ and their own languages.
        flohofwoe 6y ago
        C++ as OS APIs (which so far only Microsoft seems to do in their UWP wrapper APIs, which is a fairly exotic use case) can be dealt with the same way as Objective-C on macOS and iOS: put all the code which talks to OS APIs into separate C++ or Obj-C source files, and put that code behind a simple C-API. It's also interesting to note that Microsoft is only using header-only C++ wrappers, under the hood it's all plain old C-APIs via COM (because it would be a bad idea to expose C++ APIs in system DLLs). The usage rules for C++ in Google's Fuchsia are so limited [1] that it is essentially a "C with classes", and it also has the rule that all shared libraries must have C APIs. I really don't see the advantage of using C++ for the underlying implementation compared to plain C if C++ has to be stripped down that much, and the public APIs are C APIs anyway. [1] https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...
Teckla 6y ago
I abandoned Microsoft compilers a long time ago due to their lack of support for newer C standards. I know a lot of other people that did, too. It may also have contributed to a lot of software developers moving to Linux, which has always had great C compilers.

C11 support is on the roadmap since a few weeks ago: https://developercommunity.visualstudio.com/idea/387315/add-c11-support.html https://developercommunity.visualstudio.com/idea/387315/add-... I hope this also means the MSVC team had a change of mind regarding this very unfortunate blog post which IMHO did more damage to C than anything else in the last 20 years: https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

andi999 6y ago
Your first link: that would be great, but somehow I can only find a statement that a c11 complient preprocessor is in the roadmap. Can you point me to something specific?
- flohofwoe 6y ago
  I can't sorry, since I'm not part of the MSVC team. The news that the MSVC preprocessor is C11 compliant made the round long before this specific ticket got the "Roadmap" tag slapped on though (which was on 20-Jul-2020). I guess we need to wait for the first results to show up in MSVC or a statement from MS.
pjmlp 6y ago
And rightfully so, C code has no place in modern secure computing besides UNIX kernel clones, and legacy code.
- deleted 6y ago
  [deleted]
- flohofwoe 6y ago
  Security should be provided by a sandbox technology. Is it wise to implement the sandbox in C (or C++, because that really doesn't make a difference)? Probably not. For most other use cases it's fine to use "unsafe languages".
  - pjmlp 6y ago
    Sandoxes don't prevent security exploits due to internal memory corruption of the sandbox.
    - flohofwoe 6y ago
      But bad actors won't use memory-safe languages either ;) The purpose of the sandbox is to keep the damage contained, no matter if this damage was intended or not.
      - pjmlp 6y ago
        The less memory unsafe languages get used the better, regardless of sandboxing. Here C++ has an edge over C, because it offers the language features for memory safe array and string manipulation, and most C++ compilers do offer bounds checking support, enabled by default in debug mode, and selectively in release if one so wishes. Ideally, Swift, Rust, Ada, .NET Native would have replaced all use cases, but we are far from that ideal, so 2nd best solution, C++ for the time being. Note that Apple and Google also reduce to the minimum the usage of C, and equally advocate C++ instead, alongside their managed languages for their OSes. So yeah, you get C11 in the box, pity that the OS APIs are a mix of C++ and their own languages.
        flohofwoe 6y ago
        C++ as OS APIs (which so far only Microsoft seems to do in their UWP wrapper APIs, which is a fairly exotic use case) can be dealt with the same way as Objective-C on macOS and iOS: put all the code which talks to OS APIs into separate C++ or Obj-C source files, and put that code behind a simple C-API. It's also interesting to note that Microsoft is only using header-only C++ wrappers, under the hood it's all plain old C-APIs via COM (because it would be a bad idea to expose C++ APIs in system DLLs). The usage rules for C++ in Google's Fuchsia are so limited [1] that it is essentially a "C with classes", and it also has the rule that all shared libraries must have C APIs. I really don't see the advantage of using C++ for the underlying implementation compared to plain C if C++ has to be stripped down that much, and the public APIs are C APIs anyway. [1] https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...

Teckla 6y ago

I abandoned Microsoft compilers a long time ago due to their lack of support for newer C standards. I know a lot of other people that did, too. It may also have contributed to a lot of software developers moving to Linux, which has always had great C compilers.