I apologise for not being a very experienced C++ programmer. I have following comment:
When some early lines of code looks like this:
define div4(i) (i>>2)
define div2(i) (i>>1)
define NCELL 10
define NPIECE ((NCELL*NCELL)+1)
define BOARDSIZE (NCELL+2)
define NCOLOR 23
PRIVATE int parity[NCOLOR] ;
define PIECEPOSSIBLE (4*NPIECE)
PRIVATE int npiece ;
PRIVATE int n[PIECEPOSSIBLE],e[PIECEPOSSIBLE],s[PIECEPOSSIBLE],o[PIECEPOSSIBLE];
PRIVATE int x[PIECEPOSSIBLE],y[PIECEPOSSIBLE],pk[PIECEPOSSIBLE] ;
it appears that the vector "parity[NCOLOR]" shares the same space as variable "n[PIECEPOSSIBLE]".
It took me days of debugging to realise that.
Is it me who has overlooked something simple?
If I code the same lines like this:
define div4(i) (i>>2)
define div2(i) (i>>1)
define NCELL 10
define NPIECE ((NCELL*NCELL)+1)
define BOARDSIZE (NCELL+2)
define NCOLOR 23
define PIECEPOSSIBLE (4*NPIECE)
PRIVATE int npiece ;
PRIVATE int n[PIECEPOSSIBLE],e[PIECEPOSSIBLE],s[PIECEPOSSIBLE],o[PIECEPOSSIBLE];
PRIVATE int x[PIECEPOSSIBLE],y[PIECEPOSSIBLE],pk[PIECEPOSSIBLE] ;
PRIVATE int parity[NCOLOR] ;
I do not have that problem.
To me it looks like a compiler error. Can/should I report it to somebody? Whom?
Regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-10-03
Almost certainly a buffer overrun somewhere. By declaring parity[] later, the overrun may be 'benign', but it is still there! As I suggested this is teh kind of bug where just posting code-fragments is unlikely to help. The true error may still be not where you are looking and you are merely observing the result of some earlier error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-29
>> it appears that the vector "parity[NCOLOR]" shares the same space as variable "n[PIECEPOSSIBLE]".
How have you come to that conclusion?
>> To me it looks like a compiler error.
Most unlikely - the conclusion of last resort, and then only if you really know what you are talking about!
>> Can/should I report it to somebody?
Yes / No not yet at least until you have someone reproduce and confirm your findings. But it is more likley that it will be your error.
>>Whom?
The relevant GNU project, but not yet if at all.
The little bit of code you have posted shows a possibly unrelated dangerous practice. You should have:
define div4(i) ((i)>>2)
define div2(i) ((i)>>1)
The argument 'i' may not be a simple variable but an expression involving multiple variables, constants, and operators. Because macros are simply textual replacement, not having the parentheses around the expression could potentially produce unintended results due to operator precedence. But don't kid yourself that you are doing some clever hand optimisation here; the GNU compiler is smart enough to implement integer division (or multiplication) by a constant power of 2 using shift operations, so the more intuitive i / 2 directly in the code will be equally efficient. It does this even without optimisation enabled.
I suspect that the problem is not with the lines you have posted but elsewhere in your code. Start by inspecting the addresses of the individual variables, both at the start of your program and after you observe the error behaviour (whatever that is).
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Clifford.
I shall certainly implement your suggestions post haste.
The reason I suspect sharing of memory between the two variables is, that as a last resort I decided to print out almost everything at a stage in the program just before the real "serious business" commenced, and I then discovered that the first places of the vector 'n' did not contain what they were supposed to.
After a while I was able to narrow to a change in those variables happening when I made the "div2()" operation on the elements of 'parity', which made me suspect some kind of variable overlap in memory.
The line modifying 'parity' is:
for (i=0 ; i<=sizeof(parity) ; i++) { parity[i] = div2(parity[i]) ; }
When I declare 'parity' later than 'n' then I do not seem to have that problem (but probably some others).
I realise that I should have mentioned that 'PRIVATE' was previously defined as 'static', and that the version of Dev-C++ is 4.9.9.2
Needless to say that I am basically playing around with a program originally written by somebody else!
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologise for not being a very experienced C++ programmer. I have following comment:
When some early lines of code looks like this:
define div4(i) (i>>2)
define div2(i) (i>>1)
define NCELL 10
define NPIECE ((NCELL*NCELL)+1)
define BOARDSIZE (NCELL+2)
define NCOLOR 23
PRIVATE int parity[NCOLOR] ;
define PIECEPOSSIBLE (4*NPIECE)
PRIVATE int npiece ;
PRIVATE int n[PIECEPOSSIBLE],e[PIECEPOSSIBLE],s[PIECEPOSSIBLE],o[PIECEPOSSIBLE];
PRIVATE int x[PIECEPOSSIBLE],y[PIECEPOSSIBLE],pk[PIECEPOSSIBLE] ;
it appears that the vector "parity[NCOLOR]" shares the same space as variable "n[PIECEPOSSIBLE]".
It took me days of debugging to realise that.
Is it me who has overlooked something simple?
If I code the same lines like this:
define div4(i) (i>>2)
define div2(i) (i>>1)
define NCELL 10
define NPIECE ((NCELL*NCELL)+1)
define BOARDSIZE (NCELL+2)
define NCOLOR 23
define PIECEPOSSIBLE (4*NPIECE)
PRIVATE int npiece ;
PRIVATE int n[PIECEPOSSIBLE],e[PIECEPOSSIBLE],s[PIECEPOSSIBLE],o[PIECEPOSSIBLE];
PRIVATE int x[PIECEPOSSIBLE],y[PIECEPOSSIBLE],pk[PIECEPOSSIBLE] ;
PRIVATE int parity[NCOLOR] ;
I do not have that problem.
To me it looks like a compiler error. Can/should I report it to somebody? Whom?
Regards,
D.
Almost certainly a buffer overrun somewhere. By declaring parity[] later, the overrun may be 'benign', but it is still there! As I suggested this is teh kind of bug where just posting code-fragments is unlikely to help. The true error may still be not where you are looking and you are merely observing the result of some earlier error.
>> it appears that the vector "parity[NCOLOR]" shares the same space as variable "n[PIECEPOSSIBLE]".
How have you come to that conclusion?
>> To me it looks like a compiler error.
Most unlikely - the conclusion of last resort, and then only if you really know what you are talking about!
>> Can/should I report it to somebody?
Yes / No not yet at least until you have someone reproduce and confirm your findings. But it is more likley that it will be your error.
>>Whom?
The relevant GNU project, but not yet if at all.
The little bit of code you have posted shows a possibly unrelated dangerous practice. You should have:
define div4(i) ((i)>>2)
define div2(i) ((i)>>1)
The argument 'i' may not be a simple variable but an expression involving multiple variables, constants, and operators. Because macros are simply textual replacement, not having the parentheses around the expression could potentially produce unintended results due to operator precedence. But don't kid yourself that you are doing some clever hand optimisation here; the GNU compiler is smart enough to implement integer division (or multiplication) by a constant power of 2 using shift operations, so the more intuitive i / 2 directly in the code will be equally efficient. It does this even without optimisation enabled.
I suspect that the problem is not with the lines you have posted but elsewhere in your code. Start by inspecting the addresses of the individual variables, both at the start of your program and after you observe the error behaviour (whatever that is).
Clifford
Thanks Clifford.
I shall certainly implement your suggestions post haste.
The reason I suspect sharing of memory between the two variables is, that as a last resort I decided to print out almost everything at a stage in the program just before the real "serious business" commenced, and I then discovered that the first places of the vector 'n' did not contain what they were supposed to.
After a while I was able to narrow to a change in those variables happening when I made the "div2()" operation on the elements of 'parity', which made me suspect some kind of variable overlap in memory.
The line modifying 'parity' is:
for (i=0 ; i<=sizeof(parity) ; i++) { parity[i] = div2(parity[i]) ; }
When I declare 'parity' later than 'n' then I do not seem to have that problem (but probably some others).
I realise that I should have mentioned that 'PRIVATE' was previously defined as 'static', and that the version of Dev-C++ is 4.9.9.2
Needless to say that I am basically playing around with a program originally written by somebody else!
D.