Why We Use C Than C++...

[Walter Bright]

2) dwarf2 based tables, where the compiler describes in detail each
stack frame so that the runtime is able to figure out where it should
jump. This method is fast when not throwing exceptions since there
is no overhead, but it costs a LOT in RAM space since those tables
must be generated for each function, and that is surely not cheap in
space requirements. The tables need to be there even for functions that
do not use exceptions at all.

On a typical virtual memory system, executables are not loaded into memory,
they are memory-mapped into the virtual address space. Only when a specific
address is accessed does that particular page get swapped into real memory
(called demand paged virtual memory). Thus, although the exception handling
tables can consume significant address space, they don't consume RAM unless
exceptions are actually happening.

To enhance this effect, the exception handling tables are typically grouped
together and separate from ordinary static data.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Malcolm]

There are many cases where C++ is a good choice for procedural code, the
ability to manage the lifetime of dynamic memory and locks is the one I
have found most useful in kernel space.

It might be the least bad choice, if you can impose discipline on your
developers, and you need some feature not provided by C.

 

[Ed Jensen]

For example, C++ allows you to do this:

int *i = new int[100];

There is no reason the performance of this should be any worse than
the C equivalent:

int *i = (int *) malloc (100 * sizeof (int));

But, which one is easier to write?

Wouldn't most experienced C developers write this instead?

int *i = malloc(100 * sizeof *i);

Casting the return value of malloc() in C (not C++!) is bad form.

Using "sizeof type" instead of "sizeof *var" is also bad form.

Also, will the compiler catch
the error for you if you accidentally change the second one to this?

double *d = (double *) malloc (100 * sizeof (int));

This potential problem evaporates if you use the proper form.

 

[Ian Collins]

It might be the least bad choice, if you can impose discipline on your
developers, and you need some feature not provided by C.

The compiler can impose discipline though options. The environment will
back this up by simply not loading the application if the rules are not
followed (lack of C++ run time in kernel space).

 

[sonugeetha]

After discussing a lot, i gathered some important points given by our
friends... Below are some points, why we use C rather than C++...

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

From http://ibis.nott.ac.uk/guidelines/ch4/chap4-4.1.html

High-level authoring systems allow developers to implement
sophisticated software products quickly. Such systems have many
advantages, therefore, in projects where there is a premium on
productivity. However, these advantages are won at some cost: high
level programs operate less directly on the hardware they control than
low level programs.


The best high level authoring tools can, of course, be extended at low
level to serve particular needs (eg with the aid of compiled languages
like C). It is important, therefore, when setting up a project team, to
consider the merits of adding low level programming skills to the team
even though much of the development will be at a higher level. The
presence of in house skills of this kind can be extremely
cost-effective.

Low-level languages are closer to the hardware than are high-level
programming languages, which are closer to human languages.

From http://www.cplusplus.com/doc/information/description.html

When choosing a programming language to make a project, many different
considerations can be taken. First, one must decide what is known as
the level of the programming language. The level determines how near to
the hardware the programming language is. In the lower level languages,
instructions are written thinking directly on interfacing with
hardware, while in "high level" ones a more abstract or conceptual code
is written.

Generally, high level code is more portable, that means it can work in
more different machines with a smaller number of modifications, whereas
a low level language is limited by the peculiarides of the hardware
which it was written for. Nevertheless, the advantage of low level code
is that it is usually faster due to the fact that it is indeed written
taking advantage of the possibilities of a specific machine.

A higher or lower level of programming is to be chosen for a specific
project depending on the type of program that is being developed. For
example, when a hardware driver is developed for an operating system
obviously a very low level is used for programming. While when big
applications are developed usually a higher level is chosen, or a
combination of critic parts written in low level languages and others
in higher ones.

(So from the above statement its clear that Object Oriented Programming
is generally used for application type of projects)

When i searched for why the systems like Unix, Linux, Windows have been
written in C, i came up with an answer that its just because C was
considered as a 'portable assembler', allowing to drive the hardware on
one hand, and to provide a sufficient level of abstraction to build
portable interfaces (API).


Some minor reasons for using C from
http://www.linuxdevices.com/eljonline/issue07/4870s1.html

*

C++'s virtues are expensive. Advanced OOP features, such as
templates and the practice of using classes in the place of primitives,
to name two examples, cause unacceptable code bloat.

*

A C++ compiler may generate many routines for one function
(templates) or create routines where no function explicitly appeared
(constructors, casts, etc.). There is generally a one-to-one
relationship between a function in C code and the resulting
machine-code routine. It's easier to optimize what you can see than
what you must infer.

*

Virtual methods and polymorphism complicate runtime linking and
require many relocations. This slows C++ application launch time
considerably. C applications are both simple to link and amenable to
lazy linking, so they load quickly. (For details, see Waldo Bastian's
paper ``Making C++ Ready for the Desktop",
http://www.suse.de/~bastian/Export/linking.txt.)

*

Each class with virtual methods has an associated vtable array,
which adds memory overhead.

*

C++'s tighter type-checking makes it difficult to write the
space-conscious code reuse common to C applications (think: void *).

*

The small, simple code demanded of embedded projects provides
maintainability. There is no reason to assume OOP will further simplify
such systems.

*

GUIs may not have a simple solution in a rigorous OOP model.

*

It's easy to get carried away and start doing OOP for OOP's sake.
The One True Object Model may describe a problem perfectly, but it
comes at the cost of excessive code.

Carefully written C code can be much faster than C++ code,
especially on embedded hardware. GTK+'s hand-crafted object system
offers much better spatial locality than C++'s more numerous and
distributed constructors. Our device has a tiny cache, so locality is
an especially important performance consideration.

From the above said points, I feel that 'C' Code is more close to

kernel and harware programs where memory management, speed are
considered and where as 'C++' Code is for easy use for programmers in
developing Application level programming...

 

[Ian Collins]

After discussing a lot, i gathered some important points given by our
friends... Below are some points, why we use C rather than C++...

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

Some minor reasons for using C from
http://www.linuxdevices.com/eljonline/issue07/4870s1.html

*

C++'s virtues are expensive. Advanced OOP features, such as
templates and the practice of using classes in the place of primitives,
to name two examples, cause unacceptable code bloat.

To use a colloquialism popular in these parts, bollocks. Sorry about
using such a term, but the above is pure FUD.

*

A C++ compiler may generate many routines for one function
(templates) or create routines where no function explicitly appeared
(constructors, casts, etc.). There is generally a one-to-one
relationship between a function in C code and the resulting
machine-code routine. It's easier to optimize what you can see than
what you must infer.

Again, FUD. OK, maybe not so with inexperienced C++ programmers, but
when you know what you are doing, this isn't an issue.

*

Virtual methods and polymorphism complicate runtime linking and
require many relocations. This slows C++ application launch time
considerably. C applications are both simple to link and amenable to
lazy linking, so they load quickly. (For details, see Waldo Bastian's
paper ``Making C++ Ready for the Desktop",
http://www.suse.de/~bastian/Export/linking.txt.)

Not an issue in kernel space, where everything tends to use static linking.

*

Each class with virtual methods has an associated vtable array,
which adds memory overhead.

* True, cost/benefit trade off.

C++'s tighter type-checking makes it difficult to write the
space-conscious code reuse common to C applications (think: void *).

*

That's why its there! (think: bugs).

The small, simple code demanded of embedded projects provides
maintainability. There is no reason to assume OOP will further simplify
such systems.

* C++ doesn't mandate OOP.

GUIs may not have a simple solution in a rigorous OOP model.

* Kernels don't have GIUs.

It's easy to get carried away and start doing OOP for OOP's sake.
The One True Object Model may describe a problem perfectly, but it
comes at the cost of excessive code.

That's a bold assumption, any facts to back it up?

Carefully written C code can be much faster than C++ code,
especially on embedded hardware.

Nope, FUD.

GTK+'s hand-crafted object system

offers much better spatial locality than C++'s more numerous and
distributed constructors. Our device has a tiny cache, so locality is
an especially important performance consideration.

Again, Kernels don't have GIUs.

kernel and harware programs where memory management, speed are
considered and where as 'C++' Code is for easy use for programmers in
developing Application level programming...

I'd have to disagree there, with this first assumption anyway. Both
languages are fine for kernel and hardware programs, I know I've used both.

The bigger issue is your developer skills base. An experienced team of
C developers will produce a much better result than an inexperienced
team of C++ developers. C++ kernel/embedded developers are a rare
commodity.

 

[sonugeetha]

I'd have to disagree there, with this first assumption anyway. Both
languages are fine for kernel and hardware programs, I know I've used both.

yes collins, i accept with you as you say you have used both... but
what i told above is what i felt.. Maybe because that i'm familiar more
in C than C++...

The bigger issue is your developer skills base. An experienced team of
C developers will produce a much better result than an inexperienced
team of C++ developers. C++ kernel/embedded developers are a rare
commodity.

yes collins... i accept with you... Everything depends on the way we
implement and how well we know...

 

[Default User]

Ed Jensen wrote:

Wouldn't most experienced C developers write this instead?

int *i = malloc(100 * sizeof *i);

I would say no to that. Certainly most of the experienced C developers
that read this newsgroup would, but I've never seen it used by an
outsider.



Brian

 

[Ulrich Eckhardt]

When choosing a programming language to make a project, many different
considerations can be taken. First, one must decide what is known as
the level of the programming language. The level determines how near to
the hardware the programming language is. In the lower level languages,
instructions are written thinking directly on interfacing with
hardware, while in "high level" ones a more abstract or conceptual code
is written.

Generally, high level code is more portable, that means it can work in
more different machines with a smaller number of modifications, whereas
a low level language is limited by the peculiarides of the hardware
which it was written for. Nevertheless, the advantage of low level code
is that it is usually faster due to the fact that it is indeed written
taking advantage of the possibilities of a specific machine.

A higher or lower level of programming is to be chosen for a specific
project depending on the type of program that is being developed. For
example, when a hardware driver is developed for an operating system
obviously a very low level is used for programming. While when big
applications are developed usually a higher level is chosen, or a
combination of critic parts written in low level languages and others
in higher ones.

(So from the above statement its clear that Object Oriented Programming
is generally used for application type of projects)

No it is not clear, this text only talks about levels of abstraction.

There are reasons for using OOP/OBP. One reason is that the problem when
displayed/presented as interacting objects is easier to understand. Think
about it: how many drivers in fact provide a common interface? This is a
typical example of in-kernel OOP. Other examples are the memory subsystem:
it could be abstracted as a single object that initially owns all
available RAM and then gives it away in an orderly way. Mostly, this is a
case of encapsulation (which is just one facet of OOP) and something which
can also be achieved with good modules written in C. Lastly, there are
dozens of kernel-level object types inside e.g. Linux. Every time you see
a struct and a bunch of associated functions this is in fact an object. If
the struct is only available as declaration, it also has encapsulation. If
it has some function pointers or a pointer to some other struct holding
them it is an implementation of an interface, i.e. derivation and thus
OOP. If it contains a void pointer named 'private' or 'user' or such it is
to extend the data of the struct with data the particular derived
implementation needs.

Please also note that C++ is not synonymous with OOP. C++ supports OOP
(yes, to an extent that disappoints OOP purists) but doesn't mandate it.

Some minor reasons for using C from
http://www.linuxdevices.com/eljonline/issue07/4870s1.html [...]
C++'s virtues are expensive. Advanced OOP features, such as
templates and the practice of using classes in the place of primitives,
to name two examples, cause unacceptable code bloat.

hmmm, templates are not generally an OOP feature. Wrapping primitives can
be just as efficient as using them directly - you just need to inline
relevant accessors. Other than that, an inappropriate design will alway
suck in this or that way and you have a choice to use those features, a
fact the author of above text blissfully ignores.

Virtual methods and polymorphism complicate runtime linking and
require many relocations. This slows C++ application launch time
considerably. C applications are both simple to link and amenable to
lazy linking, so they load quickly. (For details, see Waldo Bastian's
paper ``Making C++ Ready for the Desktop",
http://www.suse.de/~bastian/Export/linking.txt.)

Not only that this doesn't apply to in-kernel programming (as already
pointed out), it has also ceased to be true! It was just a matter of
patching the linker to cope with whole arrays at once, as they happen with
vtables of polymorphic C++ classes, IIRC it was called the 'combreloc'
patch.

cheers

Uli
(who is surprised by the low amount of flames in this thread)

 

[EventHelix.com]

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.

The intent of the articles is to show C equivalent of the processing
performed
by a C++ compiler. This gives you a good feel of the overhead in using
C++.
This information would be useful to someone evaluating the performance
characteristics of C++.