Computer Chess Club Archives


Search

Terms

Messages

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

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.