Pointers

This is a discussion on Pointers within the C++ Programming forums, part of the General Programming Boards category; Using a pointer, write a function named time() that accepts an integer number of seconds and the addresses of three ...

Pointers

Using a pointer, write a function named time() that accepts an integer number of seconds and the addresses of three variables named hours, min, nad sec. The function is to convert the passed number of seconds into an equivalent number of hours, minutes, and seconds and directly alter the vlaue of respective variables using the passed addresses.

To test, run the program using 10,000 seconds.

I know its not a big program, but I am stuck, anyone who will help me will be appreciated. Please mail this back to my address: dharma_sanyasi@hotmail.com

sam:
1. Don't do someone's homework for them.
2. It's <iostream> and we use namespace std.

I don't understand why people get funny over convention on this forum. The file is called iostream.h so I will refer to it as such. Since when was this perfectly acceptable practice so taboo? At what point did some smart arse say "Oh, you can't do that anymore - despite the fact that it's served you perfectly well for decades"?

And what exactly is all this "namespace" malarkey? I've never used it. I've never been taught it. My C++ books don't mention it once. The program compiles perfectly well without it, so to all intents and purposes it is pointless.

<iostream> is standard (which I am using to mean in compliance with the ISO C++98 Standard). <iostream.h> is not and never was standard. Do a search on namespaces on this board, and you will "discover a wealth of information".

I don't understand why people get funny over convention on this forum.

All languages evolve--including C++. Without conventions, programs you wrote would never be able to execute on anyone elses computer, and probably not even on your own, unless the person who wrote your C++ book also wrote the compiler software.

I've never used it. I've never been taught it. My C++ books don't mention it once.

Well, you are wrong, your teachers have been ignorant, and the author's of your books were incorrect. You can stick with being wrong, or you can learn the correct way to do something. No one really cares if you insist on doing things incorrectly yourself, but when you advise beginners to adopt bad practices, then you should expect to be corrected.

Your more egregious transgression, however, is that you posted a solution to what was clearly someone's homework--it violates the cboard homework policy, and it's not fair to those students who do their own work. In addition, a person learns more by coming up with the solution on their own.

Here is some information on pointers that you may or may not find useful:

All variable names and their corresponding values are stored in memory somewhere. The location in memory where they each reside is denoted with an address. An address is somewhat scary looking:

006BFDF4

but you can just think of it as a mailbox number. If you look inside the mailbox with that number, you'll find the variable and its value. A pointer is a variable that stores the address of another variable.

If you declare an int like so:

int num = 10;

that line stores the variable num with a value of 10 somewhere in memory. We don't know where it is in memory yet. However, there is an "address of" operator which will get the address of num, e.g.

cout<<&num<<endl;

You can store that address in a special variable called a pointer:

int* p;

That declares a variable named p, and p is a variable of type "pointer to int". Essentially, you read the line in reverse. Now, you can assign the address of any int to p:

p = &num;

which reads: "p equals the address of num".

Finally, you can also use a pointer to get the value stored at that address by putting a little star in front of the pointer name:

cout<<*p<<endl;

Pointers are very important in the context of functions. If you pass a regular int type to a function, like this:

the function is not able to permanently change num. When the function returns, num is still equal to 24 not 26. How can that be? The problem is that when you send num to the function, a copy of num is made for the function, and the copy is what actually gets sent to the function. Then, the function proceeds to change the num copy, and when the function finishes executing, the num copy is destroyed--as are all variables declared inside the function. (Note: the function 'parameters', i.e. the variable names inside the function parentheses, are variables that store the values you send to the function. The parameters are considered to be declared inside the function, and they are destroyed when the function ends--along with any variables declared inside the function body.)

A pointer is what allows you to change a variable value permanently inside a function. Look at this example:

An address of a variable gives you access to the value stored in the variable, and the result is that you can change the value of the variable permanently.

The process is actually the same as before, but the result is different. A copy of the variable p is made and sent to the function, and when the function finishes executing the copy of p is destroyed. However, p is able to permanently change the value of num. The difference in the two examples can be seen in this analogy: the first example is the same as if you made a xerox copy of a sheet of paper with the number 24 on it, told a friend to take the xerox copy and and change the number to 26, and then told him to burn the xerox copy. Would anything change on the original sheet of paper? The answer is obviously no. That is why num still equaled 24 in the first example.

However, if you put the sheet of paper with 24 written on it into one of 10 mailboxes on your street, wrote the mailbox number down on a piece of paper, copied the sheet of paper with the mailbox number on it, gave the copy to your friend, your friend went to that mailbox number and erased the 24 on the piece of paper therein and wrote down 26, and then burned the xerox copy with the mailbox address on it. What would be the number written down on the piece of paper in the mailbox when you checked it later that day? Hopefully, you can see that the answer is 26. That is the process that took place in the second example. The function was able to change the variable num from 24 to 26:

Code:

int num = 24; //put a sheet of paper with 24 written on it into a mailbox
int* p = &num; //recorded the address of the mailbox
add2(p); //gave a copy of the address of the mailbox to your friend: a function named add2()
*p = *p + 2; //your friend add2() erased the 24 on the paper, and wrote down 26
cout<<num<<endl; //Later that day, you checked what was written on the paper.

All languages evolve--including C++. Without conventions, programs you wrote would never be able to execute on anyone elses computer, and probably not even on your own, unless the person who wrote your C++ book also wrote the compiler software.

Well, you are wrong, your teachers have been ignorant, and the author's of your books were incorrect. You can stick with being wrong, or you can learn the correct way to do something. No one really cares if you insist on doing things incorrectly yourself, but when you advise beginners to adopt bad practices, then you should expect to be corrected.

Your more egregious transgression, however, is that you posted a solution to what was clearly someone's homework--it violates the cboard homework policy, and it's not fair to those students who do their own work. In addition, a person learns more by coming up with the solution on their own.

OK, but what possessed someone at ISO to propose, "I know, let's make removing the .h a standard"? What does it achieve? It seems to be the epitome of just-for-the-sake-of-it-ness.

As for namespaces, I've survived long enough without even knowing they existed. Call me strange, but I would have thought that to propose a radical change of standard in something that works perfectly well already, it would have to be some kind of life-altering standard - one for which the benefits would be immediately obvious. I don't see this with namespaces.

And I apologise for posting the solution - but I'm sure he won't just blindly cut and paste it. No doubt he'll make an effort to understand it and, ultimately, learn from it. This is how books teach us, so I thought it would apply equally here.

And if I were such a pedant, I could pull you up on your grammar - a glaring example of which is up in bold...

Also I see that my reputation points have gone down. Rrrraw! The claws are out tonight, aren't they ladies?

For one: consistency, which fosters predictability, which allows programs to run in more places.

As for namespaces, I've survived long enough without even knowing they existed. Call me strange, but I would have thought that to propose a radical change of standard in something that works perfectly well already, it would have to be some kind of life-altering standard - one for which the benefits would be immediately obvious.

Namespaces are such a useful tool, it's hard to know how to respond to that statement. Do you go through the standard library cataloging all the variable names, so that you don't duplicate them in your code? The reason you don't have to do that is because all those names are in the std:: namespace, and your code isn't, so even if you name your variables the same name as something in the standard library, you won't get an error.

Some programmers work on large projects in conjunction with other programmers. Since programmers are supposed to give meaningful names to variables, functions, and classes, what do you think the odds are that two programmers writing code on the same project use the same name to describe something? Probably pretty good since they are writing code about the same things. When all their code is combined, variables with the same name will cause errors, and the debugging of that code could take countless hours. But, what if the project manager assigned a unique namespace to every programmer? No name clashes, no attendant errors, no enormous cost to debug something that is easily preventable.

You have to realize that a lot of these programming languages are vast subjects, and just because you personally don't use a feature, or don't adhere to the standards, or adhere to good programming practices because you only write code for yourself, doesn't mean that the features or the standards aren't valuable.

Namespaces are such a useful tool, it's hard to know how to respond to that statement. Do you go through the standard library cataloging all the variable names, so that you don't duplicate them in your code? The reason you don't have to do that is because all those names are in the std:: namespace, and your code isn't, so even if you name your variables the same name as something in the standard library, you won't get an error.

Some programmers work on large projects in conjunction with other programmers. Since programmers are supposed to give meaningful names to variables, functions, and classes, what do you think the odds are that two programmers writing code on the same project use the same name to describe something? Probably pretty good since they are writing code about the same things. When all their code is combined, variables with the same name will cause errors, and the debugging of that code could take countless hours. But, what if the project manager assigned a unique namespace to every programmer? No name clashes, no attendant errors, no enormous cost to debug something that is easily preventable.

That makes sense now. Thank you for explaining it. Still of no immediate use to me, but I can see the benefit now.

With regards to <iostream.h>: that was also consistent before ISO changed it, was it not? I mean, didn't everyone put the .h in?