Author: Uri Blass
Date: 13:00:00 02/22/03
Go up one level in this thread
On February 22, 2003 at 15:28:06, Dezhi Zhao wrote: >On February 22, 2003 at 02:54:40, Uri Blass wrote: > >>On February 21, 2003 at 15:59:25, Dezhi Zhao wrote: >> >>>On February 21, 2003 at 13:31:50, Uri Blass wrote: >>> >>>>On February 21, 2003 at 13:10:27, Dezhi Zhao wrote: >>>> >>>>>On February 21, 2003 at 12:48:45, Uri Blass wrote: >>>>> >>>>>>On February 21, 2003 at 11:15:24, Dezhi Zhao wrote: >>>>>> >>>>>>>On February 21, 2003 at 04:14:49, Uri Blass wrote: >>>>>>> >>>>>>>>On February 20, 2003 at 13:51:37, Filip Tvrzsky wrote: >>>>>>>> >>>>>>>>>On February 20, 2003 at 12:49:39, Uri Blass wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>I guess that you mean >>>>>>>>>>#define gen_dat_i_mpromote (gen_dat[i].m & (63 << 16)) >>>>>>>>>> >>>>>>>>>>I guess that the laternative that I tried >>>>>>>>>> >>>>>>>>>>#define to(x) (((x)>>8)&255) was also bad >>>>>>>>>>and better was >>>>>>>>>>#define to(x) (((x)&255<<8) >>>>>>>>>> >>>>>>>>>>I guess that in that case I need to change some more code >>>>>>>>>> >>>>>>>>>>For example >>>>>>>>>> >>>>>>>>>>I have today some cases when I have >>>>>>>>>>switch(m.bits) >>>>>>>>>>case 1: >>>>>>>>>>case 17: >>>>>>>>>>... >>>>>>>>>> >>>>>>>>>>in that case I need to say case 1<<24 and in order not to have an ugly code >>>>>>>>>>I need to have more constants for 2^24,2^24*17,... >>>>>>>>>> >>>>>>>>>>I can use >>>>>>>>>>enum >>>>>>>>>>{ >>>>>>>>>> bits1=16777216 >>>>>>>>>> bits17= >>>>>>>>>>... >>>>>>>>>>} >>>>>>>>>> >>>>>>>>>>Uri >>>>>>>>> >>>>>>>>>#define to(x) (((x)>>8)&255) is definitely worse than #define to(x) >>>>>>>>>(((x)&255<<8) because in the first case the shifting is done in run-time and in >>>>>>>>>the second during compilation. Note also that the result of both macros is >>>>>>>>>different. >>>>>>>> >>>>>>>>Yes >>>>>>>> >>>>>>>>This is an important note. >>>>>>>> >>>>>>>>I did not do the mistake of assuming that they are the same but I see that I >>>>>>>>have problems. >>>>>>>> >>>>>>>>I cannot use my usual macros after that translate >>>>>>>> >>>>>>>>for example >>>>>>>> >>>>>>>>I had if (piece(m.b.to))=PAWN) in my code >>>>>>>>I cannot transalate it to >>>>>>>>if (piece(to(m))==PAWN) because to(m) does not get something between 0 and 63 >>>>>>>>after the change and it seem that I cannot do it faster in this case. >>>>>>>> >>>>>>> >>>>>>>you probabaly need another inline function or micro here: >>>>>>> >>>>>>>#define IsPawn(move) (piece(move.b.to) == PAWN) >>>>>> >>>>>>note that piece() is not a function and it is in my defines >>>>>> >>>>>>#define piece(square) ((info[square])&7) >>>>>> >>>>>>The point is that info[64] include for every square both the color and both the >>>>>>piece and the piece can be accesed by the array info[64] that is an array of >>>>>>int. >>>>>> >>>>> >>>>>nested macroes are OK. >>>>> >>>>>>> >>>>>>>If you are using VC, inline functions are prefered. You can easily browse these >>>>>>>inline fuctions. And the compiler does type checking that is certainly helpful. >>>>>> >>>>>>I do not see a function that I should inline in that case because there is no >>>>>>function in the code that I posted(only macros). >>>>>> >>>>> >>>>>You missed the point that a inline function is the same in effect as a macro. >>>>>A inline function _is_ a much better macro. >>>> >>>>Thanks for the advice. >>>>I use visual C++ but >>>>I saved the files in my project as .c >>>>I guess that inline functions mean that I need to change the .c to .cpp first >>> >>>yes. a simple rename >> >>It is not so simple because I get errors from doing it >> >>hash_table = calloc(TableSize, sizeof( HASHE )); >> >>: error C2440: '=' : cannot convert from 'void *' to 'struct tagHASHE *' >> Conversion from 'void*' to pointer to non-'void' requires an explicit >>cast >>evaluate.cpp >> >>I get also warnings that I did not get in C >> >>warning C4390: ';' : empty controlled statement found; is this the intent? >> >>My reply Yes it is >>I ignore opponent time but I may use it in the future so I told my program to do >>nothing when it gets the opponent time from winboard. >> >>warning C4551: function call missing argument list >> >>At least I could fix that warning by changing >> >>input_available >>to >>input_available() >> >>Strange that I did not get the same warning in C. >> >>Uri > >These added warnings are good things in fact. C++ has some more tight type >checking. So you may consider changing those generating warnings, like this: > >hash_table = (tagHASHE*) calloc(TableSize, sizeof(HASHE)); > >or the C style: > >hash_table = (struct tagHASHE *) calloc(TableSize, sizeof(HASHE)); > >dzhao Thanks but I still have problems. I tried in my C files(I renamed them back to C) and got the following warnings warning C4047: 'function' : 'unsigned int ' differs in levels of indirection from 'struct tagHASHE *' warning C4024: 'calloc' : different types for formal and actual parameter 1 Note that TableSize is an integer and here is the relvant defintion in my program. typedef struct tagHASHE { __int64 key; unsigned int depth:7; unsigned int flags:2; signed int value:16; move best; } HASHE; Uri
This page took 0.01 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.