Sematically -- may be. Functionally -- they are exactly same: object with one
VIRTUAL function and one data field.
BS> The fact is that the ONLY difference between a struct and a class in C++
BS> is that classes have a default private scope for all its members.
Of course. Why there are two words -- is not clear to me. But it's other story.
BS> In all of your examples I can recall you insist on declaring the methods
BS> as virtual yet you don't bother to write code in your C example to support
BS> the same functionality (FYI - your C example is not an example of the
BS> capabilities of a virtual call).
Are you joking or just incompetent or may be just plain stupid ? There IS
capabilities of a virtual call and more.
-- cut --
struct someclass {
int i;
int (*foo)(struct someclass*); /* Note this POINTER to function !!! */
};
-- cut --
Call goes via foo POINTER TO FUNCTION and thus, of course, VIRTUAL.
It's as
clear as it is. Only stupid C++ advocates could claim that this call is not
virtual while in fact it's even "more virtual" then call to C++ virtual
function...
BS> Why do you insist that C++ methods be declared virtual?!?!?
Since there are virtual calls in both C++ and C sample. C++ VIRTUAL CALL
requires one additional inevitable memory reference over C VIRTUAL CALL.
But looks like all your brain is wasted for C++ are no more room for any
new information.
BS> Additionally cout and printf are no where near the same.
Indeed. That's why I'm not compare SPEED of two versions. I compare CODE !
BS> If you want a direct comparison go ahead and use printf in your C++
BS> examples or else you should implement a iostream capable equivalent of
BS> printf (not likely).
It's doable but I'm not know if this will be very usefull. BTW what about
C++ equivalent of printf(_("File %s is size %d"),filename,size); with
-- cut --
msgid "File %s is size %d"
msgstr "Size of this file is %2$d and it's name is %1$d"
-- cut --
In .po file. BOTH iostream and stdio libraries has advantages and disadvantages.
And I'm not compare iostream and stdio here. I compare speed of virtual call
in C and C++ via inspection of code. Ok. If this iostream vs stdio issue
blinds you so much how about the following sample:
-- C++ code --
class someclass {
int i;
public:
explicit someclass(int _i) : i(_i) {}
virtual foo() {
}
};
void test(someclass& x) {
for (int i=0;i<100000000;i++)
x.foo();
}
void main (void) {
someclass a(1);
test(a);
}
-- C code --
struct someclass {
int i;
int (*foo)(struct someclass*);
};
int someclass_deffoo(struct someclass* x) {
}
void test(struct someclass* x) {
int i;
for (i=0;i<100000000;i++)
x->foo(x);
}
int main (void) {
struct someclass a={1,someclass_deffoo};
test(&a);
return 0;
}
-- cut --
Here time of C++ code is 4.020s while time of C code is 3.580s ... And PLEASE
DO NOT CLAIM THAT CALL IN C IS NOT VIRTUAL. This will be just prove of your
complete stupidity and nothing more... Since this sample does not have neither
iostream not stdio may be you'll be able to see on sample and stop attack
windmills ...
BS> All of your code comparisons are examples of ignorance of C++ or plain
BS> intellectual dishonesty.
Not at all. Looks like you just not have enough brain to undertood even trivail
sample. All you brain is wasted on useless C++ :-)
BS> Its also getting way offtopic (which is why I even now hesitate to post
BS> this) because we've left behind the issue of linux kernel issues and
BS> how the language features apply to it.
Not at all. This is EXACTLY the point: for ordinal programs one additional
memory
reference usually acceptable while in kernel there are is timer-critical
parts.
Also function in C sample is "more virtual" then in C++ sample -- you could
change nature of object at runtime. Sometimes it's usefull feature but it's
not in C++. If you think that this is not virtual call than this means that
you just completely misunderstood how virtual functions are realised in C++
and this is REAL PROOF of inacceptability of C++ for kernel -- if even C++
advocates are not aware about internals of virtual functions that this is
clear sign of inacceptability of such language for kernel !
BS> Khimenko Victor wrote:
>> In <003101be3db0$d4d945e0$04c809c0@Fake.Domain.com> Anthony Barbachan (barbacha@Hinako.AMBusiness.com) wrote:
>>
>> AB> 1 - It does not lead to speed loss.
>>
>> It does. Take a look:
>> -- C++ code --
>> #include <iostream>
>>
>> class someclass {
>> int i;
>> public:
>> explicit someclass(int _i) : i(_i) {}
>> virtual foo() {
>> std::cout << i << endl;
>> }
>> };
>>
>> void test(someclass& x) {
>> x.foo();
>> }
>>
>> void main (void) {
>> someclass a(1);
>> test(a);
>> }
>> -- C code --
>> #include <stdio.h>
>>
>> struct someclass {
>> int i;
>> int (*foo)(struct someclass*);
>> };
>>
>> int someclass_deffoo(struct someclass* x) {
>> printf("%d\n",x->i);
>> }
>>
>> /*
>> * int someclass_otherfoo(struct someclass* x) {
>> * printf("%d\n",x->i<<1);
>> * }
>> */
>>
>> void test(struct someclass* x) {
>> x->foo(x);
>> }
>>
>> int main (void) {
>> struct someclass a={1,someclass_deffoo};
>> test(&a);
>> /*
>> * a.foo=someclass_otherfoo;
>> * test(&a);
>> */
>> return 0;
>> }
>> -- cut --
-
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/