Author: Matt Taylor
Date: 20:45:35 12/26/02
Go up one level in this thread
On December 26, 2002 at 07:07:19, David Rasmussen wrote: >On December 25, 2002 at 15:27:03, Dave Gomboc wrote: > >>On December 25, 2002 at 15:00:21, Matt Taylor wrote: >> >>>> >>>>OK. Inability to use a tool shouldn't be blamed on the tool. >>> >>>Unless the tool is kludgy, in which case the tool can be blamed for being >>>difficult to use. >>> >>>-Matt >> >>Um... there are much harder things in software development than declaring a >>function extern "C". >> > >I was about to say almost the same: >If writing extern "C" is your most complex problem, you're lucky. I don't find >it kludgy at all. You don't have to use it, you only use it if you want that >specific feature (C linkage). How would you suggest a language goes about being >type safe and also having optional C linkage? It is not my most complex problem, but I would prefer to divert my attention to my complex problems rather than on trivial syntax. It is in either case an irritation I have with C++. Type checking can be implemented without name mangling. The only problem is when you have multiple functions with the same name and different parameter types. Usually in this case they all backbone on the same functionality; the multiple instances will do things like data conversion and implicit parameters for you to make your code more consise. Since there is no defined standard for exporting multiple functions under the same name, the best option is to represent the function heirarchy as a tree and pick one at random with no parent node to receive an undecorated name. Functions inside classes can be decorated because you can't reasonably export them to other languages anyway. (Actually you can if you implement the functions in C and provide a C++ wrapper.) Type information can be passed as a seperate section in the object file. A C++ aware linker can match the type information section. Without a linker that understands the type information, you can still produce valid executable code. All you lose is the type checking. >All of this is really peanuts. >I can't believe there's a whole subthread about mispredictions of unconditional >jumps (which I don't believe affects prediction anyway). Dann said it very >concisely: >"The performance cost for changing to C++ will be 5% at most, if it is done >right. > >The increase in abstraction will be worth this cost many times over. Trying out >new ideas will be ten times easier." > >You wont lose any relevant performance (if any at all. Actually you might gain >performance, depending on your competence), and you will gain a lot from design >and abstraction. Look at the development log of Crafty, or think about the bugs >in your own engine (if you have one). Many of these bugs are of the kind that >could never happen with the right design. High levels of abstraction do result in slower code because the existing compiler implementations cannot optimize the code to the same levels of efficiency. For simpler constructs like classes without inheritance, the performance is identical. Classes with inheritance suffers some penalties. Templates are fast but very large, and you may lose performance from the size of the code generated. I'm also not sure why you think abstraction helps eliminate bugs. My bugs are almost always transcription bugs or violation of preconditions within a module. If I wrote the same code in C++, I would get the same results. Classes are merely a means to organize code -- something that I do naturally regardless of language. A good design does not imply OO, nor does OO imply a good design. I usually get the design right and implementation wrong. >It's not to say that everybody writing a C engine is a fool or that C++ is the >only language to use. It's just that this thread shows a lot of misconceptions >about C++ that need to be corrected. There are no inherent problems in using C++ >for this, in fact there are many advantages. If people choose C, fine. Just >don't spread false information about C++ to justify it. > >/David The evaluation of the value of abstraction is completely arbitrary and up to an individual's opinion. The evaluation of the speed of the code, however, is not, and all the figures I have ever seen corroborate what I'm still claiming. When you peel away the black box from C++, you see several facilities added to C. Not all of these hurt performance. I'm saying that some do. When performance isn't critical, go hog wild. In a chess engine, make those choices carefully. -Matt
This page took 0.24 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.