compiler dependent scores!

[jswaff]

Hi James,
I had something very similar when I switched to Linux. Ubuntu didn't install the gcc compiler by default and I had to do that manually. Somehow I suceeded in installing the wrong package for my system. I was able to compile but compiles with -O2 resulted in odd evaluation scores very much like yours. There was no problem when using no optimization or -O3. Compiles with the intel compiler resulted in segfaults as the intel compilers seems to rely on libs/headers from gcc. Installing the right gcc package solved all the problems.

Maybe you could check if you have the right compiler package and the proper libs and headers for your system.

best regards
Roman

I have.. I think we're way past that. At this point I'm pretty sure it is a compiler (optimizer) bug after all, triggered perhaps by a redundant break condition in the construct of the for loop (as Gerd pointed out).

--
James

[bob]

We are still hung up in semantics...

I do not believe that "for (int i = etc...)" would be considered "best practice" by the majority of people that develop/support large systems. It makes the program significantly harder to read.

Again, this is not a comment about scope, it is about readability. I would prefer this:


{
int i;
for (i=......)
}

to

for (int i.....)

because now the scope of I is clearly visible, not buried inside an instrcution intended for looping.

So that was my only quibble with this. It is about readability, not about scope...

Ok, Mr. Hyatt. When we talk about "best practice", can you name me one book about C++, where the loop iterators are not declared in the for statement? Because that is how young people learn it and get used too.

Harder to read sounds more like C programmers that switch to C++ and just don't like it.

I've programmed in C and C++ for years. And Fortran. And PL/1. And Algol. And Pascal. And Lisp. And Ada. And basic. And APL. And COBOL. And assembler for a dozen platforms. So I have seen it done in lots of ways. from FORTRAN's implicit typing/declarations which lead to difficult-to-find errors since nothing has to be declared, to PASCAL where things are so tightly defined it is difficult to use.

You might be right that my comment comes from a _lot_ of prior experience. But, there is absolutely nothing that says that this "new method of declaration" is better. Particularly from a readability perspective. If you like it, that's fine. I've been around the block enough times that I prefer that which is simplest, most direct, and least likely to introduce unexpected errors. The C/C++ standards are not exactly brilliant, otherwise we would have a standard way of declaring variables of a specific size, and every declaration would leave no "left to the implementor" type aspects (is char x signed or unsigned? Standard does not specify, where "int x" is always signed unless overridden.

So change is not always for the better. And for large programs, readability is paramount...

[Bo Persson]

Which one is easier to read? that is what I don't like about the

for (int i=0; i<n; i++)

syntax. that "int i" is buried inside a common statement and it is easy to overlook the fact that i is local to the loop only, and if you modify i inside the loop, or break out of the loop, the value of i that is left is not the one from the loop counter, it is the i that has greater scope.

It's generally a bad idea to try to use a loop counter outside the loop anyway. IIRC the value of the loop counter when you exit the loop is undefined.

Heavens no, and thank goodness the days of FORTRAN are gone. Loops like this exist in every program I have looked at:

For (i=0; i<x ;i++)
if (a < 0) break;

And then use i which points to the first element of a that is < 0...

This might be clear programming for CSauriers ... (Hmm, how come a lot of people consider Crafty hard to read )

Nowadays something like does is more common/considered more readable. (ie split iterator and found location variable)

Tony

I believe it really *is* a difference in culture. For those of us that have used C++ for a long time, without a heavy C background, it is just as confusing as it is for Bob - but in the opposite direction.

If you are used to almost always have the loop counter (or iterator!) declared inside the for statement, it is equally confusing when it is not. There are several other little differences as well, between

for (i=0; i<x ;i++)

and

for (int i=0; i != x; ++i)

C and C++ really *are* two different languages. If you try to read Crafty as C++, it is a bit hard to read, because it is written in C.

[Gerd Isenberg]

I believe it really *is* a difference in culture. For those of us that have used C++ for a long time, without a heavy C background, it is just as confusing as it is for Bob - but in the opposite direction.

If you are used to almost always have the loop counter (or iterator!) declared inside the for statement, it is equally confusing when it is not. There are several other little differences as well, between

for (i=0; i<x ;i++)

and

for (int i=0; i != x; ++i)

C and C++ really *are* two different languages. If you try to read Crafty as C++, it is a bit hard to read, because it is written in C.

I think C versus C++ is not the issue here, but whether this C++ feature is dubios or not.
Is this correct?

Code: Select all

void foo() {
   for (int sq=0; sq < 64; sq++) {...}
   for (int sq=0; sq < 64; sq++) {...}
}

Or this?

Code: Select all

void foo() {
   for (int sq=0; sq < 64; sq++) {...}
   for (sq=0; sq < 64; sq++) {...}
}

It may depend on the c++ compiler. In such cases - like Bob - I prefere the C style if I use multiple loops with the same iterator. To keep the iterator pattern consistant, it is fine to use it don't matter how many loops with same iterator occur.

Code: Select all

void foo() {
   int sq;
   for (sq=0; sq < 64; sq++) {...}
   for (sq=0; sq < 64; sq++) {...}
}

I pragmatically like the convenient on the fly declaration in small routines with one simple loop. But as Bob mentioned, one should be aware of the "undefined" or compiler dependent scope outside the loop.

Code: Select all

// return: 0..63 if square found, otherwise 64
int firstSquareOfPiece(int* board, int piece) {
   for (int sq=0; sq < 64; sq++)
      if ( board[sq] == piece ) break;
   return sq;  // hmmm
}

int firstSquareOfPiece(int* board, int piece) {
   for (int sq=0; sq < 64; sq++)
      if ( board[sq] == piece ) return sq;
   return 64;
}

int firstSquareOfPiece(int* board, int piece) {
   int sq = 0;
   for (;sq < 64; sq++)
      if ( board[sq] == piece ) break;
   return sq;
}

[Guetti]

I believe it really *is* a difference in culture. For those of us that have used C++ for a long time, without a heavy C background, it is just as confusing as it is for Bob - but in the opposite direction.

If you are used to almost always have the loop counter (or iterator!) declared inside the for statement, it is equally confusing when it is not. There are several other little differences as well, between

for (i=0; i<x ;i++)

and

for (int i=0; i != x; ++i)

C and C++ really *are* two different languages. If you try to read Crafty as C++, it is a bit hard to read, because it is written in C.

I think C versus C++ is not the issue here, but whether this C++ feature is dubios or not.
Is this correct?

Code: Select all

void foo() {
   for (int sq=0; sq < 64; sq++) {...}
   for (int sq=0; sq < 64; sq++) {...}
}

??? OMG!
Of course this is correct!! Any compiler saying otherwise has a bug!
The iterator declared in the for loop is only valid in the body of the loop. The body may or may not be encapsulated with braces. There is no difference in C or C++. This is about scope.
I use always int i for the iterator, with the exception of encapsulated loops.

Or this?

Code: Select all

void foo() {
   for (int sq=0; sq < 64; sq++) {...}
   for (sq=0; sq < 64; sq++) {...}
}

Here you use a variable that was never declared in that scope!!
No compiler (hopefully) will even compile that code!

It may depend on the c++ compiler. In such cases - like Bob - I prefere the C style if I use multiple loops with the same iterator. To keep the iterator pattern consistant, it is fine to use it don't matter how many loops with same iterator occur.

Code: Select all

void foo() {
   int sq;
   for (sq=0; sq < 64; sq++) {...}
   for (sq=0; sq < 64; sq++) {...}
}

I pragmatically like the convenient on the fly declaration in small routines with one simple loop. But as Bob mentioned, one should be aware of the "undefined" or compiler dependent scope outside the loop.

Code: Select all

// return: 0..63 if square found, otherwise 64
int firstSquareOfPiece(int* board, int piece) {
   for (int sq=0; sq < 64; sq++)
      if ( board[sq] == piece ) break;
   return sq;  // hmmm
}

int firstSquareOfPiece(int* board, int piece) {
   for (int sq=0; sq < 64; sq++)
      if ( board[sq] == piece ) return sq;
   return 64;
}

int firstSquareOfPiece(int* board, int piece) {
   int sq = 0;
   for (;sq < 64; sq++)
      if ( board[sq] == piece ) break;
   return sq;
}

[Gerd Isenberg]

The old msvc6 compiler...

Code: Select all

void testBitScanReverse()
{
	BitBoard one = 1;
	BitBoard bb = -1;
	for (int n = 1; bb; n++) {
		int i = bitScan(bb, n&1);
		//int i = bitScanReverse(bb);
		printf("%2d ", i);
		bb ^= one << i;
		if ( (n&7) == 0)
			printf("\n");
	}
	bb = -1;
	for (int n = 1; bb; n++) {
		int i = bitScanReverse(bb);
		printf("%2d ", i);
		bb ^= one << i;
		if ( (n&7) == 0)
			printf("\n");
	}
}

c:\source\bitscan\bitscan.cpp(448) : error C2374: 'n' : redefinition; multiple initialization
c:\source\bitscan\bitscan.cpp(439) : see declaration of 'n'

[Guetti]

Ok, anscheinend geht's nicht in C.

gcc -c test.c

test.c: In function 'testBitScanReverse':
test.c:10: error: 'for' loop initial declaration used outside C99 mode
test.c:19: error: redefinition of 'n'
test.c:10: error: previous definition of 'n' was here
test.c:19: error: 'for' loop initial declaration used outside C99 mode

[Gerd Isenberg]

Ok, anscheinend geht's nicht in C.

gcc -c test.c

test.c:14: error: 'for' loop initial declaration used outside C99 mode

May be, but msvc6 was explicitly C++, obviously not C++ standard.

[Guetti]

Ok, anscheinend geht's nicht in C.

gcc -c test.c

test.c:14: error: 'for' loop initial declaration used outside C99 mode

May be, but msvc6 was explicitly C++, obviously not C++ standard.

Then I would only prod it with a long stick.

[Alessandro Scotti]

MSVC 6 is 10 years old though, and based on pre-standard C++ specifications. It's probably not the safest way to test code compliance.