Author: Matt Taylor
Date: 18:36:49 12/26/02
Go up one level in this thread
On December 26, 2002 at 08:50:27, David Rasmussen wrote: >On December 25, 2002 at 15:38:19, Matt Taylor wrote: > >>>Overloading costs nothing, it's a compile time construct and is resolved at >>>compile/link time. >>>Inheritance costs nothing, it too is a compile/link time issue. >>>You know nothing about C++, do you? I didn't think so. >> >>Overloading costs an indirect function call. > >What? No it doesn't. Overloading is resolved at compile time by a well defined >set of rules. See The C++ Programming Language 3rd ed. p. 149. > >I recommend both of you to read that book and also The Design And Evolution of >C++, to get an understanding of how much care has been taken to not impose >runtime overhead on features that doesn't need it. It would help if everyone was using the same terms. I was not quite sure whether Vincent was using the term overloading as interchangable with virtual functions. I did get the semantics wrong, but I have been doing much more Java lately than C++. I've limited my C++ to basic classes (no polymorphism or inheritance) and basic templates. >> I'm not sure if you can apply const >>to a class like you can apply final to one in Java, but unless the compiler >>knows the class can't be inherited from, it has to make the operator an indirect >>function call. >> > >What has this to do with overloading? Overloading means using the same name for >different things. Overriding and virtual functions are something different. I am >responding to "overloading" because that was the word Vincent used. > >>>>I had to chose between writing my GUI functionality (database and such) >>>>in C or C++ before i started. Initially i wanted to start it in C++ >>>>but in the end i figured out that speed for a chess database is not >>>>unimportant so i wrote it in C. >>> >>>If there was a speed difference for that kind of application, it just goes to >>>show how bad you are at C++ programming, or at programming in general. >> >>C code in C++ is the same speed, but using C++ constructs can be slower. > >Or faster. There will not be a speed difference for this kind of application if >done right, even if you have a nice design with abstraction benefits etc. Not usually. Theoretically abstraction from the machine yields more optimal code because the compiler gets to pick more things. Practically, the compiler cannot think, and it takes good programmers to recognize and write code for different cases to make them optimal. C has been around for more than 30 years. C++ is still somewhat young. Some of the C++ constructs optimize very well, but many don't, particularly templates. >>Multiple inheritance, polymorphism, etc. >> > >You don't have to use those features. And when you do, you would have to do >something similar to obtain the same effect. It's the programmers choice. Ok, but wasn't that the question? Generally "converting to C++" is held synonymous with "converting to object-oriented class heirarchy with polymorphism." >>>>But i could of course have done it in C++ as well. In fact if i change >>>>the extension of the code from *.c to *.cpp then it pretty quickly >>>>is c++ code already, the nearly same code being both C and C++. Says >>>>enough to me about speed differences. >>> >>>C++ has nothing to do with extensions, Vincent... >> >>Most compilers I have worked with (Borland, Symantec, Microsoft) decide whether >>to compile C++ or C based on file extension, though you can always pass a flag >>and force C++ rules. I believe GNU C also does this, but I have ignored the >>commandline options except for optimization flags. >> > >And this is relevant in what way? > >/David It's relevant in answering the same question you did. Vincent's text is so garbled that I have no idea what he said originally, but the point is that most compilers implicitly recognize language by extension. In the case of C/C++, since C++ is a superset, you usually have a compile flag to force C++ compilation of C files. -Matt
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.