Would you use C, today, for a software project? [closed]

Question

If yes, where and why would you use it?

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

if it has to be both

• fast, and
• portable

then I use C. Maybe C++.

Answer 11

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.

Answer 12

Yes!

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!

Answer 13

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!

Answer 14

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.

Answer 15

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.

Answer 16

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.