Computer Chess Club Archives




Subject: Re: C and C++ --- NPS

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.

>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

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.

>>>can implement my OO in C, and it simplifies linking because C doesn't have name
>>Is that an issue? It hasn't been an issue for me at all.
>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.


This page took 0.02 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.