If yes, where and why would you use it?

If no, please provide an explanation to why C is not acceptable to you.

  • 10
    Of course there are applications for which C is the right and obvious choice, but personally, if I never malloc a block of memory ever again, I'll die happy. Dec 14, 2010 at 12:53
  • Yes- Horses for courses. Dec 14, 2010 at 14:14
  • What does that mean? Dec 14, 2010 at 14:20
  • It's an old saying for those who follow Horse racing. Basically it means that any Horse can win on its day, as long as the Course (Dry, Muddy, Long, Short, whatever) suits it. Same goes for programming languages - it always depends on the context and problem domain. Dec 14, 2010 at 14:24
  • 2
    No, but only because today I am not working on any projects for which C would be a good language choice. Ask me again tomorrow. Dec 14, 2010 at 18:48

16 Answers 16


C is a great language for System programming

I would use C if I implemented some harware drivers. And I would use C if I implement my own Operating System kernel or my own Virtual Machine.

It is a very good language to do low-level things if you have to deal with hardware or low-level OS APIs for Windows API, Linux, Mac OS X, Solaris and so on... Embedded systems has usually good support for C with a compiler + development kit.

  • 4
    Can you point out where "Mac OS is linux"? I thought Mac OS is Darwin: en.wikipedia.org/wiki/Darwin_%28operating_system%29 Dec 14, 2010 at 14:37
  • 1
    @Stephen Furlani: LOL - yeah, that's kind of an understatement. :-) There are lots of dead Unices like Xenix, DYNIX, and A/UX, and current versions most of us don't see like HP-UX. The family tree is as complicated and tangled as that of European royal families.
    – Bob Murphy
    Dec 14, 2010 at 17:54
  • 4
    C is a horrible language for system programming. We've known that for more than 20 years, ever since the Morris Worm, and anyone still using it for any project with any security requirements at all, especially operating systems or network-facing applications, ought to face criminal negligence charges. Dec 14, 2010 at 18:11
  • 2
    @Mason Wheeler: What should we be using instead?
    – Steve S
    Dec 14, 2010 at 19:00
  • 1
    @Mason Wheeler: Hmm... I've dismissed Pascal in the past, but maybe it's time to take another (closer) look. Do you have other suggestions?
    – Steve S
    Dec 14, 2010 at 19:37

Yes, of course. I would use C for writing performance critical pieces of system or low level communication parts. For example I would use C for writing NIFs in Erlang project just because it is The Right Tool(tm) for this sort of job. Or I would use C for writing similar parts (XS) in Perl project.


I use C professionally, nearly every day. In fact, C is the highest level language in which I regularly program.

Where I use C: I write low-level library code that has a requirement to be as efficient as possible. My glue code is written in C, inner computational loops are written in assembly.

Why I use C: It's much simpler to handle complex argument structures and error conditions than it is in assembly, and the performance overhead for that sort of condition checking before starting the real computation is often negligible. Because C is a simple, well-specified language, I have an easy time working with the compiler team at work to improve the code generation whenever I see compiled code with unacceptable performance hazards.

Portability is another great virtue of C. My glue code is shared across multiple hardware-specific implementations of the libraries I work on, which really simplifies bringing up support for new platforms. Most platforms don't have a virtual machine or interpreter for the language flavor of the month. Some platforms don't have a good C++ compiler. There are very few platforms that lack a usable C compiler (and, since I have a good working relationship with our compiler team, I usually don't have a hard time getting the support I need).

  • 6
    Sounds like you have a really fun job! Dec 14, 2010 at 19:26
  • This is my dream job. Dec 25, 2010 at 19:42

Yes, I would use C in a severely resource-constrained embedded system. I may use C++ instead because it makes it easy to promote strong interfaces between software components, but only if all engineers working on the project understand that C++ is easy to misuse leading to code size bloat (virtual functions and templates are examples of things to avoid).

I also saw a C++ programmer trying to create a 10K object on a 1K stack, not a good idea.

  • 2
    actually virtual functions are okay as they follow the "you don't pay for what you don't use" principle, but in memory constrained environment, you could want to disable exceptions and RTTI. Dec 14, 2010 at 18:54
  • I feel like I'm always just creating singleton objects in C++ to provide peripheral interfaces. I think people choose C++ over C in embedded systems because they think C++ is "better".
    – Erik
    Dec 17, 2010 at 4:04

I work mostly with the Xen hypervisor, the assorted libraries it features and the Linux kernel. On occasion, I have to write a device driver (or re-write one so that nxx virtual machines can share a single device such as a HRNG). C is my primary language and I am quite happy with that.

Would I try to write a spreadsheet program using it? No way. Each tool has its applications, and I'm happy that I have many tools.

I love C, but I don't try to pound screws with a hammer.

If C is a sensible choice for a new project, sure. If not, I'll use something else.


I would for some projects. Definitely would if I have to implement an embedded system, say for an autonomous aircraft's controller. Might even go lower level on some parts with assembly.

If it fits the project, I have no problem with it.

If you want to develop a web-application, hmm, probably not (or I'd need to see a very strong and fact-supported justification).

I would also use it from other projects mainly developed with other languages when a bottleneck has been clearly identified and an optimization can be implemented using native code. For instance, a Java solution which needs to be perform intensive computations for some advanced rendering (say, a rendering engine or something). You could default to a Java implementation if it's not a supported platform, but provide a natively compiled implementation from C for some supported platforms, and get a nice performance boost.

  • You want a reason to use it for a web-appliaction? Memcached is written in C, and it is a core part of many web applications. Also, a colleague of mine wrote a piece of code pertaining to a social networking site in C - once it's algorithmically complex, with data sets bordering on the size of economically available RAM, and handling queries that run on average 23 times per page render.. we saved 4 months of a programmers salary worth of servers, with a 4-day C application.
    – qdot
    Dec 15, 2010 at 5:04
  • @qdot: It's a valid reason. There's also a reason why there are good frameworks for C and C++ web dev. Just wouldn't be my 1st choice if needed to develop a general web-app or website. In the case of a framework like memcached, it does obviously make perfect sense. Similarly having the server in C can make sense. Hence the probably not. Memcached (and your specific C implementation of a computation intensive part of a web-app) are perfectly valid uses of C for web dev. But you do need a good C programmer to do that. Just not someone who'd pick it up on the way, or expect problems.
    – haylem
    Dec 15, 2010 at 8:50
  • And if other people have other valid reasons like these, please do post them here! It's useful for readers.
    – haylem
    Dec 15, 2010 at 8:52
  • If you use C, you learn to expect great performance, good learning experience, and tons of unexplained problems at first. I just tried to encourage people to use C, since it becomes quickly crucial when you move from being a "one-in-the-million" PHP/Ruby/Python developer and start scratching your head against big computation problems.
    – qdot
    Dec 15, 2010 at 8:56
  • @qdot: indeed. Shame a lot of people don't really know C anymore, really.
    – haylem
    Dec 15, 2010 at 10:56

Every single language out there has a decent niche of use. I frequently find myself implementing things in higher-level languages, and then gradually bringing them down to C-land if I need them to be higher-performance or even simply just more portable. There are C compilers for nearly everything in existence, and if you write to an API that is universally available (such as POSIX), then it can be very useful.

What I often tell people who are interested in learning programming today is to make sure that at some point, they learn C and become comfortable with it. You might find yourself in circumstances where you need it. On more than one occasion, I've had to compile a tiny, statically-linked "fast reboot" program, and use scp to put it on a RAM disk on a server where the disk subsystem went away entirely. (Cheap, cheap servers, no online redundancy, and only the ability to load a small program? C is the way to go.)

Also, learning how to work in C without shooting yourself in the foot can contribute significantly to one's ability to write efficiently in other languages and environment. At least, that has been my experience.

While I certainly don't use it for everything, or even most things, it has its place and it's pretty much universal: so yes, I've used it in the past and will use it in the future (though I don't know when at the moment).


Yes, I do it all the time.

If you don't call any libraries, code generated from C requires no OS support. It also gives you fine control over the generated machine language. So it's great for writing drivers or other code that lives in kernel spaces, and other constrained situations like many kinds of embedded systems work. It's also the primary language for open-source projects I work with like X Windows, GTK+, and Clutter.

While you can do everything in C you can in C++, often C++'s mechanisms make it quicker and easier to write code. I love OOP and the way C++ classes encapsulate functionality, and I love RAII. Careful use of automatic destructor invocation when an object goes out of scope eliminates most of the memory and resource leaks that are the bane of C programming. The STL is basically a giant library of highly optimized algorithms and data structures; if you wanted to use them from C, you'd have to write them yourself or buy them someplace.

Unfortunately, for reasons I don't understand, the runtime system on Linux requires a special shared object library (equivalent to DLL on Windows, dylib on Mac) to run any C++, and it's not found when you run a C program. So I can't do one of my favorite Mac and Windows tricks, which is to write a C++-based shared object with a C-based API, and call it from a C program.

So here's my decision-making process:

  1. Am I working in a constrained situation like a device driver? Use C.
  2. Am I writing a Linux library anybody else will have to use? Use C.
  3. Am I working inside code that's already written in C? Use C.
  4. Am I writing a Mac or Windows library, or a Linux library only I will use? Write the internals in C++, but only expose a C interface to avoid the fragile binary interface problem.
  5. Use C++.

One nice thing is that because C++ can compile C, if you really need fine-grained control over the code generated for a particular situation, you can just write C for that, and C++ for the rest, and compile it all with the C++ compiler.

  • You can't "compile it all with a C compiler" because of the malloc issue with C++ - you have to cast in C++ but not in C. Of course its all okay if you cast in the C code which is perfectly legal but annoying. Feb 5, 2011 at 19:51
  • 1
    @mathepic: Yes, C++ is decidedly stricter than C about many things, including assigning void pointers to typed pointers. However, I'm fixing bugs in a couple of legacy projects, in part by compiling C files with C++. I'm finding type-casting the results of malloc to be a small price to pay for having the C++ compiler uncover subtle bugs due to code that's perfectly legal in C.
    – Bob Murphy
    Feb 6, 2011 at 22:28

Yes, but depends on project. C is very good for some low-level projects or part of biggest solution.

Eg. For bussines logic ok, but not for user interface.


if it has to be both

  • fast, and
  • portable

then I use C. Maybe C++.

  • Fast and portable, that could be Java or C# too.
    – Jonas
    Dec 14, 2010 at 15:01
  • 11
    @Jonas: not. Portable doesn't mean just 'windows or linux' ;-) Dec 14, 2010 at 15:37
  • 1
    @Jonas: Fast and portable, that would be neither Java nor C#. C++ is portable across platforms and embedded devices like microcontroller, and C is even portable (as foreign functions) to other languages. Both are faster than non-functional-and-therefore-stack-based-but-still-garbage-collected languages. You do not need both: a stack and a garbage collector.
    – comonad
    Dec 14, 2010 at 17:34
  • 2
    @Jonas: read it; note the caveats, and again, "portable" does not mean only windows/linux. The question asks when you would use C; the answer is: when it has to run fast everywhere. I love Java and C#, but they are sledgehammers, and older/embedded systems don't have runtimes. Many of them don't even have space to hold a runtime! Dec 14, 2010 at 18:00
  • 2
    @Jonas: I appreciate your passion, but "new platforms" are not the topic. Let me give you a more specific example, to see if that helps: the microprocessors that provide fire-control support for tanks on the battlefield have C compilers. They do not, nor will they ever, have a JVM. Dec 14, 2010 at 18:20

Yes, in fact I have recently!

I like programming in C. I do most my programming in python, but there are times when I need fast code and I really enjoy the elegance that come from the simplicity of the language.

The project I'm working on now is a database, which, as you can imagine, is performance critical. At the moment I'm using C and some python, but it will eventually be predominantly, if not entirely C.



C is a low level language and there are situation which C is almost the only option like I use C for programing micro-controllers, or put some code together to interact with devices from classic ports like Parallel, Serial or even Modem!


Yes. I spent most of my career programming C++, but now I write most of my code in Ruby and if I need performance or access to low level stuff I write a C extension. It's the future Man!

  • Some answers addressed portability and speed as the benefits of C code, but linkage is another important characteristic. It's relatively easy to link "foreign" code written in C because of its simple "classic" stack discipline. Many C compilers will allow "inline assembler" as a convenience to go very low level in an architecture (obviously sacrificing portability in the act).
    – hardmath
    Dec 15, 2010 at 3:54

I would use C if I was writing an operating system. Since that is not going to happen in the next twenty years, unless I hit lotto and have nothing else to do but make my own awesome Linux distro, I'll probably just stick to C#, Java, Python, etc, etc. I haven't used C in a very long time but I always enjoyed using it; I think though, these days my head is so wrapped around OO if I have to go back to it it'd take me a bit to get rolling again.


C++ is portable across platforms and embedded devices like microcontrollers. (C++ can be compiled to C, therefore microcontrollers.)

C is even portable (as foreign functions) to other languages. Therefore, iff I program low-level libraries, then I want more compatibility than C++.

Haskell is portable across platforms (ARM is coming soon) but NOT embedded devices like microcontrollers. Its speed is comparable to C and C++; but because it is functional, it uses a garbage-collector instead of an runtime-stack, therefore it can be faster and slower than C at different times (garbage-collecting) and in different situations (continuations instead of sub-routine calls).

I choose the most abstract language possible, because the program speed does not differ but the development time and bug-rate. C and C++ differ much, but not from the point of view of Haskell.

I do not prefer other languages, even though I know one or two hand full. …except in a few cases, well, bash.


Embedded systems frequently have no more than a few kilobytes of RAM and perhaps a couple dozen kilobytes of flash, with a processor clock rate of a few MHz. C is the only option that makes any sense in such a bare-metal environment.

Not the answer you're looking for? Browse other questions tagged or ask your own question.