Performance question

[Sven]

I assume all programmers in this forum are aware of the difference between these two statements:

A. "It is correct to use this construct" (i.e. conforms to standard, is portable)

B. "It is recommended to use this construct" (i.e. good style, has no drawbacks).

In the given case, A is clearly true. In C, all expressions of the form "a OP b" where OP is a comparison operator have always been evaluated to either numerical 0 or 1, and the type of the comparison expression has always been "int". In C++, nowadays these expressions are of type "bool" (but in the beginning there were compilers, even MSVC++ 6.0, where the type was "int" in contradiction to the standard) and the numerical value is the same (0 or 1). So yes, you *can* make use of it in expressions like "c += (a == b)".

But B is a matter of taste. I would never write such code although it is correct, simply because it is not necessary to use this kind of "obfuscation". The simple "if (a == b) c++" is easy to understand for everyone and has zero drawbacks (I know, the original question was which of the two ways would be faster but I think it has been clarified that usually there is no substantial difference today), so why should we think outside the box?

If someone really wants to use it while keeping it readable then he or she should write this (C++ only): "c += int(a == b)". The explicit type conversion of the boolean (a == b) to "int" shows the intention of the programmer without generating different code.

Sven

[Don]

It's a matter of style, but for me I find that less code is almost always less obfuscation within reason. Of course this can be taken to ridiculous extremes but as a general rule this is true for me.

It's my belief that what seems obfuscated is more about what you are used to than anything else.

For instance I have seen language advocates show examples of how their favorite language is simpler and cleaner and when I look at the examples I don't agree - but I understand that it's just because it's not something I am used to looking at. I know that if I was intimate with the language I would probably agree.

I find this:

val = array[ a == b ];

less obfuscated than

if (a == b)
val = array[1];
else
val = array[0];

Probably only for the reason that it is less to parse. On top of that, many would argue that there should be extra braces around the assignments just for "clarity":

if (a == b)
{
val = array[1];
}
else
{
val = array[2];
}

To me the following is by far more pleasing:

val = array[ a == b ];

and because it's easier on the eye (at least for me) I consider it more readable.

I assume all programmers in this forum are aware of the difference between these two statements:

A. "It is correct to use this construct" (i.e. conforms to standard, is portable)

B. "It is recommended to use this construct" (i.e. good style, has no drawbacks).

In the given case, A is clearly true. In C, all expressions of the form "a OP b" where OP is a comparison operator have always been evaluated to either numerical 0 or 1, and the type of the comparison expression has always been "int". In C++, nowadays these expressions are of type "bool" (but in the beginning there were compilers, even MSVC++ 6.0, where the type was "int" in contradiction to the standard) and the numerical value is the same (0 or 1). So yes, you *can* make use of it in expressions like "c += (a == b)".

But B is a matter of taste. I would never write such code although it is correct, simply because it is not necessary to use this kind of "obfuscation". The simple "if (a == b) c++" is easy to understand for everyone and has zero drawbacks (I know, the original question was which of the two ways would be faster but I think it has been clarified that usually there is no substantial difference today), so why should we think outside the box?

If someone really wants to use it while keeping it readable then he or she should write this (C++ only): "c += int(a == b)". The explicit type conversion of the boolean (a == b) to "int" shows the intention of the programmer without generating different code.

Sven

[michiguel]

It's a matter of style, but for me I find that less code is almost always less obfuscation within reason. Of course this can be taken to ridiculous extremes but as a general rule this is true for me.

It's my belief that what seems obfuscated is more about what you are used to than anything else.

For instance I have seen language advocates show examples of how their favorite language is simpler and cleaner and when I look at the examples I don't agree - but I understand that it's just because it's not something I am used to looking at. I know that if I was intimate with the language I would probably agree.

I find this:

val = array[ a == b ];

less obfuscated than

if (a == b)
val = array[1];
else
val = array[0];

Probably only for the reason that it is less to parse. On top of that, many would argue that there should be extra braces around the assignments just for "clarity":

if (a == b)
{
val = array[1];
}
else
{
val = array[2];
}

To me the following is by far more pleasing:

val = array[ a == b ];

and because it's easier on the eye (at least for me) I consider it more readable.

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

I assume all programmers in this forum are aware of the difference between these two statements:

A. "It is correct to use this construct" (i.e. conforms to standard, is portable)

B. "It is recommended to use this construct" (i.e. good style, has no drawbacks).

In the given case, A is clearly true. In C, all expressions of the form "a OP b" where OP is a comparison operator have always been evaluated to either numerical 0 or 1, and the type of the comparison expression has always been "int". In C++, nowadays these expressions are of type "bool" (but in the beginning there were compilers, even MSVC++ 6.0, where the type was "int" in contradiction to the standard) and the numerical value is the same (0 or 1). So yes, you *can* make use of it in expressions like "c += (a == b)".

But B is a matter of taste. I would never write such code although it is correct, simply because it is not necessary to use this kind of "obfuscation". The simple "if (a == b) c++" is easy to understand for everyone and has zero drawbacks (I know, the original question was which of the two ways would be faster but I think it has been clarified that usually there is no substantial difference today), so why should we think outside the box?

If someone really wants to use it while keeping it readable then he or she should write this (C++ only): "c += int(a == b)". The explicit type conversion of the boolean (a == b) to "int" shows the intention of the programmer without generating different code.

Sven

[MattieShoes]

What about

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

Still one line but perhaps more human readable.

[michiguel]

What about

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

Still one line but perhaps more human readable.

You can always use every loophole of C. This two versions are perfectly legal. They even compile without warnings in GCC:

v = (a==b? 1: 0) [array];

v = (a==b) [array];

Miguel

[Aaron Becker]

We also have this option:

v = *((a == b) + array);

Just be glad it's not perl. I imagine somewhere out there there's a fully functional one-liner perl chess engine, and the code is 90% punctuation marks.

[Don]

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.


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.

[mcostalba]

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.

[Don]

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.

If it's silly it's because someone takes something that is purely a matter of personal taste, as you say and because they don't like it they construct arguments that imply it's incorrect or somehow impure. I guess I feel compelled to come to the aid against people who criticize programming style on these kinds of grounds.

But did you notice that in these kinds of discussions there is inevitably someone who will produce the same lecture you just gave. Did you cut and paste this from some language war forum and just change a few words around or something?

[mcostalba]

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