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.
Related
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.
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.
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
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.
I was just listening to episode 57 of Software Engineering Radio
(TRANSCRIPT: http://www.se-radio.net/transcript-57-compiletime-metaprogramming )
I'm only 40 minutes in, but I'm wondering why C is the language of compilers- when a Scheme subset would seem to be a better fit? (or some other HLL)
(excluding the obvious reason of not wanting to rewrite gcc)
PS originally posted this at LtU http://lambda-the-ultimate.org/node/3754
I won't bother to listen to 40 minutes of radio to perhaps understand your question more thoroughly, but I would claim the exact opposite. Only a minority of compilers are written in C. I rather have the impression that (at least where appropriate), most compilers are implemented in the language they are meant to compile.
C need not be the language for compilers, but it does have some advantages. C is available on almost all platforms and that makes it easy to port and bootstrap the compiler. C is closer to the hardware and makes possible many optimizations that will be difficult to achieve in other languages. It is easy for a compiler written in C to co-exist with other languages, libraries and systems as most of them provide a C interface. It is also easy for others to extend the compiler as C is the Esperanto of system programmers.
Well, one reason will be the issue of bootstrapping the compiler on unsupported architectures. That will usually require the existence of a working compiler for that architecture, which generally means C. I remember trying to compile MIT-scheme from source, and getting really pissed off that it required MIT-scheme to be installed before I could build MIT-scheme.
Incidentally, I'm not sure I agree with your premise... C certainly seems to be the most widely deployed language, but other language compilers (e.g. MIT-scheme) are often implemented in those languages.
It's probably a combination of factors:
C compilers are available for almost every platform, making it easier to build a new compiler for a new language.
History: C is a very popular language, so it makes sense that a lot of projects are in C (no matter the project).
Scheme, specifically, is very unpopular (compared to C).
C has Flex and Yacc which help with implementing the Frontend (parser and lexer) of a compiler, if I remember right their output is limited to c code
Many compilers today are written in languages other than C (such as Scheme). To make them portable they initially generate C code as a target language.
I think a lot has to do with backends. Someone mentioned Flex and Yacc, but there's also GCC and LLVM that will help you with a lot of other important stuff, like optimizations.