Author: David Rasmussen
Date: 04:04:42 12/27/02
Go up one level in this thread
On December 26, 2002 at 23:45:35, Matt Taylor wrote: >>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++. > And with every other language that provides both type safety and the ability to link to and from other linkage conventions, specifically non-typesafe ones. >Type checking can be implemented without name mangling. True. But it is a very simple and effecient manner that can use existing linker technology. >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. > The currect scheme works perfectly and is simple and effecient. I fail to see the problem. >>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. Not necesarily. There are many abstraction mechanisms in C++ which costs nothing. Also, there are many other features that helps careful designing. Namespaces is one very simple thing that can help design immensely by minimizing coupling between independant modules/notions/concepts/ideas. And the abstraction mechanism that do cost runtime, can be used many many places without affecting nps to any relevant degree. >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. > There is no runtime overhead associated with inheritance. It is a compile time technique unless you have virtual functions or multiple inheritance. >I'm also not sure why you think abstraction helps eliminate bugs. I am not alone with this belief. It is a very well documented "fact", and has been the impetus for the design and evolution of many languages, even systems programming languages such as C++ and Ada (and C for that matter). Would you maintain the the concept of a function doesn't help design at all in a language like C? We should just write all our code in main()? The function is the primary abstraction mechanism in C, and a very important one. C++ adds many more, all of the designed to have no runtime overhead unless necesary. >My bugs are >almost always transcription bugs or violation of preconditions within a module. You are lucky then. You can see from Robert Hyatt's well documented development process (in main.c), that many of his bugs are not of that kind. A philosopher in the 18th century tried to construct a language in which it was impossible to express a lie. One of the criteria of success of the design of a computer program is that there is a tight correspondance between syntax and semantics, so that nothing can't be expressed syntactically that doesn't have a well defined (and intended) meaning semantically. This ideal is hard to reach, but good to keep in mind. In a good design, semantical bugs are harder to express syntactically. >If I wrote the same code in C++, I would get the same results. If you wrote the same code, yes. C++ is _not_ C. Nor is it C with Classes. Even small and trivial examples of C programs will look entirely different when expressed by a good C++ programmer. Bjarne Stroustrup has several interesting articles on his homepage that addresses this. >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. Exactly! C++ isn't only about OO, as I've already said. >I >usually get the design right and implementation wrong. > Even if you make a very nice design, you will have a hard time expressing it in C, and you will find it impossible to have the language implementation enforce your design. In C++ this is much much easier. The primary reason for the existance of C++ and for most individual C++ features is to better be able to express design decisions and have the language implementation enforce it. Stroustrup could have made a more abstract language, but that wasn't his intend. He wanted a systems programming language with the performance of C, but with much better opportunities for expressing design decisions. Ada is a very very beautiful example of this too, but has some problems too, the most important of which is that much less effort has been put into Ada compiler implementations than into C++ and C implementations. >>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. > I'd like to see those figures. I am aware of such things as the Stepanov abstraction benchmark. But there is no reason to use the highest possible level of abstraction when writing a chess program. You can gain a lot with no runtime overhead. You can gain even more if you're willing to sacrifice 0-5%. It's the programmers choice. There is a huge difference in the NPS of different competitive programs anyway. 0-5% for a huge design benefit might not be too much. But if you think so, don't use abstractions that cause overhead. >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. > One should always be careful. That's also the case in C. /David
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.