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/