Author: David Rasmussen
Date: 03:05:39 12/25/02
Go up one level in this thread
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. >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. >>>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. >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. >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 >>>can implement my OO in C, and it simplifies linking because C doesn't have name >>>mangling. >>> >> >>Is that an issue? It hasn't been an issue for me at all. >> >>/David > >It's a pain to mix with assembly, C, and other languages. It's also a pain to >put in a DLL/shared object and use in other applications. > How is it a pain? I've never had problems with that. /David
This page took 0.04 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.