views:

5755

answers:

26

Since C++ seems to have all of C's features, why learn C over C++?

+1  A: 

C++ is basicly C with some new features, such as classes for instance. If you are new to programming you should concider learning C first. You shouldn't be able to dig too deep down before you know the foundations.

Filip Ekberg
I wouldn't do that. Good C++ programming has little to do with good C programming so starting C++ after you're good at C will just mean you have to do a lot of unlearning.
+15  A: 
  • C requires less runtime support (useful in low-level environments, such as embedded systems or OS components)
  • C is compiled faster ;-)
Timbo
compiled faster? hey.. thats argumentative, depending on the compiler and the target system :P
Filip Ekberg
@Filip Ekberg, I still say in most cases.. it is compiled faster.
Simucal
Has anybody ever created a project functionally equivalent using C and C++ and then compared compilation time? A C++ compiler is generating a lot of code for you "under the hood", this takes more time - as you'd expect. If you write that code in C, how does the copmile time compare?
Richard Corden
yeah its compiled faster, but who really cares that much about compile speed? :D
CrazyJugglerDrummer
It only compiles faster because C programs do such simplistic tasks! C is for Cimian, that's good enough for me.
Kieveli
+6  A: 

There are many situations that C is still useful. First, it has probably the biggest code page available. Many open source projects (os kernels, toolkits, web servers, http clients) are written in C. I don't think that these are going to be ported in another language soon. So if you want to be a contributor to a major open source project, you need to know C well. The same applies if you need to support legacy code.

C is also mainly used in embedded software projects. Micro-controllers have limited resources and C is better suited for them than C++. Most device drivers are also developed in C.

kgiannakakis
+67  A: 

One reason you might program in C is if you intend to read the generated assembly code. C++ does name-mangling, generates virtual tables for classes that use virtual functions, and other such things that will make the resulting assembly code harder to read (although I'm sure that doesn't scare some programmers). I'm a bit of an assembly noob and I sometimes write C code just to see what kind of assembly the compiler generates for the purpose of learning. This can also be a good way to research optimization strategies, for instance.

Another reason to stick with C is if you have a project or team where the advanced features of C++ are seen as a risk. Perhaps the project has a very straight-forward design and you don't want there to be any excuse for team members to get fancy with a complicated class hierarchy (this is more of a team management problem than a real tech problem, obviously). The decision to go with C may force project members to approach the problem in a simple way, although one hopes that such management trickery would never be needed in the first place.

Simucal made good comment on the above point in one of the other answers: "I know that the decision to code Git in C vs C++ was partly due to that. Linus was raving about the number of "bad" c++ programmers and how using C instead, he was keeping a huge amount of poor developers out." (link added)

Yet another reason I can think of to go with C is if you need to write a compiler for your target platform because there isn't a suitable one available. This is highly hypothetical, but if I found myself in a position of trying to bootstrap a software development pipeline for a hardware platform without existing compiler tools, I'd start by writing a C compiler because it's far easier to do so than to write, say, a C++ compiler.

One reason to learn C (but not necessarily use it) is to gain insight into the roots of programming. C was an extremely influential language that helped shape Unix culture as well as all of modern computer technology. One can better understand the design of C++, Unix, and even how assembly code works by having a detailed knowledge of C. It's yet another important puzzle piece in understanding how computer technology all fits together.

Parappa
Very good answer. Also embedded systems, working with low level systems and operating system internals, etc.
Simucal
Aslo, if you bitch about strings in C++ you should do you own String implementation in C. For good practice!
Filip Ekberg
I disagree with your second part. Strongly. This is ultimately a failure of the team to communicate properly. Imposing arbitrary restrictions is a poor way of handling this.
Konrad Rudolph
I mentioned this elsewhere, but Linus Torvalds decision to write Git in C was in large part due to him wanting keep bad developers out. He ranted and raved about the number of bad c++ programmers out there and how writing in C by definition will keep many out.
Simucal
@Simucal: I just included your quote from Konrad Rudolph's answer. Good to see you recap it [email protected]: I agree that in a *typical* dev team, it would be a horrible reason to go with C, but it is possibly a good idea in a special case.
Parappa
Here is the link to source with Linus: http://lwn.net/Articles/249460/
Simucal
C++ does name-mangling - extern "C"?advanced features of C++ - small language subset?This is highly hypothetical - but really!insight into the roots of programming - you'll have these as well using the same language features in C++.
Vadim Ferderer
I mention the "roots of programming" thing because it becomes clearer once you learn where the line between C and C++ is. I am one of those programmers who learned C++ first and then C, so I think it helps knowing what exactly is specific to C++.
Parappa
Some low level hardware, that can run code, only have C comilers, and no C++ compilers. Anything you want to use as a library on this type of hardware will need to be written in C.
Kieveli
Writing a full application in C "because it will be easier to read the resulting assembly code" is a weak reason, IMO. Tipically, you'll need to optimize (and mess with the resulting assembly code) at maximum 10% of the program, if the type of application is bound on performances. You don't need to mess with assembly language on the rest of the applications.
friol
+2  A: 
  • C is much easier to learn then c++
  • C is slightly easier to master then c++
  • C has a wider support of processors then c++
  • it is easy to shoot yourself in the foot with both, but c++ has more class
  • you would learn c as part of your c++ studies anyway.
Raz
I believe that your first point is fundamentally wrong. Starting with learning C++ is much easier for new programmers than starting with C even if the language has some features that are extremely complicated.
Konrad Rudolph
@Konrad, i would have to disagree. If you think about it, the fundamentals of programming is what? I would say when starting programming need to be simple, light-weight, strucuted and straight forward. C has a benefit, you CAN'T do advance stuff ( as you acn in C++ ) if you don't know Exactly how.
Filip Ekberg
@Konrad it would be nice to show us why C++ should be easier. You have to understand more in C++ than in C to get your first program running
Friedrich
@Friedrich - Starting with "Accelerated C++" is pretty easy.
Vadim Ferderer
C is a much smaller language then C++, requires a much smaller set of knowledge. After all c++ is a considered a superset of c (which is not accurate but close enough). since it is smaller, it takes less time to learn the basics. the knowhow take much, much longer.
Raz
Raz
Raz: your argument is fundamentally and fatally flawed: “since [C] is smaller, it takes less time to learn the basics.” This reasoning is simply wrong. Since C is smaller, it is certainly easier to *master* it. But since it offers less help, it's much harder (!) to learn the basics than in C++.
Konrad Rudolph
@Konrad - I can see your point and I think it is valid. Going to the next stage of capability and understanding is much easier once you mastered c++ then C. I was referring to to this initial stage saying it was easy. I agree that once you got over the basics. c++ is much better.
Raz
+4  A: 

There is none. Even if you don't use the whole C++ feature set C++ still offers some substential advantages over C. This is why some of the other arguments mentioned here fall short of reality:

C is compiled faster

For normal code this is definitely true. C++ does some really wacky stuff at compile time which, unfortunately, is time-consuming. However, if compile time really matters, you're able to write code that compiles just as fast as equivalent C code.

C requires less runtime support (useful in low-level environments, such as embedded systems or OS components)

Also true. However, there are special stripped-down versions of the C++ runtime for embedded systems. Again, this drastically diminishes C++' advantage over C but it still has advantages!

First, [C] has probably the biggest code page available.

Not an argument, since all of this code can be directly used from C++. However, this is obviously true:

So if you want to be a contributor to a major open source project, you need to know C well.

So yes, in such a situation it really pays to know C. Another reason are the aforementioned embedded systems. While there are C++ compilers for some of them, this is not true for all environments and sometimes it's simply a cost factor that speaks against bootstrapping a C++ compiler to work here. Generally, if no specialized compiler for a given platform exists, don't use C++ there.

However, I would still strongly advise first learning C++ and then "downgrading" to C because C++ is much easier to learn. I've talked about the reasons before.

Konrad Rudolph
What about Parappa's point of "advanced features of C++ are seen as a risk". I know that the decision to code Git in C vs C++ was partly due to that. Linus was raving about the number of "bad" c++ programmers and how using C instead, he was keeping a huge amount of poor developers out.
Simucal
+1 Excellent answer.
Parappa
@Simucal: I'm sorry but I don't put much stock in what Linus has to say here. Concerning C vs. C++ (or just generally programming), this guy expresses too many wacky opinions to be taken seriously. He may be a brilliant programmer but he has some severe shortcomings in the area of argumentation.
Konrad Rudolph
I agree with you that he is a little wonky. However, I do see some logic in the fact that C++ has many, many more ways to shoot yourself in the foot or do things in cludgey ways. With an experienced team this is a non-issue but I could see in being one with a loose team of varying skill level.
Simucal
+3  A: 
  • Simplicity
  • Portability
  • Maintainability
  • Interfacing to Scripting Languages

In all this areas C has an advantage over C++. C is a very matured language and backward compatability was always very high on the list. One can say just with ANSI C 99 this has changed, because then some new things were introduced (e.g complex numbers) before they were in widespread use.This has let to the situation that, people do not use some of the ANSI C99 stuff because their compiler does not support them. But one still can even compile K&R C with the current C compilers. Maybe in the COBOL or FORTRAN world something comparable can be observed...

Friedrich
You gotta be kidding me, you win the price! I've never seen anyone use d the words "simplicity", "portabillity" and "maintainabillity" with C or C++ :D I agree on c++ being too complex.
Filip Ekberg
I would argue with maintainability but I agree with portability. ANSI-C will run on pretty much anything. Sure - the higher level libraries will not be portable but the language itself very-much-so is.
Nick
I'm sorry, but maintainability means also that your code once written will run with another version of your compiler also. My understanding is that you can not count on backward compatability in one compiler line but also not with cross-compioer compatability.
Friedrich
C isn't simple and it is a maintainability nightmare when the code base grows out of small proportions. See Lua and PHP for example.
the_drow
Well every large code base get's nightmarishly. C is simple in comparison to nearly other programming language. Or what do you understan under an "simple" programming language?
Friedrich
+3  A: 

You might also find this thread interesting:

http://stackoverflow.com/questions/211686/what-do-you-miss-when-you-have-to-use-c-instead-of-c

sharkin
+1  A: 

what is the gain then

constraining self by forms that

limit expression?

Pete Kirkham
Is this meant to be a comment?
Simucal
no, it's meant to be a haiku.
Pete Kirkham
+27  A: 

Linus Torvalds has a pretty strong opinion on the matter.

He was asked the following concerning his Git version control system:

When I first looked at Git source code [it] struck me as odd: Pure C as opposed to C++. No idea why. Please don't talk about portability, it's BS.

His reponse is pretty entertaining:

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

  • infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

  • inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

Simucal
This isn't necessarily my opinion btw, I just found Linus Torvalds take on the issue entertaining.
Simucal
yea those comments are famous :)
Ric Tokyo
When all you have is a hammer, everything looks like a nail...
Greg Hewgill
LOL! Those comments sound very much like the comments assembly language programmers use to make about C programmers.
Ferruccio
And they also look a lot like the argument C++ programmers make about Java.... Interesting.
Bill K
Maybe we have stumbled on to something...
Simucal
It is amusing, but also very skewed. Very few people need ultra-portable source code touched by thousands of unvetted contributors, many of questionable skills. For the vast majority of projects on the planet, C++ is a superior tool to C.
Euro Micelli
@Euro Micelli, yea.. I think that is key. If you have a lot of varied skill level I think c++ could be more of a nightmare than C. If your team is all of similar skill level (medium to high), I could see it being a much better tool for you.
Simucal
and here is Stephen Dewhurst's response to Linus's claim. http://stackoverflow.com/questions/385297/whats-wrong-with-c-compared-to-other-languages/696595#696595
Comptrol
I guess Linus has never seen a C program that had turned into MACRO soup. Bad programmers can write bad, unmaintainable code in any language.
jmucchiello
@jmucchiello, actually I'm pretty sure he has seen plenty of bad C code. Just because bad code can be written in any language does not mean all languages are equal as far as how easy it is to do so.
Simucal
This only proves Linus can't tell the difference between a good C++ programmer and a bad one. His line of reasoning is incorrect, IMHO.
Matt Fichman
@Matt Fichman, I think you sort of missed his point. There are some fine C++ programmers. But, when you are dealing with groups of programmers of varying skill level (like the people working on an open source project) then it can be too easy to shoot yourself in the foot with less-experienced programmers. He found that C was the better choice in that case. He just said it colorfully.
Simucal
+20  A: 

One very good reason is that C has a de facto standard ABI on most platforms, while C++ doesn't.

dsimcha
Great point. On Windows, for example, this lets you write dlls on different compilers and they still work together. The non-compatible ABI is apparently an intentional design feature of C++. Thus, we get extern "C" hacks in any c++ dll exports
kibibu
+9  A: 

Portability has been mentioned before but it has not been stressed enough. Something written in C89 (ANSI 1989 Standard) is EXTREMELY PORTABLE, it is literally referred to as portable assembly. If portability is your key concern, C89 is the way to go. Nothing, I mean nothing is more easy to port than something written in C89. Rest assured that you will find a C89 compiler for almost any hardware.

Nikhil
Are you sure you are not talking about C99?
the_drow
No. I am not. C99 is relatively new and its portability is limited as compared to C89.
Nikhil
-ansi -pedantic -WAll -WError
Mike Weller
+3  A: 

C is a much smaller language with fewer but extremely stable functionality. - It has many flaws, however these flaws are widely known. - The flaws in C can easily be managed through the use of conventions, guidelines and recommended libraries, some of which can be specified by the project. - It is widely supported, and is much the same everywhere you go.

In addition, because C is much smaller, it is also much simpler - yes, you do have to deal with pointers and low level detail, however good programming practice in C is to use functional decomposition to abstract these details wherever possible.

Naive or unskilled programmers can easily be knocked about and forced to conform to the project because the guidelines needed are very small.

In C++, however, it is a huge language that is constantly evolving, functionality that should've been avoided in projects 5 years ago should be recommended today, and vice versa. It has functionality that can be used one platform, but can not be used on another, and the style of C++ is a topic that has yet to mature.

Caveats: - my usage of 'smaller', 'widely', 'much the same', 'everywhere', 'huge' are all relative terms, not absolute. - I'm a C++ fan, and love the language - Simplicity, however, is not in C++'s lingo, although it has been said that within C++, there's a smaller, simpler language struggling to emerge.

Arafangion
+5  A: 

Two quick points:

  • Embedded systems come to mind, C is less resource-hungry
  • Portability is also a point as C compilers are more easily ported

But for larger systems, I tend to go with C++ over C almost all the time.

Dirk Eddelbuettel
+1  A: 

Almost all high performance stuff. There is also COBOL which is highly recommended for processing high amount of data. Probably your phone bill is printed by a mainframe running a COBOL program.

Havenard
+2  A: 

C is more portable and faster than C++.

Many embedded projects will probably use C.

GIT is written in C, linus hates c++.

Byron Whitlock
More portable? Probably. Faster? Thems fighting words: there are so many different variations of how you can use both languages and so many examples of each being faster than the other for particular uses, that it's almost meaningless to make a blanket statement like that. If you want to stand by it you should give some specific examples.
quark
+5  A: 

The performance differences between compiled C and compiled C++ are very minor (but sometimes relevant nevertheless). It's largely a stylistic choice (with profound consequences to your software design mind you) although on some more arcane platforms you may find easier access to C compilers than C++ compilers (although gcc is almost ubiquitous these days).

Some have strong opinions about this. Linus Torvalds famously ranted against C++:

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

  • infinite amounts of pain when they don't work (and anybody who tells me
    that STL and especially Boost are stable and portable is just so full
    of BS that it's not even funny)

  • inefficient abstracted programming models where two years down the road
    you notice that some abstraction wasn't very efficient, but now all
    your code depends on all the nice object models around it, and you
    cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

So to answer your question any project where performance really mattters is suitable to written in C if you're so inclined.

cletus
+3  A: 

C compilers are easier to implement than C++ compilers

Lawand
That's an understatement :). I'm not sure it answers the question though.
quark
+8  A: 

C is also a language whose specification can (more or less) be described in detail in a fairly slim volume. When I meet a competent C programmer, I can be reasonably sure that she or he is familiar with 90% (or more) of the features of the language.

Compare and contrast to C++, where I'd guess that a large number of people developing in it don't even know about, much less use, a huge percentage of the language features. On the one hand, that means the language has lots of power and flexibility. On the other hand, it means that for any given C++ project there's more likely to be code that's going to be using some feature that a nontrivial number of developers have no idea how to use.

It's hard to overrate simplicity.

peterb
You can make that argument against almost all modern languages. I seriously doubt the average .NET programmer is firmiliar with 90% of the BCL.
Billy ONeal
A: 

Some have asked for a real-life project written in C and C++.

TrustLeap G-WAN is a Web Application Server which is faster (in user-mode) than IIS 7.0 (in the kernel). G-WAN ANSI C89 ('edit & play') scripts are 5x faster than ASP.Net C#.

G-WAN is up to 38x faster than Apache. G-WAN is up to 25x faster than Nginx.

G-WAN was started in C++ and then converted to C because of the '++' overhead. The gain was not only in footprint (currently 106 KB), but also in performances (~180%).

If you want to know what makes C++ so bad, just try virtual inheritance and virtual functions, and then compare the machine code générated by the C++ compiler with a clean C implementation of the same features (the C++ code is twice larger -and slower).

Conclusion: if you are targeting performances then you can use C++ as long as you write C code compiled with a C++ compiler.

In my humble opinion, Linus is a programmer that make systems work, and Bjarne is a programmer that uses the systems created by programmers like Linus.

There should be no surprise that system users are less technically inclined than system engineers.

I have a hard time going along with the comment that Bjarne is less "technically inclined" than Linus simply because one wrote a kernel and one wrote a language spec. On the contrary, I would argue that Bjarne had the much more difficult job.
San Jacinto
A: 

Best I remember, if you want to develop device drivers on Windows you had to use C. The dev kit didn't support C++. (This may have changed.)

Slapout
+1  A: 

Some other answers have mentioned that C is good for embedded programming because resources are limited. One reason why C is better in embedded environments is because you have a better sense of memory usage by data structures. When a C++ class get instantiated, it's hard to tell how large that object will be because of inheritance. This problem can be mitigated by limiting class hierarchies to be only a few deep. C++ templates also cause a similar problem. Heavy usage of templates can really increase the footprint of the executable. Just because these features aren't in C doesn't mean that you won't get similar memory problems. But, if you do, it's a little easier to track down where memory is being used.

zooropa
+1  A: 

Jacinto,

If only Bjarne had done something that made sense, my comment would have been less severe.

But C++ is "not a better C", it's a drama -and Bjarne himself has several times recognized it:

http://g-wan.ch/en%5Fcpp.html

  • Pierre.
Pierre
+1  A: 

There are certain cases where it makes sense to use C, such as writing device drivers or kernel modules. A lot of people argue that C's simpler feature-set leads to a much simpler, maintainable code base. But honestly, I get the opposite impression when it comes to large projects. I simply can't imagine writing a large project (>100K lines of code) in straight C these days.

If you actually spend time reading a lot of C source code, especially for large projects, you invariably find that one way or another the designers end up reimplementing C++ features such as virtual functions, inheritance, templates, etc., using wacky macro tricks, function pointers, preprocessor token concatenation or what have you. The fact is, its simply harder to reuse code in C because you don't have the facilities of object-oriented or generic programming at hand, and so you either have to copy and paste code, or use macro tricks to emulate these facilities. To say that this is more maintainable than modern C++ code is insane.

Charles Salvia
A: 

And, just to piss off the OOPs:

C has better support for encapsulation.

C++:

/* foo.hpp: */
class Foo
    {
    private:
        int not_part_of_the_api;
    public:
        int getint();
    }

/* foo.cpp: */
Foo::getint()
    {
    return not_part_of_the_api;
    }

C:

/* foo.h: */
typedef struct foo Foo;
int foo_getint(Foo*);

/* foo.c */
struct foo
    {
    int not_part_of_the_api;
    };

int foo_getint(Foo* self)
    {
    return self->not_part_of_the_api;
    }

Which one do think will need the user to recompile if you change something that's not_part_of_the_api?

David X
I think in C++ this is called the private implementation idiom (pimpl), and I don't see the reason why this same lay-out couldn't be used in C++. Isn't the downside that in the "C version" the struct always has to be dynamically allocated which might not be desirable in all cases? (In C++ implementation of the pattern, the class exposed to the user can trivially take care of the dynamically allocated implementation class.)
UncleBens
Well, you *can* do it in C++ (and probably a bit more easyly), but the practical point was that people *dont* do this in C++, because `private` sounds like all you need for encapsulation, whereas if you want an opaque data type in C, you pretty much have to do it this way, which happens to accually work. (The impractical point was, as stated, to mock and annoy object oriented C++ programmers.)
David X
A: 

Here's a list of differences I documented a few years back, with a few additions:

C is an old byte processing language with

  • No namespaces (no syntax grouping names, injecting names, or pulling out a custom overload when needed, causing the used operator/function to change without any additional code, all within the intended scope and for the intended identifier)
  • No template metaprogramming (preprocess until you have to start debugging your preprocessor output)
  • No operator/function overloading
  • No generic containers
  • No generic algorithms
  • No RAII
  • No exceptions (no automatic RAII cleanup via stack unrolling, needing manual cleanup code)
  • No polymorphism
  • No references
  • No specialized casts (one cast does all, no intention documented, not easily searchable)
  • No using keyword in class-context
  • No allocators (no way to switch between debug-build memory allocation and release-build memory allocation with ease for any chosen type)

With the new C++0x features that are already supported by some implementation vendors,

  • No generic reusable hashing component
  • No atomicity support
  • No Thread Support
  • No lambda expressions
pwned