Author: Matt Taylor
Date: 12:30:23 12/25/02
Go up one level in this thread
On December 25, 2002 at 06:05:39, David Rasmussen wrote: >On December 24, 2002 at 13:32:42, Matt Taylor wrote: > >> >>I am aware of the virtues of C++. I have been programming in C++ for the past 10 >>or 11 years. Not as long as some, but plenty long enough to be intimately >>familiar with the language. >> > >That depends on how you've used it, and whether you've tried to keep up. C++ of >today is not C++ 5 or 10 years ago. Besides from the standardization in 1998, we >know a lot more today than we did 10 years ago. > >>My point was that polymorphism would be the main benefit for a chess engine. > >I disagree. Please name some other uses then. >>I >>don't see any particularly clever use for templates or operator overloading >>here. Of course, some will always do it because they can, even if it's a bad >>idea. >> > >Imagination is the key here. C++'s features can be used for chess programs in a >positive and constructive manner. > >>A switch statement will always be faster if the compiler is any good at >>optimizing it. The difference is that it avoids extra stack usage, function call >>setup costs (preserving registers), and in some cases you can get a branch >>prediction hit. >> > >It depends. You can't just compare a virtual function call to a switch statment. >Often this switch statement will be inside some function, so there is function >call overhead anyway. The cost of this function call + the switch statement >needn't be lower than that of a virtual call. Also, I don't want to "optimize" >just for the sake of doing it. Virtual functions, if needed at all in this case, >can be used many places in a chess program without affecting overall speed. If >you find on your particular implementation that with your particular design and >program, skipping virtual functions will give you 5% more speed (which will >depend on your implementation, and only be the case if you use them at the heart >of some often used code, check with a profiler), you can decide whether you want >to break your design for that 5% gain. It practice, it's not an issue if you do >it right. In the case of a direct call, the pipeline is not broken as the address can be predicted. Furthermore, if you profile, you can inline in some cases for more performance. Most switch/case statements get implemented using a table of pointers, but for small ones (such as move generation where you have a limited number of pieces), you can do it extremely efficiently. Also, since static prediction predicts "not taken," you're putting useful code in the cache. >>>>If you convert to C++ without using virtual functions, you probably won't take >>>>much of a hit at all. Personally, I've never seen a -need- to convert to C++. >>> >>>I see no need to use an inferior language to express the same thing for no gain >>>at all. C++ gives my type safety, better I/O and a lot more. >> >>Better I/O? You mean you like the I/O library better? > >I mean first of all type safe I/O unlike printf etc. >Also, the expressibility of iostreams cannot be compared to the printf family of >classes. iostreams are much more expressible. > >> I find printf-style easier >>to read. I've never had a problem with %f bugs in my code because I don't pass a >>user string into printf directly. >> > >Lack of type safety. >I have seen many bugs of this kind, if not in my own code. Actually the gcc compiler will type check printf arguments in C or C++ code. >>In terms of "good language" vs. "bad language", C++ really maintains no >>advantage over C. > >Sure it does. Even pure C with a C++ compiler is better than C, because several >holes in the type system have been closes, enums etc. Only within a module. Name decoration is required to check between modules. The biggest source of type check bugs lies in header files that don't match libraries. >>Someone who wants a "good language" can write their code in >>Ada. I will write mine in C. >> > >Ada is a much better language in C, I'll give you that. And I would prefer Ada >over C++ in most cases. Though, templates of C++ are far more powerful than >generics of Ada. Look at the Booch components. In Ada they were 125.000 lines, >in C++ they were 10.000 lines. Also, Alex Stepanov gave up implementing the STL >in Ada (his prefered language) and turned to C++. There are some real advantages >there. My ideal of a systems programming language (which we're talking about >here) would be the basics of Ada (basic language features, syntax etc.) with the >C++ OO model and templates, or in fact, a full generic programming language >subset. And skip the built concurrency model, since it is too restrictive for >many different tasks. >As things are today, I would go with C++. If someone forced me to go with Ada, I >wouldn't cry. If someone forced me to go with C, I would. A lot. I must confess that I do not particularly like Ada or Java. I prefer C++ templates to Ada generics, though I prefer the block structure of Ada generics. My problem with Java is that it has no unsigned types, does not permit procedural code, and I do not like its exception mechanism. (I will save my compelling arguments as I feel they are OT here.) The power of abstraction can be nice, but in the case of inheritance and templates, it can often cost more than it is worth in a computationally-intensive program. Multiple inheritance is difficult to implement, and complex templates can be extremely difficult to get right. Truthfully, I do not find any language really to my liking, though perl is my favorite for small projects. As a side project, I've spent the last month working on a compiler that has most of the semantics of C/C++, but the goal is to (1) implement a method to abstract machine details within C-like constructs, (2) allow for optimization beyond what can currently be achieved, and (3) implement type safety in excess of what popular languages currently implement. I can make guarantees about bounds of variables and validity of any memory access regardless of pointer arithmetic. In short, I do not believe any C-like language currently offers what it SHOULD, and I intend to implement a compiler that addresses that. -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.