5 ms·
A lot even limit their codebases to C89, which I don't understand. Are there really that many platforms/compilers that don't effectively support C99 or greater
by uxcn 11y ago
A lot even limit their codebases to C89, which I don't understand. Are there really that many platforms/compilers that don't effectively support C99 or greater? Is sixteen years not long enough for a language feature set to stabilize?
Maybe there are tradeoffs or platforms I'm just not aware of, but I at least tend to use C99 as the LCD.
- realityking 11y agoThat's mostly because of Microsoft's horribly outdated C-compiler
- uxcn 11y agoWhy would anyone use VS to compile cross-platform C on Windows when there's MinGW (and clang-cl)?
- comex 11y agoDebug info, ubiquity, simplicity of combining with an otherwise VS based project. At least VS now supports most of C99. Most. Now about that C11...
- uxcn 11y agoHaving code that's easy to integrate with existing projects is definitely a really good thing, and I honestly don't like to neglect Windows, but with all due respect, the platform kind of does it to itself. C11 would be really nice to see as an LCD, especially for threading (or even just a native POSIX threads implementation).
- comex 11y agoI was more thinking of language features. threads.h would be nice, but, as you may know, despite it being a pretty simple API, neither glibc nor OS X libc has implemented it - there's only musl and then compatibility shims. Sigh. You could blame a lack of demand, but I'd call that chicken and egg: the whole advantage of it over pthreads in theory is portability due to standardization, but as long as the portability remains theory, so does the advantage.