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