When is C really necessary?

[KarlisRepsons]

Dear all,
there are quite a lot of examples, where people (even knowing C++ no worse than C) choose to use C. I've read Linus Torvalds cursing C++ (well, he uses strong words often enough), some time ago I was watching some programmers of banking software and they used more C than C++ too etc.
The questions are:
1. when is C so much practically faster than C++, that it's obviously superior?
2. in what cases is C more safe than C++?
3. do I get it right, that it's generally easier to make a mistake with C, unless C++ features are used without knowing the elementary part of their implications?
4. in what cases it's best to mix C with C++?

I'm sure, I'll have a Qt C++ GUI, but have doubts about a related library, which might later be used in other ways...

[Bazzy]

1. Never since you can use C constructs in C++
2. The C++ way of doing things is much safer than C where different
3. "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." ( Stroustrup )
4. If you use C++ you'll be using many things that are in common with C

[Disch]

1. when is C so much practically faster than C++, that it's obviously superior?

Never

2. in what cases is C more safe than C++?

Never

3. do I get it right, that it's generally easier to make a mistake with C, unless C++ features are used without knowing the elementary part of their implications?

It's easy to screw up in either language. Writing code in C generally isn't really any easier or more difficult than writing code in C++. It's more about style differences.

Although one could argue that C++ template library and other features make it easier. Of course that's open to interpretation.

4. in what cases it's best to mix C with C++?

This is a style preference. You use whatever task is right for the job.


Personally I don't see why anyone would want to write straight C anymore unless there isn't a good C++ compiler for the target platform. I think Bjarne had a similar quote.

Even if you don't like C++, you can still write C code and use a C++ compiler. The benefit of this is you have other language features at your disposal should you ever decide to employ them.

But again it's all a personal preference. Some people just really don't like C++ and would prefer to write in C. Don't ask me why... I don't understand it myself.

EDIT: doh, too slow

[moorecm]

I agree with the previous posts. The only time that I write in C is when I'm maintaining an existing C library/application and even then it is often easy to incorporate C++ modules.

[blackcoder41]

3. yeah i find it harder to work without classes (object oriented).

+Disch

[helios]

C is typically preferred over C++ in these situations:
* The project is a kernel driver for a kernel that requires or heavily prefers C drivers (most do).
* The project requires semi-portable dynamic linking. This is one of the few things C++ really sucks at.
* The project has to be ultra-portable, or the target platform doesn't have a C++ compiler.
* The project members dislike C++.

As for making mistakes in either language, yeah, neither will cause you to make fewer mistakes, but C++ lets the cautious programmer set up safety nets that either make screwing up harder, make screw up painfully obvious, or limit the possible damage that screwing up could do. For example, proper use of RAII will never let you claim a resource without freeing it. Type checking will keep you from accidentally doing stupid stuff like writing to read-only memory. References guarantee that the "pointer" being passed is valid.
The main difference between C and C++ programs is that the latter tend to place more responsibility on the compiler to ensure some degree of correctness, while the latter former tends to use the compiler to just generate code and depends mostly on run time results to verify correctness.
That's what the "makes it harder to shoot yourself in the foot" part means. The "you blow off your whole leg" bit means that, when something does manage to slip by this array of safety mechanisms, it's usually something very nasty. Probably non-deterministic memory corruption due to a race condition caused by a one that should have been a zero.

[Bazzy]

* The project requires semi-portable dynamic linking. This is one of the few things C++ really sucks at.

You can extern "C"

[blackcoder41]

The main difference between C and C++ programs is that the latter tend to place more responsibility on the compiler to ensure some degree of correctness, while the latter tends to use the compiler to just generate code and depends mostly on run time results to verify correctness.

what do you mean here? "the latter" then "while the latter". are you describing just the C++ language?

[KarlisRepsons]

semi-portable dynamic linking

what is that?

As I remember, primarily Linus was complaining, that C++ allows people to do things, which they don't grasp the computational cost of. That seems to put "1:Never" in doubt...

Not counting the historical reasons, what else makes kernels to be written in C?

[helios]

what do you mean here? "the latter" then "while the latter". are you describing just the C++ language?

Fixed.

Actually, that's wrong. The correct term should be "semi-portable linking", and by that I mean linking that works between binaries compiled by different compilers or compiler versions. Due to name mangling, this isn't possible in C++. That''s why C++ libraries and the programs that depend on them have to be built by the same compiler, otherwise you'll get linker errors.

[KarlisRepsons]

C++ libraries and the programs that depend on them have to be built by the same compiler

Exactly same or what's the "critical level" of differences?

[KarlisRepsons]

C and C++ programs is that the latter tend to place more responsibility on the compiler to ensure some degree of correctness, while the former tends to use the compiler to just generate code and depends mostly on run time results to verify correctness.
That's what the "makes it harder to shoot yourself in the foot" part means. The "you blow off your whole leg" bit means that, when something does manage to slip by this array of safety mechanisms, it's usually something very nasty. Probably non-deterministic memory corruption

I was thinking, that "you blow off your whole leg" means, that it's more easy to make such stupid software modules, which later turn out to be fundamentally unusable and can't be just fixed, rather all thrown out... Was just a guess though.

[Disch]

As I remember, primarily Linus was complaining, that C++ allows people to do things, which they don't grasp the computational cost of. That seems to put "1:Never" in doubt...

That's true of C as well... and really any library for that matter.

If you don't know what a library is doing under the hood, and you use it improperly, then yes it's possible to produce less than efficient code.

On the other hand, the standard C++ libraries are well defined and if you understand them then it's not difficult to write simple code that's just as efficient as (and sometimes possibly even more efficient than) the C counterpart.

One particular example that I like is printf vs. cout.

printf("%d",myint);  // C style approach
// vs.
cout << myint;  // C++ style approach 

The C++ style approach is safer AND more efficient than the C style approach.

It's safer because:
- printf doesn't check to see if 'myint' actually is passed or not. It's perfectly legal syntax to call printf("%d");, but the result is a potential program explosion.
- printf has no type information about 'myint'. If you pass a double instead of an int, it will compile without error, but will not output what you expect.

It's worth nothing that some compilers have improved to detect both of the above scenarios and will issue a warning if you do either one of them. So in that sense, compilers have made printf a lot safer than it used to be.


It's more efficient because:

- printf has to parse the passed string and find all of the '%' format tags
- printf has to determine which type 'myint' is supposed to be at runtime
- cout has no string parsing, and the type is determined by the compiler at compile time

[helios]

C++ libraries and the programs that depend on them have to be built by the same compiler
Exactly same or what's the "critical level" of differences?

Exactly the same.

[KarlisRepsons]

C++ libraries and the programs that depend on them have to be built by the same compiler
Exactly same or what's the "critical level" of differences?

Exactly the same.

Crazy world! Means, if my whole system was entirely in C++, I'd have to recompile everything on each GCC upgrade? Perhaps that itself rules out use of C++ for the core system components?

[Duthomhas]

Even different versions of the same compiler often make a difference.

[chrisname]

The C++ style approach is safer AND more efficient than the C style approach.

But printf() is print fast and fprintf is faster print fast, so the C way has to be better, right?

- printf doesn't check to see if 'myint' actually is passed or not. It's perfectly legal syntax to call printf("%d");, but the result is a potential program explosion.

The glibc version does, it generates a warning if you don't pass an argument or not. But obviously most implementations won't check that, so yeah, you'd likely get a segfault when it tries to access whatever is after the formatted string.

[Disch]

which is why I made note of that in my post @ chrisname =P

That has to be compiler magic though. printf can't possibly see what the passed arguments are before they're passed, can it?

[helios]

No, the compiler does that, not the runtime. All printf() sees is a format string and the stack that was pushed X more times. There's no way it can know what types were passed from the caller, so there's no way it can do any sort of integrity check. If there was, it wouldn't need the format string in the first place.

[blackcoder41]

so in simple words it's Reliability (C++) VS Performance (C) ?

IMO C++ FTW.