>> > 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.
I not think. I know :-) Latest versions of cfront had (has? is cfront still
alive?) had all such bells and whistles acting as preprocessor...
> All things that you can't do in C. If
> you'll read Stroupstroup you'll agree
> with me.
Hmm. Cfront was developed under Stroustroup lead, don't it ?
> 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).
I'm yet to see feature of C++ not doable with sophistocated enough
preprocessor... Egcs has MUCH better implementation of C++ but not
[yet] ANSI C++ compliant.
>> > 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.
Then what's your definition of *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.
Why you think that multiple inheritance is so important for "true" OO ?
> You define a "pluggable devices", you inherit
> "PcCard", and inherit a "PCMCIA modem"
> from "PcCard" and "Modem".
Yet again: multiple inheritance. Ugly code bloat in 99% cases.
WHAT code can be inherited from abstract "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...
Not at all. Usually multiple inheritance add a lot of complexity without
real gain. USB is not realized not due problems with Linux design but simple
since there are was not enough motivated and skillfull hackers :-))
And no you do not need "USB soundcard". You just need clearly separated
abstractions. So just one soundcard driver will be used for ISA, PCI, PCMCIA
and USB soundcards with the same chipset...
> 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.
More important: it's much more sophisticated then really need !
> 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.
You can do multiple inheritance with C if you really need. But in most cases
it's just not needed. Simple and clean source text of C++ usually lead to wrong
assumptation of simple and clean compiled code. Unfortunatelly this is not
a case: A LOT OF simple and elegant C++ constructs lead to ugly code.
Multiple inheritance is one of them. On other hand ugly things (like multiple
inheritance :-) lead to ugly C code and that is usually enough to understood
that something is wrong with design...
-
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/