I was reading through some of the best practices for the GNOME project, and one thing that they kept stressing was avoiding C99 features, as support was still not widespread. Some of the things they mentioned were features like single-line comments and declaring variables in the middle of a block. It made me wonder, is C99 support, even for basic features like // comments, really still not widespread? It's been almost 15 years now since the standard was adopted, and we've even had a new standard come out in that time. Is this really still an issue?
http://en.wikipedia.org/wiki/C99#Implementations
Seems like it still is a bit of an issue, even in GCC, though it looks like some commercial compilers have implemented the entire standard.
Microsoft have said repeatedly there are no plans to implement the C99 standard at any point in the future which is a shame for C programming on Windows.
The only remotely-relevant "C compiler" that could be used for desktop-application or mobile-application usage but which does not support C99 is MSVC. If you're writing embedded software for obscure systems with their own proprietary compilers, avoiding C99 features might make sense, but the choice in Gnome makes no sense at all.
Related
I'm a beginner in C and I was wondering if C versions are backwards compatible so I know if I watch the correct type of tutorials.
backwards compatible? mostly no
forwards compatible? mostly yes
What I mean is
When the C workgroup (WG14) publishes a new standard, most of the programs that were compatible with the previous standard are also compatible with the new standard.
However, new programs written according to the new standard do not necessarily comply with the older standard(s).
In other words... you can (mostly) write C89 and compile with any compiler (C89, C94, C99, C11, C17, C2x); however if you write C17 it may have features that are not available in C11 or previous.
Well no and yes. But i don't remember there being a function that was popular and suddenly stopped existing, normally they just slowly turn obsolete or its some undo, most people work on the same version and most tutorials out there are in the most recent or a safe revision for you to work in, specially if you are learning, I've never encountered that problem in 2-3 years of hard coding in C(except in foreign libraries, you should worry about those)
ill proceed to copy pasta from the wiki
https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
The optional bounds-checking interfaces (Annex K) remain controversial and have not been widely implemented, and their deprecation or removal from the next standard revision has been proposed.[20] Even Microsoft, a main proponent of this interface, does not conform to the definition.[21] In addition, Annex K does not include the more useful TR24731-2 (dynamic allocation functions), such as vasprintf and open_memstream.[22] The few open-source implementations include Open Watcom C/C++'s "Safer C" library[23] and safeclib.
But im gonna assume you are here to learn C, so you shouldn't need to worry about these sudden deprecations
Ok i had to creep into the user because i felt this sort of question could only come... From a person who delved or interacted with python before.
This is the big reason i dislike python is because every other major version a bunch of functions gets broken and you have to fix all of it, this in my few hours of python so im not talking as a person who worked with python for weeks or did any serious or hard projects in python
But no in C unless you are all about those obscure macro's and preprocessor's you should be able to use the most well known functions to do anything, and especially for learning, you never have to worry that your functions will one day break specially if you're young.
This is because unlike python the C libraries aren't as extensive and come in my opinion with the bare minimum this makes it run faster and break less often
C standards are not backward compatible - code written under the latest standard is not guaranteed to build with compilers that only support earlier versions.
C standards are (mostly) forward compatible - code written under older versions of the standard should build with compilers that implement the most recent version, apart from a few breaking changes over the years (C99 eliminated implicit int declarations and removed the gets library function from the standard library).
The committee responsible for the C standard works very hard to make sure any changes don't break existing code, but sometimes that's not possible.
If you're just now learning C, learn using the most recent versions you have available to you. The most recent versions of most C compilers should support C17; if not they should support at least C11.
Out of C18, C11, C99, and ANSI C, which standard should I (currently) stick to, and why? What is the best way to find out which compilers support which standards? How does this choice differ for different programming domains?
Out of C18, C11, C99, and ANSI C, which standard should I (currently) stick to, and why?
In general the latest. Use the latest unless you have some argument against.
One argument against using C18 is that the documentation does not seem to be freely available yet, but C11 is. Well, freely and freely. At least they are here: https://port70.net/~nsz/c/ Note that these are not the final ones, but for most purposes they are good enough. Thanks to #Lundin and #JohnBode for pointing it out.
Another argument is that there may be platforms you want to support where a newer standard is not supported.
And I would strongly advice against ANSI unless you have no other choice. The C99 version was a very big improvement. After that, there are some nice new features, but the biggest change was C99.
What is the best way to find out which compilers support which standards?
Google. Or look in the documentation for the compilers you are interested in. However, be aware that some compilers may not be 100% compliant with a certain C version, even if they claim to be.
Usually, the latest standard, as soon as it's released, supersedes all other existing standards. So, theoretically, it's the latest one available at any time.
However, not all compilers will be up-to-date to support the latest standard revision - the practical answer is: whichever is the latest version supported by your environment, is usually best to use.
In my experience, this is often a matter of organizational policy rather than personal preference. And the reasons for the organizational policy are often not technical - they're tied up with support contracts and staff training and matters like that.
If you have the good fortune to be able to make the choice entirely yourself, you still need to consider matters such as the range of platforms you want to support, and the currentness of the compilers that will be available to people who might have to build your code, other than yourself.
If you have a complete free hand in this area, consider yourself lucky ;)
If you are a professional then in whatever project you are contributing to there is (or should be) one person responsible for that decision.
Do what that person decides.
In case you are free to decide (because you are that person or because the whole project is just you), then at first go with the latest revision (like other answers recommend), assuming you do not happen to have good reasons to the contrary.
Then when another one becomes available, redecide; I recommend to tend to stay with the one you started with, if there are no relevant benefits to be had from newer one.
In case of a professional multi-person project, deciding to use a newer compiler (implied by a newer standard being supported) is risky. It would at least make a regression test necessary.
So I'm working on this C/C++ library, and I'm using the GNU compiler, which supports the latest standard of C and C++.
I want to make my library compatible with the VC++ compiler which only supports C89/C90, not the newer C standards that allow variable declarations after other statements inside of a function body.
Is there a tool I can use that will make all my variable declarations at the beginning of the function bodies?
My library is quite large and having a tool to do this task will make the process easy.
Sorry for the anti-answer, but Visual C++ is not a C compiler. It may be a compiler for some old, outdated (22 years outdated, to be precise) language, which is not C. The best thing you should do is to advise people that are asking you for such support about this and request them to switch compiler and not use a broken one.
If this solution is really beyond your choice (it's not), then there are similar topics that you could look for:
How to compile c99-to-c89 convertor with clang?
https://github.com/libav/c99-to-c89/
If you think what I said makes no sense think again: It's a 22 year outdated C compiler. Think about the effort and money that people all over the world have spent to support it.
Edit: btw, that's C:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/standards
I like the syntax of the "GNU Extensions for Complex Number Types" but I know that it isn't standard unlike complex.h. So, which should I use?
This is really a question of what's the most important to you.
If there's any chance that you may someday want to use the code on any compiler other than gnu, then it probably makes sense to use the standard "stuff" from <complex.h>.
If you're reasonably certain you're only targeting the gnu compiler, or at least consider the improvement in syntax they offer worth the possibility that you may eventually have to rewrite the code, then it may make more sense to use the gnu extensions instead.
At least to me it would come down to a fairly simple situation: if the code was (even reasonably) portable otherwise, I'd follow the standard for complex types as well. If the code uses enough gnu extensions otherwise that porting to another compiler will probably require a (nearly) complete rewrite, then you might as well use the gnu extensions if you like them better.
I should also add that porting isn't really the only consideration, but it all works together. Readability works pretty much the same way -- if you're using enough gnu extensions that somebody pretty much needs to know about gnu extensions to read the code, then using their extensions for complex won't be a bit loss. If the code is standard enough that somebody could otherwise read it, adding in proprietary extensions just for complex probably isn't a good idea.
Either one will cause portability issues. You'll have to decide based on what set of compilers you need your code to work with.
C99's <complex.h> is, of course, part of the standard language -- but not all compilers support C99. In particular, Microsoft has said that they're not planning to support C99 or any later standard, except for those features that happen to exist in C++. (C++ has complex number support, but as a library, not as a built-in set of types as C99 does.)
On the other hand, a gcc extension will only work with gcc, or with compilers that are sufficiently compatible with gcc.
I suspect that <complex.h> is going to be more portable than the gcc extension; you're not going to be able to use Microsoft's compiler with either one, but any implementation that supports C99 will support <complex.h>.
(Another alternative is to use C++ rather than C, and use C++'s <complex>.)
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)?
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
inline functions
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.
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.
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.