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/RealtimeMa...erformance.htm
http://www.eventhelix.com/RealtimeMa...rformance2.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.

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
System Design with Sequence Diagrams in PDF and Word EMF

[Richard Heathfield]

so********@gmail.com 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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Dag-Erling Smørgrav]

Richard Heathfield <in*****@invalid.invalid> writes:

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
--
Dag-Erling Smørgrav - de*@des.no

[Walter Roberson]

In article <11**********************@f14g2000cwb.googlegroups .com>,
EventHelix.com <ev********@gmail.com> wrote:

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/RealtimeMa...erformance.htm
http://www.eventhelix.com/RealtimeMa...rformance2.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.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

[Walter Roberson]

In article <86************@xps.des.no>,
=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= <de*@des.no> wrote:

Richard Heathfield <in*****@invalid.invalid> writes:

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.

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.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Walter Roberson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
so********@gmail.com <so********@gmail.com> wrote:

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).
--
Programming is what happens while you're busy making other plans.

[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]

so********@gmail.com wrote:

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]

Walter Roberson wrote:

In article <11**********************@f14g2000cwb.googlegroups .com>,
EventHelix.com <ev********@gmail.com> wrote:

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/RealtimeMa...erformance.htm
http://www.eventhelix.com/RealtimeMa...rformance2.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.

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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[James S. Singleton]

On Thu, 12 Jan 2006 03:14:04 -0800, so********@gmail.com wrote:

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]

he************@gmx.de writes:
[...]

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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

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]

jacob navia <ja***@jacob.remcomp.fr> writes:

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ulrich Eckhardt]

so********@gmail.com wrote:

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]

so********@gmail.com wrote:

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]

Ulrich Eckhardt <do******@knuut.de> writes:
[...]

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ian]

Ulrich Eckhardt wrote:

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

[pemo]

<so********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

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]

<so********@gmail.com> wrote

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]

On 12 Jan 2006 09:19:52 -0800, in comp.lang.c , he************@gmx.de
wrote:

Another important factor is that C++ requires more run-time support
code to work properly.
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
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Ian]

Malcolm wrote:

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]

Mark McIntyre wrote:

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

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!

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.

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]

EventHelix.com wrote:

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/RealtimeMa...erformance.htm
http://www.eventhelix.com/RealtimeMa...rformance2.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.

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
System Design with Sequence Diagrams in PDF and Word EMF

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]

In article <11**********************@g49g2000cwa.googlegroups .com>
<he************@gmx.de> wrote:

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++.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Zara]

On Thu, 12 Jan 2006 20:19:17 +0100, jacob navia
<ja***@jacob.remcomp.fr> wrote:

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

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]

jacob navia wrote:

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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

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


jacob-

[Shark]

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

[Dag-Erling Smørgrav]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

Dag-Erling Smørgrav <de*@des.no> writes:

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,

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
--
Dag-Erling Smørgrav - de*@des.no

[Dag-Erling Smørgrav]

he************@gmx.de writes:

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
--
Dag-Erling Smørgrav - de*@des.no

[Dag-Erling Smørgrav]

"Andrew Poelstra" <jo*********@gmail.com> writes:

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
--
Dag-Erling Smørgrav - de*@des.no

[henryk.mueller]

Dag-Erling Smørgrav schrieb:

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.

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]

On 13 Jan 2006 00:39:10 -0800, "Shark" <cp*******@yahoo.com> wrote:

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]

he************@gmx.de said:

Dag-Erling Smørgrav schrieb:

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

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.

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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]

Richard Heathfield wrote:

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

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Richard Heathfield]

he************@gmx.de 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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Imre Palik]

Richard Heathfield <in*****@invalid.invalid> writes:

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

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

[Ulrich Eckhardt]

Shark wrote:

I think what you say about automatic cleanup is true if the destructor
itself doesn't throw an exception!

A destructor must not throw an exception, that's a rule of C++. If, inside
a dtor, you need to perform an action that might throw, you need to take
precautions that the exception doesn't propagate outside the dtor.

Uli

[Ulrich Eckhardt]

Dag-Erling Smørgrav wrote:

he************@gmx.de writes:

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.

Yes there is, you get C++ namespaces! Seriously, I wonder a) why nobody
has mentioned this point yet and b) why it's not part of C yet, I miss
them really much, and the prefix/suffix thing which is used in C is so
inelegant.

Uli

[Shark]

Ulrich Eckhardt wrote:

Shark wrote:

I think what you say about automatic cleanup is true if the destructor
itself doesn't throw an exception!
A destructor must not throw an exception, that's a rule of C++. If, inside
a dtor, you need to perform an action that might throw, you need to take
precautions that the exception doesn't propagate outside the dtor.

Well, I meant to say if an exception occurs when you are inside a
destructor and are trying to do some cleanup.......
Uli

[Ico]

Ulrich Eckhardt <do******@knuut.de> wrote:

Yes there is, you get C++ namespaces! Seriously, I wonder a) why nobody
has mentioned this point yet and b) why it's not part of C yet, I miss
them really much, and the prefix/suffix thing which is used in C is so
inelegant.

It's not my intention to start or take part in a holy war about C vs
C++, but I am seriously interested : what exactly do you mean with the
'prefix/suffix thing' ?

--
:wq
^X^Cy^K^X^C^C^C^C

[Keith Thompson]

Ico <us****@zevv.nl> writes:

Ulrich Eckhardt <do******@knuut.de> wrote:

Yes there is, you get C++ namespaces! Seriously, I wonder a) why nobody
has mentioned this point yet and b) why it's not part of C yet, I miss
them really much, and the prefix/suffix thing which is used in C is so
inelegant.

It's not my intention to start or take part in a holy war about C vs
C++, but I am seriously interested : what exactly do you mean with the
'prefix/suffix thing' ?

Global symbols in libraries have to be unique for a given program.
If two libraries use the same identifier, a program can't use both
libraries (unless you can modify one or the other or use some
implementation-specific ugliness).

The usual solution is to apply a unique prefix to all exported
identifiers. For example, an "xyz" library providing a "create"
function might call it "xyz_create()", avoiding a potential conflict
with "pdq_create()" from the "pdq" library.

This is a fairly ugly solution, and not all library authors follow it.

<OT>
C++'s namespace facility provides a cleaner way around this. For
example, an "xyz" library might put all its symbols in the "xyz"
namespace, giving symbol names like "xyz::create()". The difference
is that it's a feature built into the language, making it easier to
use and harder to avoid, and you can refer to the function as just
"create()" if you want to. (I don't use C++, so I could be missing
something.)
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ico]

Keith Thompson <ks***@mib.org> wrote:

Ico <us****@zevv.nl> writes:

It's not my intention to start or take part in a holy war about C vs
C++, but I am seriously interested : what exactly do you mean with the
'prefix/suffix thing' ?
Global symbols in libraries have to be unique for a given program.
If two libraries use the same identifier, a program can't use both
libraries (unless you can modify one or the other or use some
implementation-specific ugliness).

The usual solution is to apply a unique prefix to all exported
identifiers. For example, an "xyz" library providing a "create"
function might call it "xyz_create()", avoiding a potential conflict
with "pdq_create()" from the "pdq" library.

This is a fairly ugly solution, and not all library authors follow it.

Ah, I know the problem ( both as victim, and -I have to admit- as
perpetrator. Learning the hard way :) ), I was not aware he was
referring to this.
<OT>
C++'s namespace facility provides a cleaner way around this. For
example, an "xyz" library might put all its symbols in the "xyz"
namespace, giving symbol names like "xyz::create()". The difference
is that it's a feature built into the language, making it easier to
use and harder to avoid, and you can refer to the function as just
"create()" if you want to. (I don't use C++, so I could be missing
something.)
</OT>

Ok, that sounds as a useful feature.

--
:wq
^X^Cy^K^X^C^C^C^C

[Ian]

Shark wrote:

Ulrich Eckhardt wrote:

Shark wrote:

I think what you say about automatic cleanup is true if the destructor
itself doesn't throw an exception!

A destructor must not throw an exception, that's a rule of C++. If, inside
a dtor, you need to perform an action that might throw, you need to take
precautions that the exception doesn't propagate outside the dtor.

Well, I meant to say if an exception occurs when you are inside a
destructor and are trying to do some cleanup.......

Then you have to handle it inside the destructor, just like any other
error condition, C or C++.

Ian

[Ian]

Ico wrote:

Ulrich Eckhardt <do******@knuut.de> wrote:

Yes there is, you get C++ namespaces! Seriously, I wonder a) why nobody
has mentioned this point yet and b) why it's not part of C yet, I miss
them really much, and the prefix/suffix thing which is used in C is so
inelegant.

It's not my intention to start or take part in a holy war about C vs
C++, but I am seriously interested : what exactly do you mean with the
'prefix/suffix thing' ?

Function or variable names like someModeleDoSomething().

Ian

[Walter Bright]

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

Partly because C is faster (in places).

I'm not aware of any places where, compiling the same source code, it's
faster.

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

[Richard Heathfield]

Walter Bright said:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:dq**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

Partly because C is faster (in places).

I'm not aware of any places where, compiling the same source code, it's
faster.

If you're using the same source code with identical semantics, it's true
that there's no particular reason for one to be faster than the other. But,
if you're using the same source code with identical semantics, why bother
with C++?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)