5 ms·

Curious. Why C89?

psykotic 6y ago
C99 support in MSVC was still spotty until very recently. And for single-header libraries in particular it's helpful to use a style of C that can be #included directly into C++ source files without issue.
- sillysaurusx 6y ago
  I thought MSVC supported C99 since like ... 2012? I guess a decade is sort of "very recently" in MSVC terms, but it's been awhile.
  - psykotic 6y ago
    A post-release update to VS 2017 was the first version which supported a useful subset of C99. But support isn't a binary thing; I was tangentially involved in diagnosing a critical bug in their implementation of C99 lvalue literals just a few months ago. Minimal repro: https://godbolt.org/z/7rTv1M https://godbolt.org/z/7rTv1M
    - flohofwoe 6y ago
      Minor nitpick: Most C99 features were "already" in a VS2015 update (initialization features like designated init and compound literals, and a standard compliant snprintf()). The big missing features were VLAs (those will never be implemented) and _Generic (implemented now in VS2019).
      - psykotic 6y ago
        Thanks, I was confusing the VS 2015 update with VS 2017 as the one that got the big pieces like designated initializers and compound literals. I don't think anyone cares about VLAs, but I look forward to being able to rely on _Generic in another 5 years when VS 2019 can be assumed available. :)
        pjmlp 6y ago
        VS 2019 supports C11 and C17.
  - flohofwoe 6y ago
    MSVC only supported a somewhat usable C99 subset since a VS2015 update, but it never implemented VLAs, so it can't be called a standard C99 compiler. _Generic has only been added very recently in VS2019, and MS recently has pledged C11 and C17 support (but it will never be a C99 compiler because VLAs will not be implemented, that's fine though, VLAs should never have made it into the standard).
    - flohofwoe 6y ago
      ...also important to note in that context: unlike gcc and clang, the MSVC C++ compiler is stuck at a "sort-of-C95". GCC and clang support most modern C features in C++ as non-standard extensions, but MSVC doesn't.
      - pjmlp 6y ago
        MVSC++ isn't the only C++ compiler that follows that. There is no rule that ISO C++ compilers should be C compilers as well. In fact, I bet they only backtraced on their position on their C compiler due to WSL, IoT and devices like Azure Sphere.
dleslie 6y ago
Gamedev. Lots of legacy targets have shoddy-at-best C99, or new, support. You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers.
- pansa2 6y ago
  > You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers. Is that true? I thought low-level game development was almost entirely in C++. Why is there resistance to using libraries written in the same language as the rest of the program?
  - pmarin 6y ago
    > I thought low-level game development was almost entirely in C++ And this is the main reason why is written in a subset of C89, because is 100% source compatible with C++.
    - jcelerier 6y ago
      it is not. very simple example: char* bytes = malloc(4); is valid C89 but not valid C++. You have to restrict yourself to a kind-of subset of C89 if you want it to work with C++.
      - flohofwoe 6y ago
        It's true that C is not a subset of C++, but in reality such implementation details don't matter much as long as the library API is both C and C++ compatible. Compiling a C source file in a C++ project is as simple as using a ".c" file extension, build systems will then compile the file in "C mode" instead of "C++ mode".
        CyberRabbi 6y ago
        This is a header-only library, so the code must be compiled in “C++ mode” to be used in C++ projects, requiring the C++/C89 subset in this case.

Curious. Why C89?

C99 support in MSVC was still spotty until very recently. And for single-header libraries in particular it's helpful to use a style of C that can be #included directly into C++ source files without issue.

sillysaurusx 6y ago
I thought MSVC supported C99 since like ... 2012? I guess a decade is sort of "very recently" in MSVC terms, but it's been awhile.
- psykotic 6y ago
  A post-release update to VS 2017 was the first version which supported a useful subset of C99. But support isn't a binary thing; I was tangentially involved in diagnosing a critical bug in their implementation of C99 lvalue literals just a few months ago. Minimal repro: https://godbolt.org/z/7rTv1M https://godbolt.org/z/7rTv1M
  - flohofwoe 6y ago
    Minor nitpick: Most C99 features were "already" in a VS2015 update (initialization features like designated init and compound literals, and a standard compliant snprintf()). The big missing features were VLAs (those will never be implemented) and _Generic (implemented now in VS2019).
    - psykotic 6y ago
      Thanks, I was confusing the VS 2015 update with VS 2017 as the one that got the big pieces like designated initializers and compound literals. I don't think anyone cares about VLAs, but I look forward to being able to rely on _Generic in another 5 years when VS 2019 can be assumed available. :)
      - pjmlp 6y ago
        VS 2019 supports C11 and C17.
- flohofwoe 6y ago
  MSVC only supported a somewhat usable C99 subset since a VS2015 update, but it never implemented VLAs, so it can't be called a standard C99 compiler. _Generic has only been added very recently in VS2019, and MS recently has pledged C11 and C17 support (but it will never be a C99 compiler because VLAs will not be implemented, that's fine though, VLAs should never have made it into the standard).
  - flohofwoe 6y ago
    ...also important to note in that context: unlike gcc and clang, the MSVC C++ compiler is stuck at a "sort-of-C95". GCC and clang support most modern C features in C++ as non-standard extensions, but MSVC doesn't.
    - pjmlp 6y ago
      MVSC++ isn't the only C++ compiler that follows that. There is no rule that ISO C++ compilers should be C compilers as well. In fact, I bet they only backtraced on their position on their C compiler due to WSL, IoT and devices like Azure Sphere.

dleslie 6y ago

Gamedev. Lots of legacy targets have shoddy-at-best C99, or new, support. You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers.

pansa2 6y ago
> You'll find that a fair amount of single-header C libraries that are explicitly C89-supporting are in use by game developers. Is that true? I thought low-level game development was almost entirely in C++. Why is there resistance to using libraries written in the same language as the rest of the program?
- pmarin 6y ago
  > I thought low-level game development was almost entirely in C++ And this is the main reason why is written in a subset of C89, because is 100% source compatible with C++.
  - jcelerier 6y ago
    it is not. very simple example: char* bytes = malloc(4); is valid C89 but not valid C++. You have to restrict yourself to a kind-of subset of C89 if you want it to work with C++.
    - flohofwoe 6y ago
      It's true that C is not a subset of C++, but in reality such implementation details don't matter much as long as the library API is both C and C++ compatible. Compiling a C source file in a C++ project is as simple as using a ".c" file extension, build systems will then compile the file in "C mode" instead of "C++ mode".
      - CyberRabbi 6y ago
        This is a header-only library, so the code must be compiled in “C++ mode” to be used in C++ projects, requiring the C++/C89 subset in this case.