This subset is basically a post-C90, pre-C99 version of C which has most convenience-extensions which existed before C99, like declaring variables in the middle of a scope block, allowing to declare the loop variable inside for(), etc...
I tried to port my header libraries to "pure" C90, but I didn't enjoy programming at all in this. The mid-90's pre-C99 C is almost like a new language compared to ISO C90.
I'm using C for very small cross-platform programs targeting WebAssembly, e.g.:
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.
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.
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.
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.
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.
struct point p = point_init(x, y);
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.
Are there any widely used C++ compilers that don't also have a C personality? I've only ever worried about C++ compatibility in my headers. IME C and C++ toolchains make it relatively trivial to build and link C and C++ units together. However, I don't have much experience in the commercial embedded space (as opposed to x86 appliance "embedded"), which I've assumed were mostly C shops.
Also, compiling C code in C++ mode might trigger a couple more warnings which are actually bugs.
But these are the only reason I can think of compiling C code as C++.
All of them. If you mean "aren't accompanied by a C compiler front-end also", that's something else.
If you want that C++ compiler's opinion about your code, then you have to pass it to the C++ compiler, not to its C cousin that has tagged along.