Beginner Exercises

[S6k9GNh0]

http://bytes.com/topic/c/answers/213334-while-1-a

Meh... I know SOME compilers generate different code but if there isn't a boolean to be checked, I always use for(;;) but I guess it really doesn't matter.

[DrChill]

I use while (true) when doing an infinite loop, which is virtually never.

[S6k9GNh0]

So you never poll for events or create any rendering programs? What do you make?

[chrisname]

I always use for (;;) too. Only a stupid compiler would compile while (1) to check 1 is true on every pass of a loop; but why take the risk?

[Disch]

As long as we're talking about stupid things compilers might do (but actually don't do)...

A compiler might put in nop's for the two semicolons in that for(;;) statement thus producing potentially larger code than while(1).

=P

I prefer while(1) because for(;;) breaks language convention/rationality. Well it doesn't really break convention, but it makes the language syntactically inconsistent.

Syntactcally:

while( condition )
if( condition )
for( initialization; condition; iteration )

Omitting the condition shouldn't be valid.

while() is not valid
if() is not valid
but somehow for(;;) is valid?

It's like C went out of its way to make an exception so that you could make your loops more obfuscated. (C++ probably had to just go along with it to be C compatible)

[helios]

I agree. It makes no sense.

Since we're talking about inconsistencies, I've always hated that each pointer declared needs the * in front of it to actually be a pointer.
T *a, b;
So b is not a pointer. Then by that logic, a pointer is not a type, but an attribute of a variable, and yet it's possible to cast to (T *)?

[Disch]

That's one of my pet peeves too. The * is logically part of the type, yet C/C++ don't treat it that way.

[firedraco]

while() is not valid
if() is not valid
but somehow for(;;) is valid?

Didn't notice that but...I agree. And T* a, b; should make a and b pointers...don't know why they couldn't have done that...

[chrisname]

I don't think so. I like that you have to explicitly state that a and b are pointers.

Think about it: T is a type. T* a or T *a means a is a pointer to T. T b, *a would mean that b is a variable of type T and a is a pointer to T. Plus then I can do this:

char* s  = NULL,
      c  = 0,
    * s1 = NULL;

[helios]

You're telling me it makes sense to you that the language lets you declare variables of different types in the same declaration statement, even though you can't do the same for any other type pair?

[gcampton]

Things like this annoy me too:

string Text = "456";//string containing the number
int Result;//number which will contain the result

stringstream convert(Text); // stringstream used for the conversion initialized with the contents of Text

if ( !(convert >> Result) )//give the value to Result using the characters in the string
    Result = 0;//if that fails set Result to 0
//Result now equal to 456  

This is a conditional yet using it this way, is performing an assignment. I mean sure it's handy, but realistically the assignment should not take place because it's like probing a question....but a question that happens to resolve itself.

As annoying as it is I wish java had the << >> operators :)

[S6k9GNh0]

gcampton, the >> is simply an operator function for your convenience. I don't think any of use would want that to go.

[Disch]

@ chrisname:

The thing is, T is a type, but T* is a different type.

Case in point, you can't do this:

int a;
int* b;

b = a;  // error, mismatching types 

Therefore, logically, the * is a part of the type (indicating the type is a pointer, rather than an int).

Taking that logic, let's examine the following declaration:

int a, b, c;

"int" is the type, and "a,b,c" are the variables you want of that type.

So logically... int* a,b,c; you would think "int*" is the type, and "a,b,c" are variables of that type, because that would be the most consistent.

But of course that's not how it works. IE: it's inconsistent.

typedef complicates things even more:

typedef int* intp;

int* a, b;  // not the same types
intp c, d;  // ?  are c and d the same type? 

To be honest, I didn't know the answer to the above until I tried it.

As it turns out... typedef behaves logically (intp is the type, therefore both c and d would be pointers). But it just goes to show you how inconsistent and crazy the whole pointer declaration thing is.

Plus then I can do this

I guess you got me there. But honestly I don't see why you'd ever want to do that.

[chrisname]

Ok, that's a good point.

[DrChill]

So you never poll for events or create any rendering programs? What do you make?

Perhaps you mis-understood me, I meant I never do this:

while(true){
     //do stuff
}

When I poll for events I do this:

bool quit = false;
while(!quit){
     if(event.type == QUIT){ //or whatever I use for the quiting (mainly SDL_QUIT(or something like that))
          quit = true;
     }
     //do stuff
}

much cleaner.

[S6k9GNh0]

It does give you a bit more functionality, but then again, it checks for that boolean every loop. That's why we aren't using that. :D

You'll noticed most emulators use for(;;) and most games use for(;;) although you'll find more modern games not really putting much thought into it whether it be while (1) or while(bCheckEverythingInTheProgramToMakeSureItsOkay())

[helios]

What kind of depravity makes someone use Hungarian notation for functions?

[Disch]

although you'll find more modern games not really putting much thought into it whether it be while (1)

If I'm reading this right... you're implying that the usage of while(1) is somehow due to lack of thought and/or is a less preferable option.

Again -- I must object. for(;;) and while(1) are functionally identical.

EDIT:

To make extra special sure, I just compiled a test program in GCC in debug (read: optimizations off):

#include <iostream>
using namespace std;

int main()
{
    for(;;)
    {
        cout << "die";
    }
    return 0;
}

Compiled with both for(;;) and while(1). The resulting binaries were 100% identical, byte-for-byte.

This means that even with optimizations off, the compiler knows to optimize out this supposed, nonexistant extra condition check.

[S6k9GNh0]

I wasn't implying that and the correct way to interpret that would be to take one example as more correct and the other example as dramatically funny. That sentence means that they don't care the aftermath, it doesn't mean that they they don't know what it does. The were taught to use while(1), good for them.

Although, I'd like to say: I know it's the same. There are some compilers that do not do this though. Please understand. If you'd like, go and try that with every compiler and see if it's the same as some will give different results.

[helios]

There are some compilers that do not do this though.

I'm not convinced. It's like the argument that ++x is faster than x++ on some compilers. Any compiler that doesn't optimize that is not worth using.