A recent posting to the lkml requested help in porting the C++ Click Modular Router kernel module from the 2.4 stable kernel to the 2.6 stable kernel. The request was for ideas on fixing C++ related compilation errors, but the thread quickly turned into a lengthy debate on whether or not C++ had a place in the Linux kernel. The issue has been debated many times before, long ago earning its own entry in the lkml FAQ which offers numerous reasons why the kernel is not written in C++.

During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:

"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: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

From: Ashish sddf [email blocked]
To:  linux-kernel
Subject: Compiling C++ kernel module + Makefile
Date: Fri, 16 Jan 2004 13:09:24 -0800 (PST)

Hi, 
   I am trying to port a C++ kernel module from 2.4 to
2.6. (It is MIT Click Modular Router). 

   As I understand the module building has changed in
ver 2.6. I have got the Makefile to compile it but it
gives me lot of warning - all dependancies problem 

 It appears that the kernel Makefile treats it like a
host application and does not pass the necessary
processing routines.


  Does anyone can ideas about how to change the kernel
makefile to compile the C++ files the same way as C
files ? 


Any help will be appreciated. 


Ashish 



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Fri, 16 Jan 2004 17:07:05 -0500 (EST)

If somebody actually got a module, written in C++, to compile and
work on linux-2.4.nn, as you state, it works only by fiat, i.e., was
declared to work. There is no C++ runtime support in the kernel for
C++. Are you sure this is a module and not an application? Many
network processes (daemons) are applications and they don't require
any knowledge of kernel internals except what's provided by the
normal C/C++ include-files.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From: Bart Samwel [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Sat, 17 Jan 2004 13:59:20 +0100

Rest assured, ;) this is definitely a module. It includes a kernel patch that 
makes it possible to include a lot of the kernel headers into C++, stuff like 
changing asm :: to asm : : (note the space, :: is an operator in C++) and 
renaming "struct namespace" to something containing less C++ keywords. The 
module also includes rudimentary C++ runtime support code, so that the C++ 
code will run inside the kernel. I'm afraid that the task of compiling it for 
2.6 is going to be pretty tough -- the kernel needs loads of patches to make 
it work within a C++ extern "C" clause, and it probably completely different 
patches from those needed by 2.4. Getting the build system to work is the 
least of the concerns.

-- Bart



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 08:46:54 -0500 (EST)

I can't imagine why anybody would even attempt to write a kernel
module in C++. Next thing it'll be Visual BASIC, then Java. The
kernel is written in C and assembly. The tools are provided. It
can only be arrogance because this whole C v.s. C++ thing was
hashed-over many times. Somebody apparently wrote something to
"prove" that it can be done. I'd suggest that you spend some
time converting it to C if you need that "module". The conversion
will surely take less time than going through the kernel headers
looking for "::".

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From: Bart Samwel [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 18:40:18 +0100

Just to make this clear: I'm not the original poster, so I'm not the one 
who is to be helped. I just happened to know the module, and I'd thought 
I'd give you a quick answer because I knew it. :)

Now, let me try to add a bit of nuance to your suggested solution. Try 
porting 100s of C++ files (yes, it's that large) making heavy use of 
inheritance etc. to C. Then try to make a bit of C code usable as extern 
"C" in C++. Extern "C" was actually meant to be able to grok most C 
code, while C++ wasn't meant to be easily portable to C. So, for any 
moderately large module that uses any C++ features at all, it's probably 
easier to make small syntactic changes to the kernel than to port the 
module to C (which would amount to a full rewrite).

I'll give you a bit of background about the specific situation. I'm not 
involved with the project, so I don't know all the details, but I do 
know the code and have worked on a "competing" system (as far as 
research systems compete). The choice for C++ for this project is really 
the most obvious choice, as the model is very OO. The module implements 
a router model that is configured as "clickable modules", i.e., very 
small elements with input and output ports and a bit of state that are 
connected to each other through small interfaces. Their element 
implementations are arranged hierarchically (as in C++ class hierarchies).

I'm not familiar with the exact history of the project, but I expect 
that they decided to do C++ because the model they try to express is 
best modeled using C++. This design decision can be debated, because it 
is perfectly feasible (albeit with a lot more work) to implement an OO 
model in C. In fact, I have helped to implement a similar framework (the 
OKE CORRAL) which was written completely in C. But, the fact of the 
matter is, this useful (but huge) kernel module is there now (and it has 
been here since the early 2.2 kernels), and it was not written just to 
"prove" that it could be done, but because C++ seemed at the time to be 
the best language for the job. The start of this project may very well 
predate the many times that this was hashed-over on the LKML 
(disclaimer: I wasn't there, so I don't know). You refer to "what can 
only be" the arrogance of the writers, yet continue by claiming:

 > I'd suggest that you spend some time converting it to C if you need
 > that "module".

and

 > The conversion will surely take less time than going through the
 > kernel headers looking for "::".

Excuse me, but before calling somebody else arrogant, I would suggest 
that you might want check whether you're not calling the kettle black. 
It's not a sign of modesty when you assume without a trace of doubt that 
a module (that happened to have been developed over the course of four 
years by a team of people at MIT) is just a "\"module\"" and that it 
will take less time to port it to C than to make the kernel headers 
parse in a C++ extern "C" clause. In addition, imagine how you would 
feel if somebody referred to your work as a "\"module\""! The fact that 
you "can't imagine why anybody would even attempt to write a kernel 
module in C++" may just as well be due to a lack of imagination on your 
side, but in your statement I detect no trace of a doubt. And _yes_ you 
may very well be right about their initial decision being stupid (and 
you might not be -- I don't know), and _yes_ you are probably right 
about the whole thing being hashed-over many times (I don't know -- I 
wasn't there), and _yes_ there are people out there who would do 
anything just to prove they can do something others think is impossible 
or just filthy. So, yes, there _may_ be a point to what you're saying. 
_May_. I'm not saying you're wrong, and I'm not saying you're right. 
What I'm saying is that simply assuming that any C++ module is nothing 
more than a few lines of (de)glorified C and accusing the writers of 
being arrogant just because they wrote a kernel module in C++ is, in my 
opinion, jumping to conclusions based on 
technical-preference-turned-prejudice (at least, that's how it seems), 
and it's not very polite either.

Unfortunately, this is how flame wars get started (as can be seen by the 
slightly agitated tone this message has taken, sorry about that! :) ). 
Just to make this clear to everyone: I'm not trying to instigate a flame 
war here about C vs. C++, as I don't really have an opinion on that 
subject. This posting has to do with my preferences w.r.t. personal 
style, and nothing with my technical preferences.

-- Bart



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 13:39:43 -0500 (EST)

The possibility that something may have been written by some MIT people
can't change the fact that C++ is not the tool that should have been
used within the kernel. I once worked on a project at Princeton. That
doesn't make me know anything about Relativity. Einstein didn't rub
off due to some proximity effect.

If the "MIT Team", as you so state, had actually inspected some
kernel code, and actually understood what a Linux/Unix kernel does,
then learned persons could not possibly have selected C++ for this
project.

If you review the project, you will probably also find that a
large percentage of the code should have been implemented in
user-mode (a daemon, or several). That's where C++ really shines.

However, it wasn't. Which, to me, means that the developers
were either clue-less or, once somebody actually figured out
how a kernel works, it was way too late to change (an all to common
problem).

The number of persons who worked on a project does not affect the
correctness of the tools nor the architecture chosen. Facts are
not democratic. You can't vote them into or out of existence.

> Unfortunately, this is how flame wars get started (as can be seen by the
> slightly agitated tone this message has taken, sorry about that! :) ).
> Just to make this clear to everyone: I'm not trying to instigate a flame
> war here about C vs. C++, as I don't really have an opinion on that
> subject. This posting has to do with my preferences w.r.t. personal
> style, and nothing with my technical preferences.
>

This is not about preferences. Most software engineers wish that
everything could be done using the first language they learned. Once
they try to write a state-machine in FORTRAN (my native language), they
begin to understand that there are other tools more suited for the
job. Unfortunately, especially for students at well-known universities,
learning a language often opens the door to a cult. I remember
the "Pascal cult", the "forth cult", the "C cult" the "C++ cult", and
now the "C# cult". Next year there may be "D" and the cycle will
continue.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From: Bart Samwel [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 21:02:43 +0100

> The possibility that something may have been written by some MIT people
> can't change the fact that C++ is not the tool that should have been
> used within the kernel. I once worked on a project at Princeton. That
> doesn't make me know anything about Relativity. Einstein didn't rub
> off due to some proximity effect.

No. But the fact that you haven't seen the module means that you can't 
possibly know whether the module is a "\"module\"" or just a "module" -- 
there are probably solid technical reasons to dislike C++ in the kernel, 
but that is no excuse to start calling things "\"module\"" instead of 
just "module". The fact that you're now attacking this minor point (the 
fact that these people happen to be MIT people) means that you missed 
the major point -- you were jumping to conclusions and calling people 
arrogant without checking the specific background, and without reserve. 
I usually think it's wise to *either* not check the background *or* keep 
no reserve, but not both. But that's just me. :)

> If the "MIT Team", as you so state, had actually inspected some
> kernel code, and actually understood what a Linux/Unix kernel does,
> then learned persons could not possibly have selected C++ for this
> project.
> 
> If you review the project, you will probably also find that a
> large percentage of the code should have been implemented in
> user-mode (a daemon, or several). That's where C++ really shines.

For most projects, you might be right. For this project, I think you're 
not. This project implements a new network router design, one that is 
aimed at achieving the best possible routing performance that can be 
achieved while maintaining maximum flexibility. The flexibility is 
achieved by having large amounts of configurable elements available, so 
that practically any routing task can be composed of the available 
elements. To achieve enough speed (and lack of latency) to be really 
viable as a router, they need to be as close to the hardware as 
possible. See it like this: as soon as pkttables can be moved to 
userspace with negligible performance loss, this app will be able to 
move too.

> However, it wasn't. Which, to me, means that the developers
> were either clue-less or, once somebody actually figured out
> how a kernel works, it was way too late to change (an all to common
> problem).

The router code of the project works both in userspace and in 
kernel-space. It just works much slower in userspace. If they were able 
to get the right kind of performance in userspace they probably would. 
AFAIK these guys were also very early in the adoption of polling, 
according to the changelog they built polling support in April 2000. 
This got them a 4-5x speed increase. Not your typical project that you 
can make a daemon -- unless you're working in a microkernel OS, of 
course. Definitely not in Linux 2.2.

> The number of persons who worked on a project does not affect the
> correctness of the tools nor the architecture chosen. Facts are
> not democratic. You can't vote them into or out of existence.

The main point of that phrase was to indicate that more than four 
person-years went into this module. It didn't have anything to do with 
facts regarding correctness nor architecture, only with the fact that 
you stated without much reserve something that led me to believe that 
you had not considered that the size of this module may be larger than 
you imagined.

>>Unfortunately, this is how flame wars get started (as can be seen by the
>>slightly agitated tone this message has taken, sorry about that! :) ).
>>Just to make this clear to everyone: I'm not trying to instigate a flame
>>war here about C vs. C++, as I don't really have an opinion on that
>>subject. This posting has to do with my preferences w.r.t. personal
>>style, and nothing with my technical preferences.
> 
> This is not about preferences. Most software engineers wish that
> everything could be done using the first language they learned. Once
> they try to write a state-machine in FORTRAN (my native language), they
> begin to understand that there are other tools more suited for the
> job. Unfortunately, especially for students at well-known universities,
> learning a language often opens the door to a cult. I remember
> the "Pascal cult", the "forth cult", the "C cult" the "C++ cult", and
> now the "C# cult". Next year there may be "D" and the cycle will
> continue.

Yes, I know how this works. Although I have never programmed in FORTRAN, 
I have at least 15 other languages on my list (covering all of the 
well-known paradigms), not counting scripting languages, and I know that 
there is definitely a thing such as "the right tool for the right job". 
I do not dispute that. What I care about is your response, which seemed 
to indicate that you had already grouped the module authors in the "C++ 
cult" category, without keeping open the possibility that they might not 
be. You had already called them arrogant without checking any 
background. I don't care if they _are_ part of the "C++ cult", as you 
call it, but you had not enough information at this point to derive 
that. It seems that you're so allergic to the idea of mixing C++ with 
the kernel that you're blocking all possibility of discussion 
immediately. Calling somebody "arrogant" before they can even tell you 
why they did what they did is a perfect way to prevent any reasonable 
conversation from happening. It's not productive towards solving the 
problem at hand, and also not towards convincing people of your opinion.

-- Bart



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 15:37:46 -0500 (EST)

On Mon, 19 Jan 2004, Bart Samwel wrote:

> Richard B. Johnson wrote:
> > On Mon, 19 Jan 2004, Bart Samwel wrote:
> [... lots of text ...]
[Snipped...]

I stand by my assertion that anybody who develops kernel
modules in C++, including MIT students, is arrogant.

Let's see if C++ is in use in the kernel. At one time, some
of the tools that came with it were written in C++ (like ksymoops).

Script started on Mon Jan 19 15:19:33 2004
$ cd /usr/src/linux-2.4.24
$ find . -name "*.cpp"
$ exit
exit
Script done on Mon Jan 19 15:20:25 2004

Well, perhaps the kernel developers were ignorant. They didn't
write anything in C++. Maybe they were just too dumb to learn the
language?

Maybe there is another reason:
The kernel development languages, as previously stated, were
defined at the project's inception to be the GNU C 'gcc'
compiler's "C" and extensions,  and the 'as' (AT&T syntax)
assembler. Anybody can search the archives for the discussions
about using C++ in the kernel.

Any person, or group of persons, who is smart enough to
actually write some kernel code in C++, has proved that
they are not ignorant. Therefore, they have demonstrated
their arrogance.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From: Robin Rosenberg [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Tue, 20 Jan 2004 01:59:22 +0100

måndagen den 19 januari 2004 21.37 skrev Richard B. Johnson:
> Let's see if C++ is in use in the kernel. At one time, some
> of the tools that came with it were written in C++ (like ksymoops).
> 
> Script started on Mon Jan 19 15:19:33 2004
> $ cd /usr/src/linux-2.4.24
> $ find . -name "*.cpp"
> $ exit
> exit
> Script done on Mon Jan 19 15:20:25 2004
> 

This is the "We've always used COBOL^H^H^H^H" argument. 

-- robin



From: Linus Torvalds [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)


On Tue, 20 Jan 2004, Robin Rosenberg wrote:
> 
> This is the "We've always used COBOL^H^H^H^H" argument. 

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:

 - the whole C++ exception handling thing is fundamentally broken. It's 
   _especially_ broken for kernels.
 - any compiler or language that likes to hide things like memory
   allocations behind your back just isn't a good choice for a kernel.
 - 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 
 (a) looking for problems
 (b) a C++ bigot that can't see what he is writing is really just C anyway
 (c) was given an assignment in CS class to do so.

Feel free to make up (d).

		Linus


From: Bart Samwel [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:24:39 +0100

Richard B. Johnson wrote:
[...]
> I stand by my assertion that anybody who develops kernel
> modules in C++, including MIT students, is arrogant.
> 
> Let's see if C++ is in use in the kernel. At one time, some
> of the tools that came with it were written in C++ (like ksymoops).
> 
> Script started on Mon Jan 19 15:19:33 2004
> $ cd /usr/src/linux-2.4.24
> $ find . -name "*.cpp"
> $ exit
> exit
> Script done on Mon Jan 19 15:20:25 2004

Just so that you know, the extension .cpp is typically used by Windows 
C++ programmers, on most other environments the usual extensions are .cc 
and .C. If you look for *.cc you find scripts/kconfig/qconf.cc, so the 
kernel toolset is not completely C++-free. Not that all of this matters.

> Well, perhaps the kernel developers were ignorant. They didn't
> write anything in C++. Maybe they were just too dumb to learn the
> language?

It seems you you assume I'm an arrogant Bjarne-hugging C++-lover. Where 
did you get that? It's probably in your mind, where everyone who 
suggests C++ is a Bjarne-hugging C++-lover. I'M NOT IN THE C++ CULT. I'M 
NOT SAYING THAT EVERYONE SHOULD PROGRAM IN C++. Hope this came across, 
you are now officially declared deaf. ;)

> Maybe there is another reason:
> The kernel development languages, as previously stated, were
> defined at the project's inception to be the GNU C 'gcc'
> compiler's "C" and extensions,  and the 'as' (AT&T syntax)
> assembler. Anybody can search the archives for the discussions
> about using C++ in the kernel.

Yeah, definitely. I fully agree that it's not wise to use C++ *in the 
base kernel*. The Linux project needs to maintain overall consistency, 
and one of the means of doing that is using a small, well-defined 
toolset -- in this case, as and gcc. Any large project needs language 
and coding standards.

But we're not talking about the base kernel here. We're not talking 
about migrating the kernel to C++, or even modules that are part of the 
Linux kernel source. We're talking about *independent modules*. The 
kernel exports a module interface, and any binary driver that correctly 
hooks into the interface of the running kernel (using the correct 
calling conventions of the running kernel) and behaves properly (e.g., 
doesn't do stack unwinds over chunks of kernel functions etc.) can hook 
into it and do useful work. If somebody has decided that it would be 
worth it for his project to use C++ (without exceptions, rtti and the 
whole shebang) then so be it, why should you care? It's just binary code 
that hooks into the module interface, using the correct calling 
conventions. It doesn't do dirty stuff -- no exceptions, no RTTI, 
etcetera. It compiles into plain, module-interface conforming assembler, 
that can be compiled with -- you guessed it -- 'as', the AT&T syntax 
assembler. Yes, they're taking a risk. Their risk is that C++ can't 
import the kernel headers, or that C++ might someday need runtime 
support that cannot be ported into the kernel. It's *their risk*, not 
yours. Then why do you have a reason to get religious about this? 
They're not submitting this stuff for inclusion in the Linux source!

> Any person, or group of persons, who is smart enough to
> actually write some kernel code in C++, has proved that
> they are not ignorant. Therefore, they have demonstrated
> their arrogance.

This logic is faulty. It is built upon the premise that (ignorant || 
arrogant). Not listening to warnings of others is not a sign of 
arrogance per se, it is only a sign of the presence of a different 
opinion. It assumes that the kernel developers are always right, and 
that everybody who is smart should listen to them, on penalty of being 
arrogant. Yes, these C++-loving people may be wrong (or they may not 
be), but that does not _automatically_ make them arrogant, they may 
simply have a different opinion -- right or wrong. If they are wrong, 
they are not arrogant, but simply *stupid*. If they are right, they are 
not arrogant either -- they may be arrogant *about it*, but that's just 
a manner of behaviour, and it's up to them if they behave in this way or 
not. Kernel developers do not prescribe what people can do with the 
kernel, this is part of the essence of "free". And as a result of that, 
they do not have the right to declare people arrogant when they do not 
listen. They have the right to *call* them that, but the only result of 
that is that all discussion on matters like these are smothered in 
religious wars. And that's a pity.

-- Bart



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Tue, 20 Jan 2004 10:20:53 -0500 (EST)

On Mon, 19 Jan 2004, Bart Samwel wrote:

> not. Kernel developers do not prescribe what people can do with the
> kernel, this is part of the essence of "free". And as a result of that,
> they do not have the right to declare people arrogant when they do not
> listen. They have the right to *call* them that, but the only result of
> that is that all discussion on matters like these are smothered in
> religious wars. And that's a pity.

It's not, as you say, a religious war.

Whether or not one can use the back-end of a
hatchet as a hammer does not qualify the hatchet
as a hammer.

Let me introduce the concept of a "learned person".
Such a person might not actually exist. However,
for my proposes, a learned person knows everything
there is to know about solving the problem at hand.
This is a definition. It is not subject to discussion.

C++ was designed as an object-oriented language.
C and assembler are procedural languages, as have
been most all previous programming languages.

The coding of operating systems is all about
procedures. In fact, one of the reasons for the
superiority of Linux is the great attention to
the details of the actual execution mechanisms
and the actual execution paths.

An object-oriented language relies upon the
compiler and libraries to work out the execution
mechanisms to be used. The programmer is shielded
from the actual mechanisms that implement the
objects being manipulated. For instance, in C, one
can code a loop counter and code the actual
mechanisms by which a procedure may terminate. In
C++, one may use iterators. Whether or not there
is some actual counter is an implementation detail
that can be hidden from the programmer.

Of course one may also write C-like code when using
C++ because there are some things that an object-
oriented mechanism can't do by itself. This allows
one to write loops with loop-counters in C++. The
fact that C++ can be used somewhat like C does not
make it a substitute for C anymore than a hatchet
is a substitute for a hammer.

Because of the object-oriented design of C++, there
is considerable overhead necessary to make it function
in an environment with many other objects. C has some
overhead of its own, too. However, it is quite minimal.
Local variable space is allocated simply by subtracting
a value from the stack-pointer, for instance. The overhead
of a particular language is often demonstrated by writing
a simple "Hello World!" program in that language and then
displaying the result as the size of the executable.
This, of course, is quite unfair. It really shows how
smart the linker is. A smart linker will link in only
the required code. Linkers are pretty dumb.

In the kernel, a linker doesn't have to be smart because
the programmers have provided only the code that should
be executed. There is no runtime library.

Nevertheless, I provide three programs, one written in
C, the other in C++ and the third in assembly. A tar.gz
file is attached for those interested.

-rwxr-xr-x   1 root     root        57800 Jan 20 10:16 hello+
-rwxr-xr-x   1 root     root          460 Jan 20 10:16 helloa
-rwxr-xr-x   1 root     root         2948 Jan 20 10:16 helloc

The code size, generated from assembly is 460 bytes.
The code size, generated from C is 2,948 bytes.
The code size, generated from C++ is 57,800 bytes.

Clearly, C++ is not the optimum language for writing
a "Hello World" program. Because many persons don't know
assembly language, it is probably not the best language
either, in spite of the fact that the executable file is
only 460 bytes in length. Therefore a learned person,
given the task of choosing the language in which to write
"Hello World!" would likely use 'C'. In spite of the
fact that it can be written in C++, I suggest, in fact
insist, that a learned person would never write such a
program in C++ except for the purpose of demonstrating
that it can be done.

When writing code for a project, one is not usually
presented with a bunch of languages from which one can
choose on a whim, or by throwing darts. Instead, there
are specific requirements defined by the nature of the
work to be done. There is no learned person who would
require that a data-base project be written in assembler.
It is quite likely that the optimum language would
be C++. There might be certain portions of the resulting
executable that, in fact, were written in assembler,
probably a lot of the runtime library. When writing a
data-base program, one absolutely positively must not
know what the underlying data-fetching mechanisms are
because, once known and used to define (poison) the
design, the program may run poorly on a network. This
is one of the areas where object-oriented programming
really shines.

However, when writing code that runs in an Operating
System, one is most entirely concerned, in fact consumed
with the mechanisms by which the required functionality
is obtained. Programmers spend hours, days, even weeks,
shaving microseconds off from critical execution paths.
This is because any resources used by the Operating
System directly affect every task running under that
Operating System.

A learned person would never allow the code, defined by
the designers of a compiler, to make the final decision
about the mechanisms necessary to perform the required
functions. Instead, the Operating System programmer makes
those decisions. That's why a procedural language must
be used in coding Operating Systems.

The result of such attention to details is the Linux
Operating System.

Now, if you want to trash your copy of the Operating System
with the output spewed from a C++ compiler, then I suggest
you keep it real quiet. It is similar to "touching up" a
famous painting with spray-paint, of defecating on a wedding
cake.

Again, writing a Linux kernel module in C++ demonstrates
arrogance, absolutely, positively arrogance, and is an
affront to the programmers who have dedicated major amounts
of their time optimizing code execution in the kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



From: Zan Lynx [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Tue, 20 Jan 2004 10:34:39 -0700

On Tue, 2004-01-20 at 08:20, Richard B. Johnson wrote:
> Nevertheless, I provide three programs, one written in
> C, the other in C++ and the third in assembly. A tar.gz
> file is attached for those interested.
> 
> -rwxr-xr-x   1 root     root        57800 Jan 20 10:16 hello+
> -rwxr-xr-x   1 root     root          460 Jan 20 10:16 helloa
> -rwxr-xr-x   1 root     root         2948 Jan 20 10:16 helloc
> 
> The code size, generated from assembly is 460 bytes.
> The code size, generated from C is 2,948 bytes.
> The code size, generated from C++ is 57,800 bytes.
> 
> Clearly, C++ is not the optimum language for writing
> a "Hello World" program.

I like C++ and hate to see it so unfairly maligned.  Here's a much
better example:

Makefile:
helloc: hello.c
        gcc -Os -s -o helloc hello.c
 
hellocpp: hello.cpp
        g++ -Os -fno-rtti -fno-exceptions -s -o hellocpp hello.cpp

Both programs contain exactly the same code: one main() function using
puts("Hello world!").

# ls -l
-rwxrwxr-x    1 jbriggs  jbriggs      2840 Jan 20 10:02 helloc
-rwxrwxr-x    1 jbriggs  jbriggs      2948 Jan 20 10:06 hellocpp

108 extra bytes is hardly the end of the world.
-- 
Zan Lynx [email blocked]



From: Richard B. Johnson [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Tue, 20 Jan 2004 13:10:21 -0500 (EST)

Well you just fell into the usual trap of using the "C-like"
capabilities of C++ to call a 'C' function. If you are going
to use 'C' library functions, you don't use an object-oriented
language to call them. That is using a hatchet like a hammer.

I did not malign C++. I used it as it was designed and let
the chips fall where they may.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

• Archive of above thread