public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Friesen <cfriesen@nortelnetworks.com>
To: root@chaos.analogic.com
Cc: "Dr. David Alan Gilbert" <gilbertd@treblig.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: C++ and the kernel
Date: Tue, 09 Apr 2002 10:00:25 -0400	[thread overview]
Message-ID: <3CB2F3F9.8325AC04@nortelnetworks.com> (raw)
In-Reply-To: <Pine.LNX.3.95.1020409085537.4291B-100000@chaos.analogic.com>

"Richard B. Johnson" wrote:
> 
> On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:
> > 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.
> 
> The file operations structure(s) are structures. They are not object-
> oriented in any way, and they are certainly not virtual. The code that
> manipulates them is quite physical and procedural, well defined, and
> visible to the rest of the kernel.

I disagree.  A filesystem has a certain set of semantics.  There are numerous
types of filesystems, each of which implements that set of semantics (and
possibly additional ones as well) in a different way.  This is a classic example
of a situation where oo style programming can be useful.  There are many cases
where C code is in essence implementing virtual functions using function
pointers.  C++ allows the compiler to do the hard work of keeping track of the
virtual functions.

> It is quite unlikely that a C++ compiler will make more efficient
> code than a C compiler. In fact, the code generator will likely
> be the same. The C++ compiler will end up generating some preamble
> code as part of the function-calling mechanism, that is not necessary
> in C. This means that it will generate a bit more code.

C++ has tigher constraints on code than C.  This can allow a compiler to
generate better code because it has more knowledge about what is going on.


> Making code "cleaner" is a matter of perspective.
> 
>         class A {
>         public: void func(char *st) { cout << st << endl; }
>         };
>         using A::func;
>         A a;
>         a.func("Hello World!");
> 
> Is not all that clean. In fact, I'm not sure I have it right. It's
> easier and clearer to write  puts("Hello World!");

Your example is needlessly complex, and I'm sure you know this.  A more
realistic comparison would be:

cout << "Hello World!\n";

Now I don't for a moment think that we should go and convert everything to C++. 
But I do think that certain features of the language can be useful, and that
there are cases when OO style programming makes the code easier to read and
understand.


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

  reply	other threads:[~2002-04-09 13:50 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
2002-04-09 13:28       ` Richard B. Johnson
2002-04-09 14:00         ` Chris Friesen [this message]
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=3CB2F3F9.8325AC04@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=gilbertd@treblig.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox