Beginer's C programming questions

Hi all,

I'm beginer learning in C programming. I've confused with some of the command or syntanx. Hope u all can help...

1. if i write void function_name (void) , what is the meaning of the second void which in the blacket? what is the difference between void funtion_name (void) and void function_name() ?

2. we always put 1 in while --> while(1)
However, got any situation using while(0) or while () ?

3. what is the difference between return, return 0 and break?

4. C programming never used goto command?

>1. if i write void function_name (void) , what is the meaning of the second void which in the blacket?
It means that the function takes no arguments.

>what is the difference between void funtion_name (void) and void function_name() ?
The first is correct, the second is not.

>However, got any situation using while(0) or while () ?
Yes, this is a common macro trick:

Code:

---

#define macro() do { \
  statement; \
  statement; \
  statement; \
} while ( 0 )

---

Now when calling the macro, you can safely add a semicolon after it without causing problems, and you'll even get an error if you forget the semicolon. This gives you more consistent syntax:

Code:

---

macro(); /* Always safe */
macro() /* Always an error */

---

>3. what is the difference between return, return 0 and break?
return without an operand can only be used with a function that returns void, return 0 can only be used with a function that returns an integral value, and break is used to jump out of a switch case or a loop.

>4. C programming never used goto command?
Huh? C supports goto, though it's a general guideline that you should avoid it unless you know what you're doing.

Quote:

---

Originally Posted by Prelude

>1. if i write void function_name (void) , what is the meaning of the second void which in the blacket?
It means that the function takes no arguments.

>what is the difference between void funtion_name (void) and void function_name() ?
The first is correct, the second is not.

---

Ehm, I guess that depends on which standard we refer to, as in C (as opposed to C++) empty brackets mean that "the number of parameters is unspecified".

Quote:

---

>However, got any situation using while(0) or while () ?
Yes, this is a common macro trick:

Code:

---

#define macro() do {
  statement;
  statement;
  statement;
} while ( 0 )

---

Now when calling the macro, you can safely add a semicolon after it without causing problems, and you'll even get an error if you forget the semicolon. This gives you more consistent syntax:

Code:

---

macro(); /* Always safe */
macro() /* Always an error */

---

---

Correct me if I'm wrong, but isn't a large portion of the "do ... while(0)" trick to do with this:

Code:

---

if (something) macro();

---

Without the do ... while(0) trick, the above would perform the first statement only when the if-statement evaluates true, but the next two statements are always executed. Which makes for "surprising" effects. If we just put braces around, you get problems with other stuff, such as semicolon on the end.

Also, while(0) can be used in conjunction with some sort of constants, #define or such - while() is invalid as there has to be some condition. It means that the code inside the while is never executed when it's zero. I sometimes use if(0) ... [or more commonly if (0 && something)] to make if-statements always false. The compiler will then, usually, remove the entire piece of code.

Code:

---

#define TEST_MODE 0  // set to 1 for test mode.
...
int main() {
  ... do something always ...
  while(TEST_MODE) {
    ... do test functions here ...
    if (TEST_MODE)
        if (getchar() == 'q') break;
  }
}

---

In this case, when TEST_MODE is zero, it will never do the test-code, but if TEST_MODE is one, it will loop around doing the test functions until someone hits 'q' on the keyboard. [excuse lack of niceties about the getchar()].

Most likely, the compiler completely removes this while-loop if TEST_MODE is zero.

Of course, the same can be achieved with #if TEST_MODE or similar.

--
Mats

>Ehm, I guess that depends on which standard we refer to
Not really. If you're referring to C89/90/95, it's incorrect because the inconsistent semantics are a ripe location for undefined behavior. If you're referring to C99, an empty parameter list is deprecated.

>as in C (as opposed to C++) empty brackets mean that "the number of parameters is unspecified"
Only for a function declaration. An empty parameter list in a function definition means no parameters. And mixing old style with new style results in undefined behavior. It's best to let the past go and always use void to guarantee that you're using new style declarations/definitions.

>Correct me if I'm wrong
Nope, that's definitely a big reason. Though you can (largely) correct the problem with braces (because an anonymous block is perfectly valid):

Code:

---

#define macro() { \
  statement; \
  statement; \
  statement; \
}

---

But now you have to deal with inconsistent syntax and the fact that everyone under the sun will try to bring back the problem by saying:

Code:

---

macro();

---

instead of:

Code:

---

macro()

---

I agree with the "use the new stuff" when at all possible. Obviously, if you have 100K lines of old code, you are not necessarily going to update all of those to the latest standard all at once, but I would certainly not define a function with empty brackets when it takes arguments, and I do use void when it doesn't take any arguments.

I guess I interpreted your "incorrect" in a slightly different manner - it is "correct" as far as the compiler is concerned, but I agree with your view - use the latest version of a construct that you can.

Quote:

---

Originally Posted by Prelude

But now you have to deal with inconsistent syntax and the fact that everyone under the sun will try to bring back the problem by saying:

Code:

---

macro();

---

instead of:

Code:

---

macro()

---

---

And the problem comes when you do

Code:

---

if (something) macro();
else ...

---

because the semicolon after a block is USUALLY valid, but not in the case where it ends a block in an if-statement, right?

--
Mats

>because the semicolon after a block is USUALLY valid, but
>not in the case where it ends a block in an if-statement, right?
Yep, because then you have an unmatched else.