I think the point Swiftcoder is driving at is that bool->int, and int->bool conversion only makes (some kind of) sense inside of C's kind-of-insane interpretation of any non-zero integral type as true. I mean, it might be a neat party trick, but what would we really benefit by being able to multiply some integer by a boolean value? There's no actual relationship between the two types, except for the arbitrary rule that was applied.

Only in C and C++? If I recall correctly that was a common trait of the languages of the era. This was the reason why Pascal used := for assignment and not =, if I remember (= was used for conditions instead).

The reason for making it an expression was to allow stuff like x = y = z... I'm not sure that got much use in practice. Probably more used was to do an assignment within a condition and then check if the assigned value is true or not (which made sense especially with pointers, since null pointers evaluate to false, so this'd save a sentence).

But yeah, it'd be better if this was never allowed for starters.

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

Okay, this is scary, but I think that actually might work and be rather readable... Assuming you could set it up to automatically add white-space so the open/close for the outer level is always to the right of the open/close of the nested inner set.

Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

The one I dislike is the start btrace at the end of the if test and the
other hanging out by itself at the end of the block
if (x & y & funcz(a)) {
// do shirt here
}

My usual syntax Ive used :
if (x & y & funcz(a))
{
//do shirt here --- note triple blank indent
}
when its not a single statement in the if-true code block
I will do if () plus single statement (and align them).... when they are simple
if (x < 0 ) x = 0;
else if (x > maxx) x = maxx;
if (y < 0 ) y = 0;
else if ( y > maxy) y = maxy;
I also add extra blanks in many places to make the code less of a run together clustercluck and even split and align if clauses
(funny I usually dont do some for simple 'for' control clauses)
if ((test1() == 3) &&
(test2() == 4) &&
(test3() == 7))
{
// do shirt
}
Im also liberal adding blank lines particularly around For loops to accentuate their groupings
comments I dont mind being on the same line as code
for (o=0; o<maxi; o++) // loop thru all objects
{
object[o].x = tx;
object[o].y = ty;
// etc....
}
Ive rarely ever use the ? : statement form as they disappear in clutter making it hard to visually scan code
//-------------------------------------------------------------------------
and I use lines like this between EVERY function definition to help spot the startpoints (again speeds up visually scanning code )

Edited by wodinoneeye, 19 August 2013 - 07:01 AM.

--------------------------------------------Ratings are Opinion, not Fact

For the record, I know at least one language where it is indeed the case (it only pays attention to the lowest bit instead of the whole value).

But it wouldn't be bitwise anymore, then, right?

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.