Author: Gerd Isenberg
Date: 03:41:13 01/06/06
Go up one level in this thread
On January 06, 2006 at 05:10:44, Tony Werten wrote:
>On January 06, 2006 at 03:37:17, Gerd Isenberg wrote:
>
>>On January 05, 2006 at 18:33:58, Alexander Kure wrote:
>>
>>>On January 05, 2006 at 13:04:29, Mathieu Pagé wrote:
>>>
>>>>Hi, I want to push OO to it's limit in order to get cleaner code. Here is what I
>>>>want to do :
>>>>
>>>>
>>>>class CSquare
>>>> {
>>>> private:
>>>> unsigned int m_uiSquareIndex;
>>>> public :
>>>> // the next 3 functions allow CSquare to be used as an unsigned int in
>>>> // arithmetic operations.
>>>> inline CSquare(unsigned int);
>>>> inline CSquare operator=(unsigned int);
>>>> inline operator unsigned int();
>>>>
>>>> // The next 2 functions are why i'd like to use OOP to make the
>>>>manipulation
>>>> // of squares clearer.
>>>> unsigned int GetColumn()
>>>> {
>>>> return m_uiSquareIndex % 8;
>>>> };
>>>>
>>>> unsigned int GetRow()
>>>> {
>>>> return m_uiSquareIndex / 8;
>>>> };
>>>> };
>>>>
>>>>
>>>>This way I can use CSquare like this :
>>>>
>>>>
>>>>CSquare csq(A1)
>>>>csq += 8; // One row higher. csq is now equat to A2.
>>>>csq.GetRow(); // Will return 1 (0 based index)
>>>>csq.GetColumn(); // will return 0
>>>>
>>>>
>>>>
>>>>I think that with basic compiler optimisations like inlining this code will
>>>>bring no overhead in my engine. I already asked some friends about it and they
>>>>seem to think like me, but are not sure.
>>>>
>>>>Since it's CC related and there is some good programmers monitoring this board I
>>>>though I would ask here.
>>>>
>>>>What is your opinion about this?
>>>>
>>>>Mathieu Pagé
>>>
>>>
>>>Hi Mathieu,
>>>
>>>Following are a few suggestions:
>>>
>>>1) You should declare the following functions const:
>>>
>>> operator unsigned int() const;
>>> unsigned int GetColumn() const;
>>> unsigned int GetRow() const;
>>>
>>>2) An additional constructor would be convenient:
>>>
>>> CSquare(unsigned int file, unsigned int row);
>>>
>>>Then you would need another conversion function:
>>>
>>> unsigned int ToSquare(unsigned int file, unsigned int row) const;
>>>
>>>3) Instead of low-levely maipulating a square by means of operator+=() you could
>>>declare the following high-level functions in class CSquare:
>>>
>>> void Up();
>>> void Down();
>>> void Left();
>>> void Right();
>>> void Next();
>>> void Previous();
>>
>>Isn't it better to return a reference for this functions, to cascade several
>>directions in one expression? What about throwing an out of board exception?
>>
>>
>>>
>>>4) You could also declare other convenient functions outside of class CSquare:
>>>
>>> bool IsAdjacent(const CSquare&, const CSquare&);
>>
>>while polymorphism is a nice thing to have, this function may also be member of
>>CSquare.
>>
>>try
>>{
>> if ( sq1.right().down().isAdjacent(sq2) )
>> ....
>>}
>>catch (OutOfBoardException e)
>>{
>> printf ("oups %s", e.getErrorString());
>>}
>>
>>;-)
>
>The question was: "is there overhead in OO ? "
"Is there overhead in _this_ OO design", aka wrapping a scalar.
Most likely not.
>
>Whenever you use a try .. catch : YES :)
Not necessarily - try catch is not a pure oo-feature.
It should simplify control structure - saving some "ifs" in a chain of
subroutines where some may cause exceptions, specially in recursive functions.
One if-throw - unwinding the stack and performing a long jump intead of lot of
returns and ifs.
My "didactical" sample was a bit ironic - but what is the desired behaviour of
sq.down().left() if sq is A1?
Gerd
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.