Why We Use C Than C++...

[sonugeetha]

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

Cheers,
Balaji Jayaraman...

 

[EventHelix.com]

In a well developed C++ program, there isn't much difference between C
and C++ performance.

The following articles describe a mapping from C++ to C code.

http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm

The biggest performance hit in C++ comes from the implicit passing of
the "this" pointer in every
function. However, C++ more than makes up for this by better locality
of reference. This translates
to improved cache performance.

 

[Richard Heathfield]

(e-mail address removed) said:

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

Partly because C is faster (in places). Partly because it's simpler, so it's
easier to get right. But mostly, I think, because C came first. When the
kernel was first being written, C had already firmed up, whilst C++ was
still in a state of considerable flux. And, once it's /written/ in C, if a
reasonable job was made (which certainly seems to be the case), why on
earth would anyone bother to rewrite it?

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

Partly because C is faster (in places). Partly because it's simpler,
so it's easier to get right. But mostly, I think, because C came
first.

Another important factor is that C++ requires more run-time support
code to work properly.

DES

 

[Walter Roberson]

In a well developed C++ program, there isn't much difference between C
and C++ performance.

The following articles describe a mapping from C++ to C code.

http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm

I just read through those two articles. They are short on details,
make a lot of assumptions about -how- one programs in C; and the
conclusions are a bit of hand-waving not justified by the work that
has gone before.

In particular, I would say that the "Locality of Reference" conclusion
is based upon implementation factors rather than on language design,
and that the reasoning of that section appears faulty to me.

 

[Walter Roberson]

Another important factor is that C++ requires more run-time support
code to work properly.

The C++ Standard Library is many times as big as the C Standard Library,
And if one is reading through the C++ standard, it can be quite
difficult to figure out what the tradeoffs are between using the
several different approaches to any one task that are offered by
the C++ Standard Library.

 

[Walter Roberson]

All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++...

If I understand correctly, there has been work on C++ for the Linux kernel.
For example,

http://netlab.ru.is/exception/LinuxCXX.shtml

According to the Linux FAQ, C++ is not generally well received for
the kernel, for a variety of reasons. The FAQ includes a quotation from
Linus from 2004:

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse
in 1992, but some fundamental facts haven't changed:
o the whole C++ exception handling thing is fundamentally broken.
It's _especially_ broken for kernels.
o any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
o you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++
is either
o (a) looking for problems
o (b) a C++ bigot that can't see what he is writing is really just C
anyway
o (c) was given an assignment in CS class to do so.
Feel free to make up (d).

 

[henryk.mueller]

Another important factor is that C++ requires more run-time support

code to work properly.

Nope.

The objective of C++ is that you do not pay for features you do not
use.

C++ is not faster or slower than C if you DO the same.

For example: C functions have no parameter "this". But static C++
function do not have a "this" parameter either.

So, compare only apples with apples....

I use C++ in an embedded environment. Mostly because of it's better
code encapsulation. You can write small and lean wrappers for
interfaces that actually contain mostly inline functions. So you have
no overhead but you can protect the user of your class from using it in
an unwanted way much better than in C, i.e. forget to call init in C
vs. do the init within the constructor.

There are a lot examples of C++ features that are done at compile time
and have no effect at runtime. They all help you to write more robust
code. Reference objects vs. pointers, const methods, const return
values and all this stuff...

The are only 3 reasons to use C over C++:
- you have no decent C++ compiler for your platform
- you have to continue a C project
- you are not allowed to use C++ because your boss still believes that
C++ is SLOW

Greets

Henryk

 

[Andrew Poelstra]

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

Cheers,
Balaji Jayaraman...

As has been mentioned, C hides a lot of memory allocations and stuff
from the user-programmer; obviously, you don't want that happening in a
kernel.

What I think is a far more annoying problem is the fact that
interfacing C++ is Assembler is hard, because C++ mangles the funtion
names to handle overriding properly. There are more details in 'PC
Assembly Language' by Dr. Paul Carter.

When doing kernels, you'll likely be interfacing with lots of low-level
ASM functions to handle hardware interrupts and what not; C is the most
portable language (across different compilers) for doing this.

 

[Flash Gordon]

I just read through those two articles. They are short on details,
make a lot of assumptions about -how- one programs in C; and the
conclusions are a bit of hand-waving not justified by the work that
has gone before.

In particular, I would say that the "Locality of Reference" conclusion
is based upon implementation factors rather than on language design,
and that the reasoning of that section appears faulty to me.

In addition, the articles are either a long way out of data (over 15
years) or the author does not really know C as it has been since it was
standardised. I say this because it is including malloc.h instead of the
standard header stdlib.h. Whichever is the case, it casts even further
doubt on whether the author is qualified to compare the languages.

 

[James S. Singleton]

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is more
easy to code than C... When i searched in our encyclopedia (i.e Google), i
came up with several answers, telling "C is much faster than C++ and most
kernal prgms uses only C" ... But why is it so...? Why they use C for
these OS based programs.. Please Help me with detailed explanation...

Another reason that no one has pointed out yet: Because object orient
design is not the silver bullet that many want to believe, and because
object orient design is something that comes naturally to many programmers
(good and bad) but doesn't to just as many (also good and bad).

 

[jacob navia]

James S. Singleton a écrit :

Another reason that no one has pointed out yet: Because object orient
design is not the silver bullet that many want to believe, and because
object orient design is something that comes naturally to many programmers
(good and bad) but doesn't to just as many (also good and bad).

YES!

And I would add another one:

Complexity with more complexity until no one on earth,
(besides Bjarne maybe) is able to understand the whole
language.

Man years of toiling to build incredible fragile compilers
that are incompatible with each other because not one of
them shares the same bug set. Obviously.

I have watched Bjarne and his followers start with the idea of a
"better C" and get swallowed alive by the dragons of complexity.

Automatic destructors can be replaced easily with a
garbage collector, what simplifies the whole thing
quite a bit without adding more complexity and new
features to the language itself.

Templates are one approach to genericity but that can be
better handled with metaprogramming, i.e. compile
time functions.

jacob

 

[Keith Thompson]

The are only 3 reasons to use C over C++:
- you have no decent C++ compiler for your platform
- you have to continue a C project
- you are not allowed to use C++ because your boss still believes that
C++ is SLOW

- you happen to know C better than C++;
- you happen to *like* C better than C++;
....

 

[Keith Thompson]

Automatic destructors can be replaced easily with a
garbage collector, what simplifies the whole thing
quite a bit without adding more complexity and new
features to the language itself.

As I understand it, garbage collection only reclaims allocated memory;
destructors can perform any arbitrary cleanup actions (closing files,
for example).

 

[jacob navia]

Keith Thompson a écrit :

As I understand it, garbage collection only reclaims allocated memory;
destructors can perform any arbitrary cleanup actions (closing files,
for example).

True, you have to invoke the cleanup yourself.
This may be a lot of work, or not relevant, depending on your
application.

Using exception handling, it is easy to do automatic cleanups
using the __finally clause. The exception handling provided by
lcc-win32 is just the compiler side of the native one
provided by the Win32 system.

jacob-

 

[Keith Thompson]

Keith Thompson a écrit :

True, you have to invoke the cleanup yourself.
This may be a lot of work, or not relevant, depending on your
application.

Using exception handling, it is easy to do automatic cleanups
using the __finally clause. The exception handling provided by
lcc-win32 is just the compiler side of the native one
provided by the Win32 system.

Which, again, is just find and dandy if you happen to be using a Win32
system.

 

[Ulrich Eckhardt]

All the kernel level programs are written in C...

There are some kernels out there not written in C, OS X, CE and some
microkernels come to mind.

(i.e: Open Source LINUX)... Why are they not using C++...

At the time Linux was started, there was neither a standardised C++
language nor were there really usable compilers. Much has changed, above
mentioned kernels are newer and their developers evaluated the situation
differently.

However, there is also a technical reason why many low-level programs are
written in C and that is the availability of a compiler. There are many
processors (in particular microcontrollers) which simply don't have a C++
compiler, because the overhead of writing one is just too large (C++ is
very complex). C on the other hand translates almost immediately to
assembler, which is also why it's sometimes called high level assembly.

Another reason is that much FUD is spread about C++. Just to name a few
examples already mentioned in this thread:
- The implicit assumption that C++ means OOP.
- C++ functions always pass a hidden this pointer.
- C++ exception handling is unsuitable for the kernel.
- C is much faster than C++.
- We tried it in `92 and it sucked, so it sucks now, too.

Another thing, which is but a theory of mine, is that C does less error
checking. In particular when you access registers by their address
directly, C does the conversion to a pointer implicitly, C++ needs to be
forced with a cast. That and that it's 'high level assembly' give you a
very good control on what is happening and that of course helps when
you're fiddling with the hardware directly.

Lastly, the availability to code in C++ is much less spread than to code in
C, which is probably a tribute to the added complexity. For a kernel,
you'd then need to be an expert in three things, kernel-programming, C++
and sometimes the hardware you are working on - would be hard to find
coders.

Uli

 

[Ian]

Hi, Please help me in this regard...
All the kernel level programs are written in C... (i.e: Open Source
LINUX)... Why are they not using C++... I personally feel that C++ is
more easy to code than C... When i searched in our encyclopedia (i.e
Google), i came up with several answers, telling "C is much faster than
C++ and most kernal prgms uses only C" ... But why is it so...? Why
they use C for these OS based programs.. Please Help me with detailed
explanation...

Others have covered most of the reasons and in doing so have avoided
most of the old misconceptions regarding C++ performance.

One thing that has been overlooked is the embedded C++ subset of the
language which lends its self nicely to kernel and driver programming.
Many embedded systems use this and these are pretty close to kernel
development in their scope.

I have used C++ for kernel level drivers, partly to prove it can be
done, but mainly to take advantage of the resource management provided
by object constructors and destructors. I was also able to reduce the
code base size of a driver family with templates.

In short, C++ is no worse than C for kernel/driver code and in instances
where OO is a natural fit, offers a number of advantages.

Ian

 

[Keith Thompson]

Another thing, which is but a theory of mine, is that C does less error
checking. In particular when you access registers by their address
directly, C does the conversion to a pointer implicitly, C++ needs to be
forced with a cast. That and that it's 'high level assembly' give you a
very good control on what is happening and that of course helps when
you're fiddling with the hardware directly.

If you're referring to accessing something at a specific numeric
address, C requires a cast as well. There are no implicit conversions
between integers and pointers, other than the special case of a null
pointer constant.

For example, this:
int *ptr = 0xdeadbeef;
is a constraint violation, but this:
int *ptr = (int*)0xdeadbeef;
is legal. (As far as I know, this is the same in C and C++.)

 

[Ian]

Another thing, which is but a theory of mine, is that C does less error
checking. In particular when you access registers by their address
directly, C does the conversion to a pointer implicitly, C++ needs to be
forced with a cast. That and that it's 'high level assembly' give you a
very good control on what is happening and that of course helps when
you're fiddling with the hardware directly.

I guess the counter argument to that is C++ makes it very obvious that
you are doing something 'unusual'

The ability to use 'placement new' on a pointer (say a register set) is
one of the C++ features I really like for driver work.

Lastly, the availability to code in C++ is much less spread than to code in
C, which is probably a tribute to the added complexity. For a kernel,
you'd then need to be an expert in three things, kernel-programming, C++
and sometimes the hardware you are working on - would be hard to find
coders.

Indeed, same applies to embedded C++ developments. I found it easy to
find C++ developers or embedded developers but the intersection between
the two sets was pitifully small.

Ian