lkml.org 
[lkml]   [1999]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: linux headers and C++
Date
----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Marco Ermini <mail@markoer.org>
Cc: <linux-kernel@vger.rutgers.edu>
Sent: Tuesday, July 06, 1999 1:40 PM
Subject: Re: linux headers and C++


> > Apart from this C++ is no more just a
> > pre-processor. Of course a C and ASM
> > hacker could feel in this way, but it's not
> > true; C++ could be used as an improved-C
> > or as a full-featured OO-language. Using
>
> C++ is a preprocessor, nothing more. Check how the original C++ compiler
was
> implemented.

Alan, I think your information about
C++ are a bit outdated.
Of course, in the early days C++ was just
a preprocessor, but I don't think a
preprocessor could alone implement
dynamic thunking, or dynamic template
generation, or dynamic binding of the class
methods invoked by derivated functions. All
things that you can't do in C. If
you'll read Stroupstroup you'll agree
with me. In these days, a good C++
compiler is much more than preprocessor
+ C (I am not speaking of gcc; of course,
I appreciate the very good work on
the C compiler, but I really can't include
its C++ on the "good" side of compilers.
For commercial things I had to buy
Metrowerks C++ compiler for Linux.
Maybe egcs is more good, I don't
know).

> > C or ASM or another language in an OO
> > way without a specific support for this could
> > lead to more complications that it's worth (i.e.
> > you could program as you have inheritance
> > without having a keyword to do it, but it's
> > very difficoult to keep the code clean).
>
> Have a look at all the operation arrays on objects in Linux. Inodes are
also
> virtual classes and all the other buzzwords.

Of course, you know all the Linux
sources much more than me. For what
I could see (and of course it's just my
5 cent worth opinion) Linux is kept
clear and simple as much as possible,
but I can't say it's planned with OO
in mind. Of course there are thinks
that are well designed, so you could
rewrite inodes code and don't have
to change it for all the filesystems you
manage (it's just an example, don't
take any word for good since I don't
know this part of Linux), but I don't
feel it being *true* OO.

Maybe I could explain what I mean
for a true OO OS: you define a class
for a "serial communication device", you
define a "serial port", you inherit a "modem"
from both of these and a little more code.
You define a "pluggable devices", you inherit
"PcCard", and inherit a "PCMCIA modem"
from "PcCard" and "Modem". Then, if you
write the "USB subsystem" (of course from
the "pluggable devices" class), you define an
USB modem simply with another class, inherited
from "USB" and "modem". And the like with
USB soundcards, etc. Then you could
realize that, if Linux was a truly an OO OS,
the USB should be realized months ago...

Of course, and that's what I meant
originally, this could be a very fashinating
approach, but I think it's much more
theroethical that really doable. Maybe,
the code and the complexity needed to
realize this approach was much more
than it's worth, and at the end, the
simplicity of Linux it's the best method.
Unix-like could seem a very old approach
in realizing an OS, but it's functional, and
it works...

(I think NT was planned with that kind
of object orientation in mind, but
the commercial constraints and the need
to optimize certain parts, degrading the
others, leaded to all that kind of
complexity - and subsequent malfunctions -
that we have today. Think about embedding
Internet Information Server in the NT 5
kernel, just because Microsoft wants NT
to be the fastest web server...).

> > results. Linux could be not OO, but the
> > sources are (quite) always clean and
> > understandable.
>
> I guess it depends what you think of as object oriented. Linux has a very
> clear set of abstractions to objects - inodes, files, sk_buffs. I
regularly
> merge several hundred K of changes with Linus and the kernel is very very
> modular in the abstract sense - the number of overlapping changes is
almost
> nil.

I hope I understood what you mean with
"object oriented"... an OO abstraction could
be done with Cobol, for istance, but the code
needed could lead to much more complexity
than it's worth. I think C++ is much more
suited than C (how could you do multiple
inheritance in C, without writing very
unreadable code?), but you know, you
could do it, and you could do it in assembly too,
for istance.


Cheers,

Marco



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.091 / U:3.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site