Messages in this thread | | | From | "Marco Ermini" <> | Subject | Re: linux headers and C++ | Date | Tue, 6 Jul 1999 17:53:30 +0100 |
| |
----- 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/
| |