What is the most common applications of C programming in today's marketplace?
I'm wondering this as I'm working through my C book as the examples so far seem to run around making tax software or grocery store checkout registers work right(though I'm only on page 300 out of 700)....
I have been peeking around for a job in C programming with my noob skills and so far have only found a couple of mostly strictly C positions. One of them is a power company.
Looking forward to your answers
Don't call yourself noob... if you're reading a C book, you're not a noob at all (many people even think C is obsolete, trust me. I know a lot of people who think this way because they only think about OO programming). Answering the question, perhaps a program with structs to control products input for a store, like you said.
700 hundred pages ?! ah ... why don't you try the K&R Book? it's a great book and it's almost 300 pages long, only.
Haha. Actually it is Stephen Prata's book and I absolutely love it. The pages contain a lot of examples and white space, and as someone else on this forum once said, reads like a novel. I already bought his C++ book too.
In fact, I wish his book was longer. I find myself wondering what to do to continue to sharpen my C skills when I am done with it
As you walk deeper in the path of programming, you will find out that there is sooooooo much to learn....
In this link you will read interesting things.
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
I also like the second post of this thread. Don't call yourself a noob
We are currently programming a robot and we use C/C++ .
A software engineer of facebook that was speaking in an event I attended recently said that they use C/C++ too.
Of course in both sections I mentioned we use more languages.
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
I was a noob in July, but now in December, I consider myself an intermediate.
You are a noob and looking for C programming work? Don't kid yourself. Try again in maybe 5 or 10 years, after you have attained qualifications and experience.
PS - my BIGGEST tips for noobs is to learn how to use the debugger as soon as you can. It can save an enormous amount of time trying to fix coding problems. I've been programming for about 5 months, and only learnt to use the debugger in the 3rd month. Before that, I was asking for help here almost daily, but after learning to use the debugger, I hardly ask here anymore.
Last edited by cfanatic; 12-01-2012 at 06:21 PM.
I am a noob with a year of experience, including an internship and a formal class
I am merely interested in what types of jobs there are with C programming to pursue. I did not say that I have applied yet, but would like to have a sense of what options are available in the work place.
The definitions are subjective I guess. I opened my first book on C before the parents of some members of this site had met. And I still view myself as intermediate.Originally Posted by cfanatic
I was a noob in July, but now in December, I consider myself an intermediate.
Then again, I am not a programmer and have never sought to be. Any programming skills I have are a side-effect.
Embedded Systems EngineerWhat is the most common applications of C programming in today's marketplace?
Fact - Beethoven wrote his first symphony in C
I do think many employers blindly state C/C++, when they actually need a specific one, either C or C++. It seems that the misconception that C++ is "C plus something else" is very widespread. In reality, they are very different languages, and you cannot expect even an expert C++ programmer to produce good-quality C code, and vice versa. The root paradigms, the fundamental approaches, are just that different.
There are not that many Linux kernel developers, but based on the moaning about C++ at LKML and elsewhere it seems that companies that look for Linux kernel developers ask for C/C++, whereas the kernel really is C only. (Yes, there are now patches and whatnot to get certain C++ code to compile, but good luck getting that upstream. Won't happen.)
Also, on embedded Linux systems, a majority of the basic utilities are written in C. GNU tools are predominantly C, as is Busybox. Therefore, I'd also add close-to-metal Linux system maintenance and integration to the list. (C is not sufficient there at all, of course; it is just very useful. For integration, I'd say almost essential.)
Personally, I have never really been employed to develop Linux or any of the core projects, but I've been a sysadmin and whatnot -- a checkered career to say the least. As a side effect of fixing things I've submitted patches here and there. My users benefited from shorter service outages, as I could do temporary security patches -- I even spun a few ksplices, patching running kernels without reboot, when the open ksplice tools still worked --, read security mailing lists to determine whether known bugs would affect my clients' security, and inform them about it to get them to calm down and realise what the actual security implications are. And I got better job satisfaction: rather than applying bandages, I was actually fixing things. While I wasn't usually the first one to report a problem, I could verify and evaluate patches; it's close enough, and important as of itself.
I suspect C is much like Linux itself: many people just do not realize in how many places it already is. Because it tends to stay under the eye of the typical user, people don't see how ubiquitous it is.
In particular, I've never found a C proponent who was half as vocal as any of the dozen or so C++ proponents I know. Just because they are vocal, does not make them right. Personally, I've always found them (the vocal ones!) to be rather comical figures, holding a hammer and demanding to know where all the nails are, muttering about the superiority of passivated metals, while standing in a screw factory.
All that said, do not limit yourself by only learning one or one type of programming language. They all have inherent paradigms or approaches, and unless you learn to see outside that, your solutions will be severely limited. After you can work in more than one language easily, you can check out the type of work done in each. I'd say that in the long term, you'd be happier if you found projects and positions you find interesting, rather than looking at specifically the programming language used.
As to myself, I prefer the low-level, closer-to-metal, library-backend kind of work, letting someone else deal with user interfaces, glitz, and polish. That's why I prefer C. If I did more of GUI stuff, I'd prefer C++ or Python, I think. If I used or developed for Apple products, I probably would prefer Objective-C. I've used PHP a lot for web stuff, although I consider it quite a poor language security-wise. Whether these map in any sensible way to current job markets, I don't really know.
I wrote nothing but C code for 15 years, 10 of those professionally. Having gone through that and written somewhere around 500,000 lines of shipping code, I can say without any equivocation that C is an inherently inferior language to C++. There are two main reasons for that. Neither of these reasons have anything to do with OOP. The big two problems are lack of automatic resource management, and lack of templates.
By automatic resource management, I mean the ability to acquire a resource and be 100% guaranteed that resource will be released at the appropriate time. Whether by RAII (preferred), or a smart pointer system (sometimes necessary).
Templates are absolutely critical for anything performance-sensitive that requires a lot of closely-related but distinct cases. Without those, you're stuck with massive switch statements, dispatch through function pointers, or incomprehensible applications of complicated networks of macros.
Paradoxically, C is superstitiously held up as the only appropriate or safe language for a wide variety of safety-critical embedded scenarios, despite the prolific rate of occurrence of memory and resource-related bugs. Companies spend hundreds of thousands, or sometimes millions of dollars on giant test environments, static code analyzers, armies of QA engineers and exhaustive modeling to prevent bugs that, had the code been written according to an appropriate set of standards in C++, could never exist. Yes, I'm saying that the correct use of C++ 100% eliminates the potential for entire classes of bugs.
C++ is a big, complicated language with a lot of features a low-level programmer will probably never need. So don't use those.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
What you actually mean, is that C++ is much closer to your patterns of thinking, and that you feel much more productive and efficient with C++ than you do with C, after having considerable experience with both.
It's rather sad when people turn their own experiences into blanket statements.
BTW, I just added you to my ignore list. I really cannot handle your attitude, sorry.
I'm trying to plan for the future by keeping an eye on what jobs are out there. Right now, most job descriptions I'm seeing say C++ and Java, and then there is usually a random variety of other programs added on to that, which varies greatly from company to company. SQL, Linux, and Unix make frequent appearences, as does "lean and agile" - not sure what lean and agile are. Software engineering seems more popular then computer science jobs, too. Who let the C++ guy into the C forum?!? LOL.
