All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <gilbertd@treblig.org>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Martin Dalecki <dalecki@evision-ventures.com>,
	"T. A." <tkhoadfdsaf@hotmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: C++ and the kernel
Date: Tue, 9 Apr 2002 13:26:22 +0100	[thread overview]
Message-ID: <20020409122622.GN612@gallifrey> (raw)
In-Reply-To: <3CB2BA4C.80200@evision-ventures.com> <Pine.LNX.3.95.1020409075919.4157A-100000@chaos.analogic.com>

* Richard B. Johnson (root@chaos.analogic.com) wrote:
> 
> I would like to rewrite the kernel in FORTRAN because this was
> one of the first languages I learned.
> 
> Seriously, the kernel MUST be written in a procedural language.
> It is the mechanism by which something is accomplished that defines
> an operating system kernel.
> 
> C++ is an object-oriented language, in fact the opposite of a
> procedural language. It is not suitable.

Bollox!

There are many places in the kernel that are actually very OO - look at
filesystems for example. The super_operations sturcture is in effect a
virtual function table.

Sure making every file an object is probably OTT; but large scale things
like a filesystem, a network device or the like probably actually fit
very well.

Sure, there are a lot of features of C++ to stay clear of - exception
handling probably being one of them, and I wouldn't let the C++ stuff
anywhere near the memory management code.

Point being that it is a case of using the write tool for the job.  C++
douesn't add any extra overhead just by calling it C++ and not using any
of the features; careful use of the features where appropriate does no
harm and might actually make the code cleaner, and possibly more
efficient.

I will agree going head in and just throwing C++ at it is a bad thing.

Dave

 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

  reply	other threads:[~2002-04-09 12:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09 10:16 C++ and the kernel T. A.
2002-04-09  9:54 ` Martin Dalecki
2002-04-09 12:10   ` Richard B. Johnson
2002-04-09 12:26     ` Dr. David Alan Gilbert [this message]
2002-04-09 13:28       ` Richard B. Johnson
2002-04-09 14:00         ` Chris Friesen
2002-04-09 13:55           ` Sean Neakums
2002-04-09 14:00             ` Alexander Viro
2002-04-09 14:02         ` Michael Clark
2002-04-09 14:30         ` Rik van Riel
2002-04-10  1:52         ` H. Peter Anvin
2002-04-09 17:17     ` T. A.
2002-04-09 21:51       ` J. Dow
2002-04-09 23:11         ` Rui Sousa
2002-04-09 17:27   ` T. A.
2002-04-09 11:29 ` Erik Mouw
2002-04-09 16:21 ` Kurt Wall
  -- strict thread matches above, loose matches on Subject: below --
2002-04-09 16:45 Sau Dan Lee
2002-04-09 16:51 Sau Dan Lee
2002-04-09 16:58 ` Richard B. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020409122622.GN612@gallifrey \
    --to=gilbertd@treblig.org \
    --cc=dalecki@evision-ventures.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=tkhoadfdsaf@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.