Object vs structural programming in chess.

[Hood]

Hello,

just one question are chess more fitting to the structural or object programming ?

Rgds
Hood

[lmader]

I think it's largely a matter of taste.

Personally I think all programming should be "object oriented", and I much prefer the C++ language to C. But this is only my preference.

Some people prefer C to C++, because if you don't know what you are doing, some C++ constructs can negatively affect both performance and code size - specifically, C++ exception handling impacts performance (don't have to use it though), run-time type identification (RTTI) does too though almost always can (and should) be avoided. C++ classes that use virtual methods impose an extra look-up for function calls, but again, this too can be avoided by not using virtual methods and you still gain the benefit of the structural organization provided by the C++ class construct. Some C++ compilers have better optimizations for the C++ language than C, but that depends on the compiler.

[humble_programmer]

On the whole, I agree with much of Lar's posting, but the choice of object vs. structural design is often based more on philosophy than a hard and fast ruleset.

Speaking for myself (and at great risk of inflaming the trolls) I tend to gravitate towards structural languages--such as C or Assembler--when I perceive that performance is going to be a major factor. While object-oriented features like encapsulation and inheritance can help make developers create more elegant designs, they do carry a measurable overhead. On the other hand, the 'bare metal coding' approach will typically yield the fastest code, but places the burden of translating a design into robust code squarely on the developer's shoulders.

So: for code now that runs slower, use objects; for faster code later, use a structured language and test the hell out of it. It's your call...

[Hood]

Thank you for the answers.

I have wondered that language of programming will have to correspond to the chess nature may be it shall be specialized language.

When there is the analysing of position one of the important elements is analysing the functions (methods) pieces are performing in the position. It will point for structural programming but modeling the board and pieces themselves is for the object direction.

Object programming is designed for the big projects made by more then 1 programmer. Is the chess programm such a big design ?
It seems that engine and GUI parts are separable.

The mentioned performance overhead is important matter but from the other point there are (is) strong mobile chessprograms which are written
in Java.

rgds
Hood

[muxecoid]

I do not think that exception handling overhead is "bloat". If your application is performance critical you can disable them. In case of complex application that must handle everything gracefully C code without exceptions is likely to look like this:

Code: Select all

if (0==DoSomething())
{
 printerror("Something was wrong");
 goto cleanup;
}
if (0==DoSomethingElse())
{
 printerror("Something else was wrong");
 goto cleanup;
}

Exceptians are not only for bloat, exceptions replace something that is often done with ugly goto statement or even introduce the need for more complex code.

[Bo Persson]

On the whole, I agree with much of Lar's posting, but the choice of object vs. structural design is often based more on philosophy than a hard and fast ruleset.

Speaking for myself (and at great risk of inflaming the trolls) I tend to gravitate towards structural languages--such as C or Assembler--when I perceive that performance is going to be a major factor. While object-oriented features like encapsulation and inheritance can help make developers create more elegant designs, they do carry a measurable overhead. On the other hand, the 'bare metal coding' approach will typically yield the fastest code, but places the burden of translating a design into robust code squarely on the developer's shoulders.

So: for code now that runs slower, use objects; for faster code later, use a structured language and test the hell out of it. It's your call...

Good trolling.

How do you think "elegant designs" would lead to slower code? Encapsulation would rather lead to faster code and inheritance has no cost in itself. It is just a way of structuring your code.

[ilari]

How do you think "elegant designs" would lead to slower code? Encapsulation would rather lead to faster code and inheritance has no cost in itself. It is just a way of structuring your code.

But inheritance is rarely useful without runtime polymorphism, and virtual function calls have a higher cost than regular function calls. The cost of virtual functions is nothing compared to the cost of dynamic memory allocation though.

[lmader]

I do not think that exception handling overhead is "bloat". If your application is performance critical you can disable them. In case of complex application that must handle everything gracefully C code without exceptions is likely to look like this:

Code: Select all

if (0==DoSomething())
{
 printerror("Something was wrong");
 goto cleanup;
}
if (0==DoSomethingElse())
{
 printerror("Something else was wrong");
 goto cleanup;
}

Exceptians are not only for bloat, exceptions replace something that is often done with ugly goto statement or even introduce the need for more complex code.

Yes, there is no doubt that exception handling semantics are FAR more elegant than error code returns.

My point was to acknowledge that exception handling has a larger performance cost, because the compiler has to introduce extra code to handle the error branching and the stack unwind. I can appreciate that a chess programmer that wants to control every last CPU cycle would not be willing to accommodate that.

In the bigger picture, I was also pointing out that just because one is coding in C++ doesn't mean that you have to use all of the features of the C++ language, and that exception handling is one to be careful with from a performance standpoint.

[Bo Persson]

I do not think that exception handling overhead is "bloat". If your application is performance critical you can disable them. In case of complex application that must handle everything gracefully C code without exceptions is likely to look like this:

Code: Select all

if (0==DoSomething())
{
 printerror("Something was wrong");
 goto cleanup;
}
if (0==DoSomethingElse())
{
 printerror("Something else was wrong");
 goto cleanup;
}

Exceptians are not only for bloat, exceptions replace something that is often done with ugly goto statement or even introduce the need for more complex code.

Yes, there is no doubt that exception handling semantics are FAR more elegant than error code returns.

My point was to acknowledge that exception handling has a larger performance cost, because the compiler has to introduce extra code to handle the error branching and the stack unwind. I can appreciate that a chess programmer that wants to control every last CPU cycle would not be willing to accommodate that.

On the other hand, with newer compilers the exception handling is activated only when an exception is actually thrown. The return code checking is always present, and damages performance.

[Bo Persson]

How do you think "elegant designs" would lead to slower code? Encapsulation would rather lead to faster code and inheritance has no cost in itself. It is just a way of structuring your code.

But inheritance is rarely useful without runtime polymorphism, and virtual function calls have a higher cost than regular function calls. The cost of virtual functions is nothing compared to the cost of dynamic memory allocation though.

Right, so inheritance has no cost in itself.

If you use virtual functions where you would use function pointers in C, they might actually be cheaper because the use is limited, and the compiler knows about it.

Language war coming up...