Hacker News Reader

Comment by liquidify | Hacker News Reader

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.

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.

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

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).

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. :)

VS 2019 supports C11 and C17.

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).

...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.

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.

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.

> 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?

> 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++.

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++.

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".

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.

It's an STB-style single-file library, which means the implementation is in a separate ifdef-block from the interface declarations, this allows to compile the implementation in a different source file (which can be a C file) from the source files which use the library (which can be C++ files).

Here's for example such an "implementation source file" example (using stb_image.h):

https://github.com/floooh/sokol-samples/blob/master/libs/stb...

...or for a whole collection of related single-file libraries:

https://github.com/floooh/sokol-samples/blob/master/libs/sok...

Yes, my mistake. I assumed they retained some code in header mode intended for inlining but that was not correct.

C libraries are usually easier to integrate even into C++ projects because there's no "C++ subset incompatibility" (e.g. use of exceptions, RTTI, banned stdlib features etc... - since most of those things don't exist in C in the first place), and "flat" C-APIs are also usually much saner (some C++ library APIs have designed themselves into class-hierarchy- and/or template-hell).

There are easy to integrate C++ libraries like Dear ImGui but they are in the minority, and (for instance) Dear ImGui uses a very restricted set of C++ features (it's essentially "C with namespaces and overloading", so it's not very far removed from a C library).

What do you mean with legacy target? I mean, this is not going to run on a Nintendo 64. Is it?

Reply on news.ycombinator.com