Thread: Is C out of date?

Originally Posted by frktons

C language will still be there when you finish the university. C++ / C# / Java will be upgraded as well.
Do you know there are still people programming in Assembly for producing drivers and high performance software? Not to speak about the part of operating systems that cannot be written
in C or any othe language. C is sure will be useful for the next 10 years at least.

This is different. Take into account that C++ supports the entire C language as well as additional features. Looking at it from this perspective, C++ is a better C and it's a newer language incorporating features that make large programs feasible.
Neither C nor C++ supports assembly as a part of the language, so assembly is a language in its own right, and is required to be so. But C also exists as a part of C++, so the same cannot be said for C.
So why learn C? That, I believe, is CSaw's original concern.

Unfortunately, the reality is cruel. Many embedded systems only support C because they're too cheap to create a C++ compiler. Many companies still has legacy C code lying around. And a lot of people still use C for desktop applications even though it's insane.
So does C still have a meaning? Yes, unfortunately. Are you going to bump into C? That depends on what you're doing. Embedded programming? Highly likely. Desktop applications? Perhaps. Web programming? Probably not.

This is a silly argument. You can "roll your own" in pretty much any language you want. This isn't limited to C.
I might just as well argue that you should roll your own in C++ because it supports so many more features that can help you design more flexible generic code.
Don't choose a specific language just because it lacks a lot of stuff so you can roll your own. Rolling your own stuff can be done in any language and is equally useful.

Originally Posted by whiteflags

But they are two languages on separate roadmaps.

Honestly, I don't think so. The C++ standards committee is very interested in making C++ better for embedded systems, much the same as C is. Plus everytime a new C standard comes around, it gets integrated into the next C++ standard after it.
For example, C99 will be integrated into C++0x.

Where C and C++'s subset of C things are different are a frequent pest (and often FAQs) here at the forums.

Indeed. Usually, I think, it is because there is almost always a "better way" to do things. In am embedded environment, the "C way" is often the only way. But we don't see much of that here, though, I believe.

Originally Posted by whiteflags

Well maybe roadmap is a bad way to put it. They aren't, nor should they expect to be, developed in lockstep, and that matters. In fact this is more evidence to my parasite-host assessment of their real relationship. They're just evolving.

What exactly do you mean by lockstep? I know it is true that these standards take into account each other when being designed, though. C++ to be compatible with C and C not to overly break C++ or something.
If that's what you mean, then yes, I agree. It is indeed a parasite-host relationship.

You know people compile C as C++, and that is literally the whole problem? I've been here a long time and a question about microcontrollers or whatever is not only rare, but the compiling confusion is nonexistent in those folks.

No idea what you're getting at here

Originally Posted by Elysia

What exactly do you mean by lockstep? I know it is true that these standards take into account each other when being designed, though. C++ to be compatible with C and C not to overly break C++ or something.

I wouldn't say C and C++ are in lockstep at all.

It is true that the first C++ standard was required to both minimise incompatibilities with C and to document the incompatibilities.

The evolution of C after the 1989 standard, however, had no constraint for compatibility with C++ imposed. And the 1999 C standard introduced features that were incompatible with C++, despite being named similarly. C99 also introduced some features that originated during the C++ standardisation process.

I don't know offhand if subsequent proposed updates of the C++ standard have specifically sought to maintain compatibility with C99. In practice, it is likely compatibility with the 1989 C standard is mostly maintained, but there would be a divergence from C99. The extent of (or minimisation of) such divergence is going to be a decision for the standardisation folks.

A parasite-host description may once have been appropriate, but no longer, IMHO. It is now better characterised as a symbiotic relationship: both languages include features that, historically, had their genesis in the other. Both languages are now evolving separately, albeit that each is free to adopt features from the other.

It is also untrue - despite often stated - that C is a small language and C++ is a large one. They are now both large languages, although C++ is the larger of the two and implementation of a C++ compiler is often considered more technically challenging than implementation of a C compiler. That might explain why some systems only have a supported C compiler but there are few target systems that with a supported C++ compiler with no C compiler.

There have been some, in both C and C++ communities, who have suggested there needs to be some rationalisation of C and C++ into a single language that makes some feature trade-offs (i.e. pick the best of one or the other when there are mutual incompatibilities) in order to get a single language. However, there is also resistance in both camps, for both good reasons (eg some valuable features of one language or the other would be lost because of the necessary technical and non-technical trade-offs) and bad reasons (eg political and religious advocacy for particular features that would probably be better lost or modified in such a process).

Such is the way with evolution of real-world languages - which is what C and C++ both are, and will remain. It is very easy to implement a language if there is no past legacy (existing code, tools, programmers, etc). When there is a significant legacy and investment (eg large code bases that would require hundreds of man-years of reverification effort) it is not so easy to introduce substantial change.

I still find that silly. You miss out a lot of good language features by limiting yourself to C. Plus you're basically limiting yourself to the tools available in C and not in other languages.
Say you need to roll something on your own in C++. Are you going to global functions with void* pointers? That would be silly.
Plus you couldn't even do that in Java and C# and other languages.
You need to learn that when you roll your own stuff, you should also what is already available. A course in writing algorithms can be handy stuff. More so that limiting yourself to C, I'd say.

From the trenches, I can say that C isn't going away, but it's definitely not the language de jour any more. You'll find C in zillions of places, but out of sight. On your home wireless router, inside your printer, running the guts of your mobile phone... The Linux kernel is a strictly C-only beast, and you'd be laughed out of town trying to submit a device driver written in anything else.

Systems and embedded programming don't get a lot of exposure, and they aren't the "cool" thing to be doing, but they are still very much critical parts of the computing universe. Other languages are making headway, but it's like chipping pieces off one of the Great Pyramids. It's going to take a while. And certainly not until there's something better suited to the problem domains.

I'm enthusiastic that C++ can push its way into the low level arena, but I'm one of the few. I think it will only happen over time by actual demonstration -- i.e., people getting embedded C++ out there and working, convincing the rest of the community, on an empirical level, that it's actually possible.

If you're really serious about C, there will be good opportunities for the future.