Suggest a better code

[vensriram]

let there be a function

#include <stdio.h>
int add(int x, int y) or int add(x,y)
main()
{
int x,y,sum;
sum=add(x,y);
}
[B]add(x,Y) or add(int x, int y)
[/B]{
int a;
a= x+ y;
return a;
}

Kindly refer to the line numbers in bold and suggest the better code in that corresponding line number

[donbock]

What do you think is the difference between the two options?
What do you see as the advantages and disadvantages of each option?

[Oralloy]

Why does this sound like you're asking us to answer a test question for you?

[vensriram]

Hi Oralloy,
No these are not test questions. As I go through the chapters in C I have doubts either in some concepts or in some tutorial questions. Just I want to make that clear.That is the reason for these questions and definitely I am not appearing for any test at present.

[vensriram]

1. The C compiler will treat the actual arguments and formal arguments as two different variables. So in my point of view, even if we are using the same variables that has been used in the main function(in this case X & Y) in the Called function(in this case add(x,Y)) we should declare the variables again i.e. add(int x, int y).
2. In the function prototype is it enough to specify the return type of the function alone or we should even specify the datatype of the arguments of the func tion.

[donbock]

As I go through the chapters in C I have doubts either in some concepts or in some tutorial questions.

Please provide some context of how each of these options is presented in the chapters of your C book.

[vensriram]

Actually in my book I had this code as an example of functions.

#include <stdio.h>
int add(int x, int y)
main()
{
int x,y,sum;
sum=add(x,y);
}
add(int x, int y)
{
int a;
a= x+ y;
return a;
}

But after seeing the above code I had a doubt of whether we can represent the same in a different way and therefore i raised the question.

[donbock]

Please use CODE tags so there are line numbers.

Mistake #1. The second line of your code snippet is the function prototype for add. There needs to be a semicolon at the end of that line.

Mistake #2. The prototype for add says it returns an int, but the definition doesn't specify any return value. You want to keep the prototype and definition consistent.

Mistake #3. The C Standard requires that main be defined to return int.

Allowable Variation #1. You are not required to specify the argument names in a function prototype. That is, the following two prototypes are equivalent. However, there are two advantages to keeping the argument names in the prototype. (1) An easy way to create the function prototype is to cut-and-paste the function definition. All you have to do is add a semicolon. In this case it is extra work to remove the argument names. (2) Well-chosen argument names can serve as comment regarding what each argument does.

int add(int x, int y);
int add(int, int);

Deprecated Variation #2. C lets you omit the type in most places where you would normally specify the type in a declaration or definition because it assumes a default type of int; this includes the return value and perhaps argument types in function prototypes and definitions. However, making use of this feature has been deprecated for over 30 years. The most recent version of the C Standard formally announced that this feature might be removed from the next release of the Standard. People will talk about you behind your back. DON'T USE THIS FEATURE!

[Oralloy]

@vensriram

No insult intended. Your question just sounded like one of the test problems from my language survey class from oh so many years ago.

The response @donbock gave you is quite good. The only things I would add are

1) The C language has continually moved toward clarity of definition and declaration, where other languages like Perl have moved toward type transparency and run-time dispatch. There are also languages like Haskal (which I've never used) which have compile time type inference. They all serve their purpose well, although they're obviously oriented toward solving different classes of problems. Given the choice, select the language which best solves your problem.

2) C programmers have come to expect the what I call "fully quallified new-style function prototypes and definitions". I know "less is more", and by declaring less, you (in theory) have reduced chance of error. Personally, I don't think three letters are going to cause your program's code to bloat or introduce any additional errors. It may, however, illuminate ones that are already there.

Think about the expressional clarity of this function:

fac(double d)
{
  if (1 > d) return 1;
  else return d * d-1;
}

If you saw this in code you had to work with, what would you conclude?

[vensriram]

That s ok, i understood.
Then from your code whether u want me to find the utility of the code?

[vensriram]

Thank you donbock for your detailed description

[Oralloy]

@vensriram,

Sorry I disappeared on you for several days. Life reached out and pulled me away from browsers and my e-mail for almost a whole week.

What I was trying to illustrate with my code example was how misleading it can be to leave out implicit information in code. Basically, what I wrote looks like a factorial function, but in fact is a far different beast. The basic observation is that you should be clear (to humans) in what you intend the code to do, because it is probably very clear to the compiler what it needs to do.

BTW, that subtle lack of parenthesis in the second return is a modified form of a real life calculation that a co-worker of mine spent ten minutes writing and a week failing to debug. In his case, it was operator precedence of bit shift versus bitwise boolean operations. He wrote something like this:

/* swab2 - reverse two byte value */
int swab2(int v)
{
  return (v & 0xff << 8) | (v & 0xff00 >> 8);
}

Anyway, I've seen so many of that sort of error over the years that I just fully parenthesize expressions and don't worry about precedence.

Cheers. Thanks for the good intellectual exercise.

[vensriram]

Yes, I understood that because at any point of time it just multiplies n and (n-1). Factorial can be done through recursion. Thank you for a very informative discussion.

[Oralloy]

And thank you, as well. I'm glad of the chance to discuss my thoughts and perhaps learn from others as well.

Cheers!