Messages in this thread |  | | | From | "Khimenko Victor" <> | | Date | Sat, 16 Jan 1999 16:20:52 +0300 (MSK) | | Subject | Re: C++ in kernel (was Re: exception in a device driver) |
| |
In <19990115230842.C767@perlsupport.com> Chip Salzenberg (chip@perlsupport.com) wrote: CS> According to Khimenko Victor: >> Even two constructs like >> A. someclass var(1); >> B. someclass var=1; >> are NOT equal!
CS> Yes, and ... ? Initialization and assignment are entirely different CS> animals in C++. Anyone who doesn't know that isn't ready to _read_ CS> C++ code, much less write it.
Uh, oh, bummmm. This mean that YOU are one who "isn't ready to _read_ C++ code, much less write it". (Hint: there are NO assignment in BOTH constructs!). >> Somebody: >> > However, C++ has some language features that let you specify optimal code >> > constructs that would otherwise have to be hard-coded in C. The fact is that >> > you don't need to know any more than you would with C and some times less. >> >> You'll need to know HUNDREDS of C++ quicks instead ...
CS> Exaggeration. Tsk.
Exaggeration ? When even C++ advocate is able to write stupid comment about simpiest constructions after first glance ? Are you joking ?
>> If you'll use objects you are tied to VERY LIMITED C++ object model.
CS> That's a feature, not a bug. C++'s object model is limited to CS> features that have efficient implementation and which penalize only CS> those who use them.
Yes, but why use it at all ? We could create object model by hand in C and this object model will be adequate for our tasks (still may be more limited then C++ model in some cases). And if we will not use C++ object model then why use C++ at all ? C++ is former "C with classes" after all :-))
>> In C++ could not change nature of your class in run-time -- it's >> hardcoded in compile-time.
CS> You are mistaken. Standard C++ features allow just such CS> transmogrification. I should know -- it's a key part of the CS> implementation of (what might become) Perl 6. Example:
CS> Base *target = new Derived1; CS> // begin transmogrification CS> void *p = dynamic_cast<void *>(target); CS> target->~Base(); CS> target = new (p) Derived2; CS> // end transmogrification CS> Tadaa, all done. Only requirement is that the new class be no larger CS> than the old one -- same as C. :-)
Unfortunatelly this is 1. Not feature of C++ but feature of GNU C++ (i.e.: non-portable; still most implementation will work Ok here). 2. Since target could change value after such "change nature of your class" so it's not exactly change nature of your class -- more like optimization of new/delete call.
Now about speed issue: -- C++ code -- #include <memory>
struct Base { int x; virtual foo() { } virtual ~Base() { } }; struct Derived1 : Base { virtual foo() { } }; struct Derived2 : Base { virtual foo() { } }; main() { Base * volatile target = new Derived1; for (int i=0;i<1000000000;i++) { // Cast to Derived2 void *p = dynamic_cast<void *>(target); target->~Base(); target = new (p) Derived2; // Cast to Derived1 p = dynamic_cast<void *>(target); target->~Base(); target = new (p) Derived1; } } -- C code -- struct Base { int x; int (*foo)(struct Base* this); }; int Base_foo(struct Base* this) { } int Derived1_foo(struct Base* this) { } int Derived2_foo(struct Base* this) { } main() { struct Base * volatile target = (struct Base*)malloc(sizeof(struct Base)); int i; target->x=0; target->foo=Base_foo; for (i=0;i<1000000000;i++) { // Cast to Derived2 target->foo=Derived1_foo; // Cast to Derived1 target->foo=Derived2_foo; } } -- cut -- C++ sample will work 267s while C sample will work 78s (Pentium200MMX, pgcc 1.1)... This speedup could be essential for kernel IMNSHO. (Note volatile BTW -- without volatile for cycle in C sample could be even optimized away :-) >> C++ is just big non-shapen heap of different things, not clear >> language like Ada or even Java. Some concepts there are usefull, >> some not. But it's total mess as whole.
CS> C++ is a tool, not a sculpture. Read "The Design and Evolution of C++" CS> if you don't like this. Stroustrup is eloquent and, I believe, right.
C++ is the tool of the same class as perl: if you must create something quick and not bother itself by neither speed nor code/data size issues you could use perl or C++. When you need speed... Or when size is matter... Take a look on sample above once more (and not say that C++ sample is more flexible then C sample: I know this but if you want convert C artifactual "classes" to C++ "real" classes you could not do any better; plus in C you could be 100% sure that value of target is not changed unlike C++)... And exactly like perl C++ is full of quirks -- even C++ advocates could not say right things about constructs after first glance... But UNLIKE perl C++ pretend to be very effective language while it's not.
P.S. May be we must rewrite linux kernel on perl ?
- 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/
|  |