Not sure what you are saying here, but it sounds as if you are saying that
we shouldn't use C++ because C's more limited and inefficient psuedo object
model is "adequate" for our task? This sounds like MS's theme of becoming
successful with "good enougth" software, not striving for excellence.
Obviously if we starting using C++ we would probably start making some use
of classes, so the argument that we would not be using C++'s object model
(at least for some things) doesn't make sense.
>>> 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).
This can also be done by using a common base parent class, some children of
that class, and then a final class inheriting all the children virtually,
topped off with a function that automatically switched the virtual function
pointers. This code works and is C++ compatable.
> 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 :-)
>
I wouldn't do his C++ example to acomplish what you were trying to do. You
could very well do the same function pointer hack in a C++ class as well.
You could even keep this particular code C based as well, as its also C++
compatable. Or you could do something similar in the way I mentioned above
with virtual inherited children.
>>> 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
Code/data size nor speed are an issue with C++, unless you start to be
creative with unneeded features. The same ineffiences could also be done in
C or any other language.
>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
The above is virtually never done and doesn't have to be done that way.
>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++
The C++ example above was not an optimal example of C++ use. Besides which
it can be done just as efficiently in C++, you can even keep this same code
and only use C++ classes where it does provide an improvment in effiency or
code cleaness.
>is full of quirks -- even C++ advocates could not say right things about
Any language is full of quirks. And C++'s quirks could be minimized by not
using unessential features.
>constructs after first glance... But UNLIKE perl C++ pretend to be very
>effective language while it's not.
>
It is efficient, its even used in embedded systems which have less resources
available to it than the kernel usually does.
>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/
>
-
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/