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:08:37 -0500 |
| |
-----Original Message----- From: Dmitry Torokhov <dtor@solvo.spb.su> To: Khimenko Victor <khim@sch57.msk.ru> Cc: 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 9:34 PM Subject: Re: C++ in kernel (was Re: exception in a device driver)
>Hi, > >I've been reading this thread for a long time and I think we should not >blame >language itself for compiler problems. All extra instructions g++/egcs >puts >into the code are compilers problem, not C++ problem. And I agree with >Benjamin when he does not agree that virtual function call and indirect >function call is slightly different things. While indirect calls are >more >flexible and allows run-time behavior change, virtual calls save >programmer's >time and _can_ save memory footprint, because VTBL is/can be stored >outside >class instance and therefore saves us that precious memory everybody is >worried
You've got your function types mixed up. It the other way around.
>about. It also does not require manual initialization of those function >pointers. >Besides, nobody prohibits us from using indirect calls in C++. > >And as for example you provided, there is no need to indirect call in >C++ code >at all. Compiler does vtbl dereference at compile time for virtual calls >when >they done without using pointers/references to class :) (i.e. x.foo()), >It >knows what x and what foo exactly are, so why use pointers at all. >(Unfortunately in real life it happens not too often). > >As for seed in your examples ecgs -02: >testc 2.30 - 2.33 >testcc 2.25 - 2.26 > >So for _your_ example C++ is _more_ efficient for speed. (But exec size >is >more for c++, i think because of bugger start-up code for c++). > >As for kernel story I'm not sure... Efficient C++ realization may >require >kernels redesigning, and i doubt it's Right Thing To Do at this time. >Compiler problems - if someone use C++ for time critical projects they >will be solved as they is/were solved for C. > >And please, let's not be rude :) > >Sincerely yours, > Dmitry > >Khimenko Victor wrote: >> >> 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. >> >> 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 ! >> ><rest skipped....> > >- >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/
| |