Why We Use C Than C++...

[pemo]

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...

C - You shoot yourself in the foot.
C++ - You accidentally create a dozen instances of yourself and shoot them
all in the foot. Providing emergency medical assistance is impossible since
you can't tell which are bitwise copies and which are just pointing at
others and saying, "That's me, over there."

The old ones are the best.

 

[Malcolm]

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...

If you try to use C++ but not use object-oriented design, you invariable end
up with a horrible kludge with some objects and some procedures merrily
intertwined, and quite impossible to document.

So why use structured programming rather than object-orientation? Basically
because it tends to be easier to implement, and to test, and to document.
Object-orientation really comes into its own when you want your program to
be expended in ways you haven't forseen by a third-party programmer. That's
not extremely uncommon, but not the normal situation either.

C++ also tends to encourage computationally inefficient gift-warpping of
interfaces. However this isn't normally a big problem.

C++ also has problems with the language stability, and with syntax stretched
to breaking point. For some reason OO language designers seem to think that
object variables should be in the same namespace as locals, that methods
should be called with a clumsy function-like syntax, that symbols should be
resolved in long sub-expressions, that blocks should be deeply nested, and
so forth.

 

[Mark McIntyre]

Nope.

Actually, yep, sometimes.

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

Thats the objective of all languages " I think Walter's point was that
C++ apps generally make use of the C++ standard library, and thats a
lot larger than the C standard library.

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

This is wrong. Its possible for C to be much faster than C++ (and vice
versa) when doing the same thing. Whats important is how *well* you do
it.

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

And
- you apply occam's razor and use the simplest tool for the job

Why use a truck, when a mini will do?
Mark McIntyre

 

[Ian]

If you try to use C++ but not use object-oriented design, you invariable end
up with a horrible kludge with some objects and some procedures merrily
intertwined, and quite impossible to document.

Sorry had to bite...

With respect, this depends on you skills and team practices. It's
perfectly OK or mix objects and functions, if anything this is better
then forcing OO where it doesn't fit.

If a part of a design maps cleanly to an object, then use one. The same
applies equally well to C or C++, it's just a matter of how you
manipulate the object, passing a struct to a function, or adding the
function to the struct (which gets passed the struct under the hood anyhow).

So why use structured programming rather than object-orientation? Basically
because it tends to be easier to implement, and to test, and to document.

Again, that depends on the domain and the developers.

Object-orientation really comes into its own when you want your program to
be expended in ways you haven't forseen by a third-party programmer. That's
not extremely uncommon, but not the normal situation either.

No necessarily, there can many instances in a kernel where there are
similar objects that can map cleanly to an inheritance model.

C++ also tends to encourage computationally inefficient gift-warpping of
interfaces. However this isn't normally a big problem.

This is a non issue as light weight wrappers will be inlined away by the
compiler. C++ compilers tend to be very effective at doing this.

C++ also has problems with the language stability, and with syntax stretched
to breaking point. For some reason OO language designers seem to think that
object variables should be in the same namespace as locals, that methods
should be called with a clumsy function-like syntax, that symbols should be
resolved in long sub-expressions, that blocks should be deeply nested, and
so forth.

? the C++ standard was published in 1998.

Ian

 

[Ian]

Actually, yep, sometimes.

The core language doesn't require run time support, but may features
(exception, RTTI etc.) do. The key is to avoid using those features!

Thats the objective of all languages " I think Walter's point was that
C++ apps generally make use of the C++ standard library, and thats a
lot larger than the C standard library.

Well yes, it is a superset of the C standard library and may contain
code that requires run time support. That's one reason it is excluded
from Embedded C++ and tends to be a no-no in kernel space.

And
- you apply occam's razor and use the simplest tool for the job

Which might be C++, or it might be C.

Ian

 

[Stan Milam]

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.

Very interesting. However, your analysis is how C would have to be
written to do all the things C++ does to implement OOP. Not a good
comparision. If you are primarily using C you really will not care a
whit about tying to do things the C++ way.

Regards,
Stan Milam.

 

[Chris Torek]

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

Unfortunately, C++'s exception handling (try/catch/throw) is
"fundamentally hard". Compiler-writers must throw either space
(code and/or data) or time (runtime function entry/exit and/or
slower "throw"s) at the problem (and typically they choose a mix
of both). Gnu G++ chooses mainly the "space" option (those
".eh_frame" things), with slower "throw"s.

It *is* possible to use a "C++ without exceptions" compiler
(some embedded systems do this) to avoid the cost entirely, but
then you no longer have C++.

 

[Zara]

James S. Singleton a écrit :

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

Just a minor footnote:

I would never write a kernel with dependencies on a garbage collector.
Or, if I am froced to do it, I would write in an assembler/C/C++
mixing a Java Virtual machine and then I would write the kernel
dependent on agrabage collector, a Just-in-time compiler and forcing
all application programs to be written in Java.

Or I would resort to a mixing oc assembler/C/C++ to do everything. As
I really do (that is my job). Besides, I turn off exceptions (C++
allows) and RTTI more programming effort!) but I do use templates and
inheritance. And extern "C" for the C/assemebler interface.

Best regards,

Zara

 

[Shark]

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.

I think what you say about automatic cleanup is true if the destructor
itself doesn't throw an exception! Lets say your program throws an
exception and you now embark on a destruction journey, destoying
everything that comes in your path. Awesome, but what if one of these
things you are destroying calls an exception? Will you proceed with the
destruction of subsequent objects? Dragons of complexity!!!!

 

[Shark]

You'll like this then:
http://channel9.msdn.com/ShowPost.aspx?PostID=68302

 

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

The C++ Standard Library is many times as big as the C Standard Library,

A kernel is not a hosted environment, so the standard library is
irrelevant. What *is* relevant is the infrastructure required to
implement the new and delete operators in their various forms,
exceptions, constructors and destructors, etc.

(interesting problem: if your kernel contains static objects, at which
point do you call their constructors? what about their destructors?)

DES

 

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

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.

in which case there is no point in chosing C++ over C.

DES

 

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

When doing kernels, you'll likely be interfacing with lots of low-level
ASM functions to handle hardware interrupts and what not;

Define "lots". The i386 version of the FreeBSD kernel, for instance,
contains somewhat less than 4,000 lines of assembly for nearly
2,000,000 lines of C (including copyright notices and comments in both
cases).

DES

 

[henryk.mueller]

in which case there is no point in chosing C++ over C.

Well, the point is that you can do a lot more with C++ - if you want!

I think kernel programming and embedded programming have a lot in
common. If you come from, let's say PC application programming where
speed and size of your code do not matter because your system has
plenty of it, then you first need to learn to write lean C++ code - and
to avoid some C++ features:
- virtual functions
- exceptions
- rtti
- templates (if your compiler is not able to)
- a.s.o.

Still, there are a lot of C++ features left that are worth using them
in embedded environments. If you understand, what happens "behind the
scenes" of your code, then C++ is very powerful even in embedded
systems.

I personally really like the beauty and robustness of a lean interface
wrapper class that looks very sophisticated from the outside but
actually contains only a lot of inline stuff that gets and sets some
port registers...

For my part, I think that plain C just looks ugly and is so damn old
school... ;o)

 

[Zara]

You'll like this then:
http://channel9.msdn.com/ShowPost.aspx?PostID=68302

Really interesting. Thank's for the link!

Best regards,

Zara

 

[Richard Heathfield]

(e-mail address removed) said:

Well, the point is that you can do a lot more with C++ - if you want!

No, the two languages have equivalent computational power. This is perhaps
more obvious when you realise that you can write a C++ compiler in C or a C
compiler in C++. So anything you can compute in one language can clearly be
computed in the other, too.

I personally really like the beauty and robustness of a lean interface
wrapper class that looks very sophisticated from the outside but
actually contains only a lot of inline stuff that gets and sets some
port registers...

That's precisely the wrong use for C++. A good C++ class (or C module)
should be like a duck - calm and smooth on the surface, and paddling
furiously underneath. Clean interfaces are much to be preferred to
"sophisticated" interfaces. "Sophisticated" is just another word for "hard
to use and therefore bug-prone".

For my part, I think that plain C just looks ugly and is so damn old
school... ;o)

Aesthetic appreciation is notoriously non-portable.

 

[henryk.mueller]

Sorry, I used the wrong word *sophisticated*. A better word is
*elegant*.

And you are right. You can do the same thing in C as in C++. But it's
not build in! You have to code it first - like virtual functions,
inheritance, overloading and stuff...

Ok, and then write me a working equivalent to the C++ template
mechanism... ;o)

 

[August Karlstrom]

A good C++ class (or C module)
should be like a duck - calm and smooth on the surface, and paddling
furiously underneath. Clean interfaces are much to be preferred to
"sophisticated" interfaces. "Sophisticated" is just another word for "hard
to use and therefore bug-prone".

Love the duck metaphor, LOL.

Aesthetic appreciation is notoriously non-portable.

Not in a high level implementation using multi platform libraries.


August

 

[Richard Heathfield]

(e-mail address removed) said:

Sorry, I used the wrong word *sophisticated*. A better word is
*elegant*.

Fair enough.

And you are right. You can do the same thing in C as in C++. But it's
not build in! You have to code it first - like virtual functions,
inheritance, overloading and stuff...

Why would you want any of *that*? If I wanted that stuff, I'd be using C++!

Ok, and then write me a working equivalent to the C++ template
mechanism... ;o)

Why bother?

 

[Imre Palik]

Why bother?

To spare a few hundred lines of code?

Ok, I used macros with type arguments to this end before. But I
tended to be yelled at on code reviews for this. I still have no idea
why ...

ImRe