Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | Thu, 14 Jan 1999 00:49:01 -0500 |
| |
-----Original Message----- From: Khimenko Victor <khim@sch57.msk.ru> To: scherrey@proteus-tech.com <scherrey@proteus-tech.com>; scherrey@gte.net <scherrey@gte.net>; linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu> Date: Wednesday, January 13, 1999 8:21 PM Subject: Re: C++ in kernel (was Re: exception in a device driver)
>In <369CFCBC.78A86F84@gte.net> Benjamin Scherrey (scherrey@gte.net) wrote: >BS> Mr. Victor, >BS> I've refrained from replying to your previous attacks on C++ but you >BS> continue to persist in a habit of comparing C code with C++ code that is >BS> functionally and semantically different. > >Sematically -- may be. Functionally -- they are exactly same: object with one >VIRTUAL function and one data field. >
Keep in mind that virtual functions aren't required for C++'s object model. This results in much more saving than that one instruction C saves when calling virtual functions; besides which the same thing could also be done in a class in at least two ways that do not execute that extra instruction.
>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.
It doesn't have all the capabilities of virtual functions under C++. You have to initialize it yourself and if you forget or point to the wrong function; well there's always the reset button.
>-- 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... >
It basically the same, not more virtual. And it may be less so in that this is really just a hack to elmulate a virtual function under C. In C there is no garantee that there really is a function where the pointer is pointing to.
>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. >
Again the vast majority of times there is no need to inplement member function as virtual in C++. Its not needed to acheive an OO relationship between data and some functions.
>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 ! >
If you insist on have cout and printf there then you are comparing iostream and stdio which are made completely different to achieve different purposes, not C and C++. iostream's nature is basically a series of abstraction layers to allow for easy integratability with other objects; obviously this would have a tradeoff for this functionality.
>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
1. There was no need for that function to be virtual. 2. You could have done the exact same function pointer hack with a C++ class. And even used a static function to maintain the OO nature. 3. You gained 4 bytes and an instruction within the initialization of the object and the pseudo-object.
>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
Same could be done in C++ classes, I have. Not to mention that there is no need to abandon the original C code in a C++ kernel.
>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 ! >
C++ can be very simple, just stay away from the unneeded, overcomplicated parts.
>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/ >
- 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/
| |