Prototypes?

My instructor wishes for me to construct prototypes for a small program but I'm having a time figuring this out. help please.

// interest.cpp
// Date: Feb 25, 2008
// Calculate the simple interest on a loan for 1 year given the amount and rate
#include<iostream>
#include<iomanip>
using namespace std;

Code:

---


//Prototypes here



int main()
{
        // declare variables

        // get user input

        // call function for calculation

        // display results

        return 0;
}

double calcint(double amount, double rate)
{
        return amount * rate * 1;
}

---

Outside of writing the prototypes for you, what would you like us to do?

Are you having trouble understanding what a function prototype is?

Writing prototypes is simple. Just select the first line of the function, copy it, paste it at the top and add a semicolon. Works in most cases.

Quote:

---

Are you having trouble understanding what a function prototype is?

---

Yes i am. and could u finish the program so i can get a step by step basis of how to complete my programs. its a hybrid course so i have little help for the instructor. Thank you

Replied

Quote:

---

Originally Posted by MuzicMedia

Yes i am. and could u finish the program so i can get a step by step basis of how to complete my programs.

---

That is your responsibility.
http://en.wikipedia.org/wiki/Function_prototype

The prototype should just be a replica of how your function definition looks like, but with a ; at the end, as have already been implied. It's not tougher than that.

Quote:

---

Originally Posted by MuzicMedia

Yes i am. and could u finish the program so i can get a step by step basis of how to complete my programs. its a hybrid course so i have little help for the instructor. Thank you

---

Yes, I could do your homework for you, but that doesn't help you learn anything. There are examples of code all over the web, which you can learn from. Assignments are for you to actually gain practice from doing the work.

A function prototype is easy to understand if you know what a function is. Basically, a function prototype is used to tell the compiler that you have a function that you wrote. This lets the compiler store information on what types of variables it accepts and what type of variable it returns. When it comes across usage of your function and the definition of the function itself, it can verify that it matches the prototype. If it doesn't match, however, then the compiler can let you know something is wrong, and allow you the opportunity to go back and fix it.

Quote:

---

Originally Posted by CornedBee

Writing prototypes is simple. Just select the first line of the function, copy it, paste it at the top and add a semicolon. Works in most cases.

---

And will work in your case.

a hint for you:

the following will work fine:

Code:

---

double calcint(double amount, double rate)
{
        return amount * rate * 1;
}

int main () {
        //...
        calcint (amount, rate);
        //...
        return 0;
}

---

the next code won't compile because the compiler doesn't know what calcint is:
its declaration appears after the program calls it in main.

Code:

---

int main () {
        //...
        calcint (amount, rate);
        //...
        return 0;
}

double calcint(double amount, double rate)
{
        return amount * rate * 1;
}

---

a function prototype tells the compiler that calcint exists: it lets you implement your calcint anywhere:
<solution removed>

not a good practice remove var names from function prototypes - makes code harder to read

When they are member functions, I tend to leave the names in. When they are not member functions (usually when I'm actually writing in C), I tend to leave the names out.

Quote:

---

When they are not member functions (usually when I'm actually writing in C), I tend to leave the names out.

---

What's your rationale for this practice?

Quote:

---

Originally Posted by laserlight

What's your rationale for this practice?

---

In all honesty, probably nothing worth copying. :) I just posted what I have done in the past, and I'm open to changing it. Usually, it was done without much conscious thought.

I try to write my classes inside headers, and I need to have an idea how all of my classes generally interact. I imagine I write the names out because of this, because it helps me figure out what the class is doing in each function when I'm writing the headers before I write any actual implementation code.

In terms of C, I guess it's because I generally know from the name of the function and the types they take what is going on. Member functions have the added context of a class that they operate within. Non-member functions do not have that context. They operate in terms of the program (or the collection of other functions you're grouping them with), and I think potentially (depending on how you write your code of course) easier to figure out what they do.

All in all, I've heard both ends.... it's good to leave the names in, and it's good to not leave the names in. In terms of people that need to study the headers or prototypes and want to learn how to use your code, it's probably best to leave the names in as hints as to how the function works.

Quote:

---

Originally Posted by MacGyver

When they are member functions, I tend to leave the names in. When they are not member functions (usually when I'm actually writing in C), I tend to leave the names out.

---

And how do you know looking at
char *strstr(const char *, const char *);
Where should be put the full string and where the substring to be searched?

http://www.cppreference.com/stdstring/strstr.html

Code:

---

  #include <cstring>
  char *strstr( const char *str1, const char *str2 );

---

http://www.opengroup.org/onlinepubs/...ns/strstr.html

Code:

---

#include <string.h>

char *strstr(const char *s1, const char *s2);

---

I don't know. You tell me. ;)

As you can tell, they didn't choose very meaningful names, but regardless of variable names, shouldn't documentation be consulted when using a function?

Not really. The entire purpose of having meaningful names is to make it unnecessary to consult the documentation every time you use the function. What I remember about strstr is "searches for a substring". The char* return type tells me that it returns a pointer to the found position. I wish the argument names would tell me where I put the needle and where the haystack.

Quote:

---

I don't know. You tell me.

---

hmm... I get your point. The second prototype is identical to the version from C99.

On the other hand, C++03's version of std::find is:

Code:

---

template<class InputIterator, class T>
InputIterator find(InputIterator first, InputIterator last, const T& value);

---

It is a non-member function template, and so analogous to strstr(). Personally, I find that the C++ version is clearer: I get a hint on what are the parameters without having to look further into the text of the standard. With the C99 version, I must look further into the text of the standard. If you do not know what they do, then either way you have to read further, but if you only want to know the order of arguments, having descriptive parameter names looks good to me.

They do help. You may know a lot of functions and what they do, but sometimes you can forget what the parameters are and what they do. It's very easy to mix up source & destination and arguments that are like each other, for example.
All I see is bad practice for non-descriptive prototypes.

If the arguments have sensible names, then having the variable names there is a help. If they are just meaningless names (such as s1, s2 in the strstr() example above), then it makes little difference. Of course, if you use the method I do, which is to write the function first, then copy it to the prototype location, it's meaningless to go and edit the function prototype to REMOVE the names - but that's depending on how you go about producing the prototype in the first place.

--
Mats

Wow, this site is great.

Thank you. Does it always have to be double, because those are the only examples i seem to find?

-After the calcint(amount, rate), do i have to put in parentheses which things are associated with the function prototype?

Quote:

---

Originally Posted by vart

not a good practice remove var names from function prototypes - makes code harder to read

---

true, it's a lazy-ish practice

Quote:

---

Originally Posted by MacGyver

I don't know. You tell me. ;)

---

http://msdn2.microsoft.com/en-us/lib...kz(VS.80).aspx

Code:

---

char *strstr(
  const char *str,
  const char *strSearch
); // C only

---

first is a string, second is a substring. And it is shown by intellisense - I do not need to go to the external documentation if I know in general what function does (In VS2008 it is even clearer - _Str and _SubStr)

Nothing on MSDN is ever clear. ;)