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

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