Thread: Where do they go?

Originally Posted by Lesshardtofind

Cool thanks for the info I will read up on stacks now. Its a new term for me. I know that obviously this wouldn't be a solid foundation to lay a program on. The only reason I coded the example is I wanted to take the scientific approach to what I was told and prove it true. To my surprise I found this case to allow it to be recalled, but I noticed if the cout were repeated on the next line then the number came back different, but consistently different. I.E. When I first compiled it I used the loop control 10. Then I changed the control to see if it would cout other numbers and it did, but if I call it again then it reverted back to that original 10 and it did that EVERY time. I found that to be strange. I started a new project to see if I compiled it the first time and it was at a different loop if this would carry over as a new default, and it didn't. So strangly 10 is the default value for that memory adress if it isn't curry being used.

Who knows what the standard implementation that you are using does? It really shouldn't affect you unless you do evil things You can always try and step through it with a debugger.

Last note if I changed the

Code:

cout<<*ptx<<endl;

to

Code:

cout<<pts<<endl;

it couts what I'm guessing is that memory positions hex adress which no matter what I change in the program that cout is consistent and true, just not always the same value stored in that adress. Thanks again for the information on the subject. I've been having problems really wrapping my head around pointers and how they are used so I'm constantly playing around with experiments.

Yes, you're right in assuming that's the pointer's address (the compiler infers the datatype). It outputs it as a hex address, but don't forget it is just an address -- a set of bits which identify a memory location -- how you interpret it is up to you.

@ brewbuck yea I'm starting to notice that. When I start getting above 5,000 lines of code in a program, I tend to create bugs if I'm not really careful(obviously becuase I'm still new to this) . So I started on a trek of learning why and how bugs are being created so that I could solidify the foundations of my programs allowing ultimately more complex programs for me to write and still trust.

I get what you mean, I found that really exciting as well. If you learn more and more about what really happens, you get a thrill!. For instance, learn about memory, paging, heap and the stack. Then learn about Assembly and try to see if you can recreate simple C/C++ programs in Assembly -- or just look at a disassembly! Once you get all of this in your head, you'll see how amazing it is and how, even being a low-level language, C can be quite a nice deal of abstraction, at least to me.

I learnt that by writing tests and by reading up some info. I started out writing a simple OS and learnt a great deal. And now I have written my own C library which works to a pretty good extent with all these concepts. Oh, threading is also nice to learn, and the Unixy way of doing some things (fork()ing, execvp()ing) is nice.