Performance question

[Don]

Did you cut and paste this from some language war forum and just change a few words around or something?

No I didn't. But please feel free to do it yourself at your wishes

I'm really a chat-bot that was fed dialogue from the language war forums.

[bob]

It is amazing how such a silly thread grew up to a lengthy discussion

I have read the posts and thought how this could be possible. What are the ingredients that make a thread like this to spawn for almost 30 replies ?

I have identified the following recipe:

1) Pick up an argument where almost everybody can say something

2) Let the argument be tightly coupled to personal tastes

3) Let the argument to be easily discussed with few lines / small examples so that anybody can add his 2 cents with a small effort

4) Let the argument be something everybody uses often and has done so for years so to have grown up a very personal understanding on how things should be done.


I think that's the reason why coding style threads are so successful among programmers.

Just to add fuel to the fire, this is _also_ the reason that it is essentially impossible for two _different_ programmers to write a similar algorithm and end up with identical blocks of code.

[michiguel]

If number of lines is important, then this is better

val = a == b? array[1]: array[0];

IMHO, the problem of "readability" is not the number of lines. It has to do with how clear is the intention of the programmer. When you do

val = array[ a == b ];

you are switching from a "boolean variable" to an integer. C may allow you this, but it is a hidden "cast". In the example above, you can tell that the programmer wanted, but in your example, you have to stop for a second and wonder. I think it is better to keep boolean logic and integers separate if there no strong reasons to mix them.

Miguel

Miguel,

In C the only data type that can be used as an index into an array is an integer. That is why programmers use high level abstractions. For example in my program I have arrays indexed by piece type, color, square, and other things like this. But C does not have these data type natively, we have to use integers to represent them if we want to use them as an index to an array.

That's right. I try to use a level of abstraction in which there is a boolean type, despite C89 does not have it. But if I use an abstract boolean type and then I do

Code: Select all

int a = (b == c);

I am breaking my own convention. That is all I am saying (unless I am using an explicit cast as you suggest below).

So why is it ok to use a "piece type" variable to index an array, but it's wrong to use a boolean variable? C does not have either.

C99 has it, but it looks like it is just like a typedef (I think). (a==b) returns an int type. However, correct me if I am wrong, c++ returns a boolean type rather than an int when you have (a==b). Sometimes C code needs to be shared in C++ environments and it portability could be maintained with minimal effort, that would be a plus.

If I do this:

x = array[a==b]

it should be pretty obvious that this is array that is indexed by a boolean value. If that is unreadable to you then you might see this as more readable:

Just for the record, it does not matter what is readable for me, I think what it matters is what is readable for the least common denominator when code needs to be shared.

x = array[ (int) (a==b) ];

to make it clear that you know that arrays in C must be indexed by integer values.

I agree, and that makes it compatible with C++ too (please a c++ programmer correct me if I am wrong).

But I think it's very unimaginative to pretend that a boolean variable cannot exist as an abstraction, but can only be used in "if" statements. I wonder how assert() is implemented, surely you must see this as a travesty too.

Yes, I believe that boolean could be abstracted and that is exactly what I do!
but then, they should be used as the abstraction was intended! (true and false values). Once I am convinced that true and false should be "abstracted", I cannot assumed that they have an equivalent value in another type (int in this case).

I do not understand what you mean by the assert(). BTW, I do see anything as a "travesty". I am very pragmatic. If I give the impression I am dogmatic with some made up rules, sorry. I was just trying to share my style.

"It is an old observation that the best writers sometimes disregard the rules of rhetoric. When they do so, however, the reader will usually find in the sentence some compensating merit, attained at the cost of the violation. Unless he is certain of doing as well, he will probably do best to follow the rules." Strunk and White, in the famous "The Elements of Style"
http://www.literaryagents.com/gettingpublished.html

I do not belong to "the best writers" category, at all.

Miguel

[Aaron Becker]

However, correct me if I am wrong, c++ returns a boolean type rather than an int when you have (a==b). Sometimes C code needs to be shared in C++ environments and it portability could be maintained with minimal effort, that would be a plus.

It's true that in C++, bools are their own type. However, the implicit type conversion rules guarantee that bool will be converted to other arithmetic types automatically, so using a bool as an array index will still work. I still think it's an abuse of the type system to use a bool as an array index without casting, but it will work just as well in C++ as in C.

[michiguel]

If number of lines is important, then this is better

val = a == b? array[1]: array[0];

IMHO, the problem of "readability" is not the number of lines. It has to do with how clear is the intention of the programmer. When you do

val = array[ a == b ];

you are switching from a "boolean variable" to an integer. C may allow you this, but it is a hidden "cast". In the example above, you can tell that the programmer wanted, but in your example, you have to stop for a second and wonder. I think it is better to keep boolean logic and integers separate if there no strong reasons to mix them.

Miguel

Miguel,

In C the only data type that can be used as an index into an array is an integer. That is why programmers use high level abstractions. For example in my program I have arrays indexed by piece type, color, square, and other things like this. But C does not have these data type natively, we have to use integers to represent them if we want to use them as an index to an array.

So why is it ok to use a "piece type" variable to index an array, but it's wrong to use a boolean variable? C does not have either.

I realize I did not answer in the other post why a piece type is ok (for me) to index an array. Piece types are enumerated, which intrinsically are integer in nature and generally are not product of arithmetic operations. The tricky part is that once the abstraction is set, it would be very easy to forget that a boolean variable could hold a value that is not 0 or 1. We were proven wrong that a==b returns either 0 or 1, but an abstracted "boolean" variable could easily hold different values.

you start with:

Code: Select all

if (z == ' ') {
	somecode();
}
...
a += array [z == ' '];
b += array [z == ' '];

The someone else optimize it to

Code: Select all

z_is_space = z == ' ';
if (z_is_space) {
	somecode();
}
...
a += array [z_is_space];
b += array [z_is_space];

Then the code is generalized to

Code: Select all

z_is_space = z == ' ' || z == '\t' || z == '\n' || z == '\v || z == '\f' ;
if (z_is_space) {
	somecode();
}
...
a += array [z_is_space];
b += array [z_is_space];

And at this point someone decides to use a standard library function instead and a bug is introduced because a true value returned by a standard library function is non-zero, not necessarily 1 (that was the origin of my initial confusion, I guess).

Code: Select all

z_is_space = isspace(z) ;
if (z_is_space) {
	somecode();
}
...
a += array [z_is_space];
b += array [z_is_space];

Miguel

If I do this:

x = array[a==b]

it should be pretty obvious that this is array that is indexed by a boolean value. If that is unreadable to you then you might see this as more readable:

x = array[ (int) (a==b) ];

to make it clear that you know that arrays in C must be indexed by integer values.

But I think it's very unimaginative to pretend that a boolean variable cannot exist as an abstraction, but can only be used in "if" statements. I wonder how assert() is implemented, surely you must see this as a travesty too.

[bob]

However, correct me if I am wrong, c++ returns a boolean type rather than an int when you have (a==b). Sometimes C code needs to be shared in C++ environments and it portability could be maintained with minimal effort, that would be a plus.

It's true that in C++, bools are their own type. However, the implicit type conversion rules guarantee that bool will be converted to other arithmetic types automatically, so using a bool as an array index will still work. I still think it's an abuse of the type system to use a bool as an array index without casting, but it will work just as well in C++ as in C.

My take on this is a bit different after having worked on a chess program for 41+ years now. That is, I use what is best for "me". I like short code, code that is easy for me to read/understand. I don't write for others at all, I write so that I can understand what I did, when I need to modify the code. Since there is no native "boolean" type on today's computers, whether you use an int, a char, or whatever, makes no difference to me so long as the semantics are clear and unambiguous. For example, I never use "if (a = b)" If that is really what I want to do, I would use a=b; if(a); since that is more intuitive and is harder to misinterpret when reading thru code quickly...