C99 adds several useful features to the language, yet I find it difficult to recommend any practice which depends upon C99. The reason for this is because there are few (any?) actual implementations of the C99 language. Sure, there is limited support in a few compilers, but nobody wants spend the time to write C code only to have it be unportable.
This is frustrating given that the standard was written and finalized over 10 years ago now. Plus I hear discussions of a C1x from time to time, and I wonder why someone would be taking steps to revise the language given that the current version of the language isn't yet implemented.
So my question is, as joe blow C programmer today, what is useful w.r.t. the C99 standard to me (if any)?
MSVC does not, nor will it probably ever, support C99. But Microsoft has little incentive to update their C compiler. It's not like they will lose much business over it.
But there are plenty of compilers that have support for C99.
http://en.wikipedia.org/wiki/C99#Implementations
Regarding gcc:
http://gcc.gnu.org/c99status.html
You are right that perhaps C99 is not useful for library code (and may never be without Microsoft's support), but if you're working on an in-house or personal project where you can pick the compilers and tools, then the portability is not much of an issue.
C99 brings features that really makes programming in C easier and more error safe:
- designated initializers
- compound literals
for-scope variables- fixed width integer types
The language is also much more expressive with
- variadic macros
inlinefunctions
On my linux machine I have four compilers that support C99 to a satisfying extent that make this usable on a daily base: gcc, clang, opencc and icc.
The first two are open source compilers where clang trying to be code compatible to gcc (meaning C99 support is about the same).
The later two are from the two major CPU producers and are commercial but with generous license policy for non commercial users. Their C99 is a bit less, in particular their support for inline seems not completely consistent with the standard, yet.
Regarding C1x, I think it's worth noting that the standards committee is well aware that C99 has not been widely adopted and doesn't want to repeat the same mistakes (or to make the situation worse). From the C1x charter:
Unlike for C9X, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the Standard and the commercial implementation compatible.
And:
The original standard had a very positive reception from both the user and vendor communities. However, C99 has been not so widely received.
You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably).
And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course).
Original answer: "Uh? What compilers don't support C99? Plus when you move from compilers to tools, C99 is actually more commonly supported then C89."
If you care for performance, there's no way around restrict.
FreeBSD is now using Clang for kernel compiles and that pretty much supports C99.
来源：https://stackoverflow.com/questions/4241080/what-is-the-point-of-the-c99-standard