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
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.
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.
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.
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.