lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: C++ in kernel (was Re: exception in a device driver)
Date

-----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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.031 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site