C++ and C

[Frank14]

Hi all,

I've heard about both before but recently I was surprised by the opinions of Linus Trovalds.
There are many threads on comparing the two and I read some of them but still sometimes I hear some things in favour or on the side of C against C++!

I think C is good for kernel coding as in Linux and Unix kernels. It's much simpler than C++ and it's completely close to hardware making it a low level programming language.
C++, on the other side, I think, uses the advantages of OOP, has better speed resulting in better performance (for game applications for instance), is a low and also high level programming language. But these are at the cost of complexity.

Briefly, C is like a traditional typewriter while C++ is an electric typewriter.
Am I right wholly, please?

[JLBorges]

This thread may be of interest: http://www.cplusplus.com/forum/general/152477/

[helios]

I've heard about both before but recently I was surprised by the opinions of Linus Trovalds.

It's worth noting that when Torvards wrote that post some his opinion likely originated from a time when the C++ standard was new (or in development) and poorly supported by the major compilers. Back then there was also a lot of hype surrounding C++, so I'm willing to bet we was experiencing a bit of hyper backlash, like when everyone tells you to watch a show and that makes you not want to watch it.
Also, some of his complaints were less about C++ itself and more about novice programmers, which back then there were a lot learning C++, just like how today there are a lot learning JavaScript
(As I write this, I realize that my opinion of JS is not too different from Torvald's opinion of C++.)

It's much simpler than C++ and it's completely close to hardware making it a low level programming language.

Both C and C++ are high level languages. C++ is capable of going as close to the metal as C.

C++, on the other side, I think, uses the advantages of OOP, has better speed resulting in better performance

C++ code in general does not perform better or worse than C. Although it's subjective, well-designed C++ can perform as well as C while being easier to comprehend at a glance, even if internally what the code may actually be doing may be quite complex).

Briefly, C is like a traditional typewriter while C++ is an electric typewriter.

I prefer to think of C as a Ford T, while C++ is a modern car. You can more or less accomplish the same (go from A to B) with either one, but all other things being equal the latter is safer and more reliable. Yes, a modern car is more complex, but that's because it has more features. We can argue about whether those features are worth the added complexity, but in the end that's a matter of opinion.

Here's an example of how using C++ helps you write safer code. In C this is a common pattern:

void foo(){
    lock_mutex(&mutex);
    //...
    if (bar){
        unlock_mutex(&mutex);
        return;
    }
    //...
    if (baz){
        unlock_mutex(&mutex);
        return;
    }
    //...
    unlock_mutex(&mutex);
}

This code is pretty fragile. If a maintainer ever comes around and adds a new exit point, they must remember to unlock the mutex, otherwise the program may deadlock. In actuality, this is just a form of resource management, and it's similar to malloc()-free() pairs.
In C++ you would do this instead:

void foo(){
    std::lock_guard<std::mutex> lg(mutex);
    //...
    if (bar)
        return;
    //...
    if (baz)
        return;
    //...
}

The compiler takes care of properly unlock the mutex when lg goes of of scope (when foo() returns). Even if new exit points are added, even if an exception is thrown, mutex is guaranteed by the language to be properly unlocked once the function exits.
In C, every time you create a new resource you have to ensure that you're managing it correctly. In C++, you have the ability to design your classes such that you only need to get resource management right once.

[Frank14]

I took a look and thanks for the link. It seems (if I am not wrong) you're a fan of C more than C++. There are many other posts/links there too with rather high-level stuff probably bewildering for me. Would you summarize the comparison fairly?
I think you agree with my comparison in the first post.

[JLBorges]

> Would you summarize the comparison fairly?

I tend to agree (quite strongly) with Stroustrup on this.

I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.
http://www.stroustrup.com/bs_faq.html#C-is-better

Which is actually quite obvious, once we realise that anything that can be done with a subset can be done at least equally well with a semantic superset.


> Fairly?

Hmm...

I'm sure a fair number of C programmers (who haven't used C++ or used it without understanding it) would consider that statement to be extremely unfair.

And then there are a few others like this character http://www.cplusplus.com/forum/general/58900/#msg317870 who will now hate me with even more passion for stating the above.

As an aside: I was very new to this site at that time, this was my seventh or eight post; and this closed account S6k9GNh0 (IIRC, the actual name was something like ComputerEquipped) was lording it over with some bazillions of posts. I was convinced that I had come to the wrong site, till I was reassured by the posts of Cubbi and m4ster r0shi. In general, C programmers who "hate C++ programmers", with a few notable exceptions, tend to be very poor C programmers.

[Cubbi]

Frank14 wrote:

I think C is good for kernel coding as in Linux and Unix kernels.

Stroustrup's quote from JLBorges above applies here if you take into account the time dimension: when the first Unix was created, there was no C++. When Linux was created, C++ was in its pre-standard infancy and there were no good C++ compilers. When your project is in C, rewriting it in another language is almost never a good idea (GCC did switch from C to C++, though, so it's not totally out of the question.. but OS has more dependencies than a standalone application)

I've worked on a OS kernel, using C (again, that OS was initially written in 1980s, before C++), and I think it's an awful language for kernel development. I've fixed production bugs that could have been prevented by a stronger type system (like the one C++ has), by RAII (the key feature of C++), or by other C++ features that make it harder to shoot yourself in the foot than C (to borrow another Stroustrup quote).

Frank14 wrote:

It's much simpler than C++ and it's completely close to hardware making it a low level programming language.

as already mentioned, both C and C++ are high level programming languages with identical closeness to hardware. There's a popular misconception that C is a sort of a "portable assembly" and that a trained programmer could "see CPU instructions" by looking at C code. In reality, C compilers rewrite your programs as they see fit, although it's usually not noticeable unless you have errors (see http://en.cppreference.com/w/c/language/behavior#UB_and_optimization for some entertaining examples). And yes, Linus hates when the C compilers do that too - he needs a portable assembler.

[jonnin]

C has a few advantages over c++. Not many, but a few.

One of the most under-mentioned is that writing code that generates code is MUCH easier to get correct and efficiently done in C. A number of high level programs crank out robot generated C to this day, including a neural network package I use and a matrix package I use.

Another advantage of C over c++ is learning curve. C++ can take a good 3 years to master, maybe more, while C can be picked up in months.

At the end of the day, a good compiler will render similar assembler/machine code for either language, so speed should be really close. C++ may be a little slower (A lot slower if some of the built in containers are used improperly, but if used correctly, not so much) but the difference between languages and speed is linear. That is, in 1998 the difference between fast C vs fast C++ was still significant, it could be a few ms or more for small code translating to min/hours for big complex projects. Now the difference is still about the same, but computers are so much faster the difference is sub-nanoseconds instead of ms, scaling to seconds instead of min and min instead of hours ... unless your program takes days to run, you are unlikely to see any real savings in C today.

Those are the only 2 major reasons to pick C that I can think of. I prefer C's print statements for math (doubles, specifically) because all that setw and such 1) look like variables mixed with other variables and 2) they are visually messy. For just about everything else C++ usually has a better approach, and getting better all the time.

[Frank14]

Helios: Thanks so much. I appreciate your explanation. I enjoyed your preference on thinking of C as a Ford T car! :-)

Thank to others as well.

[Cubbi]

jonnin wrote:

C++ may be a little slower

C++ may also be a little faster. Or even a lot faster: unlike your typical C, it doesn't need quite so many indirections, runtime checks, and temporary results.
The only real case where C is faster is when the program uses non-aliasing pointers of the same type (something standard C can declare), but C++ compilers have non-standard compiler extension to do the same.

[Frank14]

JLBorges, Thanks sir.

I think by now the problem of lacking a good compiler is through when we have VS 2017 for C++. Agree?

[jonnin]

I would think C's arrays or Pointers would beat vectors due to not maintaining a size field, things like that, but I have not done a head-to-head comparison in 20 years so I could be way off. The containers have some (microscopic) hidden overhead, though. In other places, esp algorithms, the c++ should blow the C away.

[helios]

If anything, storing the size is an optimization. strlen() runs in O(n), but std::string::size() runs in O(1).

Cubbi: What do you mean by this?

non-aliasing pointers of the same type

[JLBorges]

> I think by now the problem of lacking a good compiler is through when we have VS 2017 for C++. Agree?

By now, all the three mainstream compilers/libraries have become good C++ implementations.


> What do you mean by this? non-aliasing pointers of the same type

http://en.cppreference.com/w/c/language/restrict

[Cubbi]

> What do you mean by this? non-aliasing pointers of the same type
http://en.cppreference.com/w/c/language/restrict

exactly. Also known as the origin of the trope "Fortran is faster than C"

[JLBorges]

Incorporating restrict into the more sophisticated type system of C++ would create an unholy mess;
but a standard attribute [[unaliased]] would have been quite useful for optimisation.

Particularly if it could also apply to non-pointer types:
void foo( [[unaliased]] std::vector<int>& a, [[unaliased]] std::vector<int>& b, [[unaliased]] int& c ) ;

[helios]

It doesn't need to be part of the type system, just a way to mark particular names in a scope. It's just a hint for the optimizer, like how register used to work.

[JLBorges]

> It doesn't need to be part of the type system

That is the raison d'être for suggesting that it be an attribute and not a qualifier. The distinction between a qualifier and an attribute is that a qualifier is part of the type system, while an attribute is not.
(In C, restrict is a qualifier.)