Function not working, is it my compiler

Im trying to write this program and i think i am close to being complete but im getting 2 errors C2448, C3861. I am using microsoft visual studio 2005 and when i look up the definitions for the code it doesnt help much anyone have an idea of whats going on

Well im trying to use pointers and have them work with the function. I am a student and i am having trouble. I am not asking for anyone to do my homework for me, thats my job, but if anyone has any tips or can provide any explanation on this because i am a little lost and my teacher isn't much help because he won't respond to email frequently and i only have class once a week. If this is a problem or if anyone believes i should not be asking anyone here for help please tell me so i can stop posting and you wont have to hear about it.

Well im trying to use pointers and have them work with the function. I am a student and i am having trouble. I am not asking for anyone to do my homework for me, thats my job, but if anyone has any tips or can provide any explanation on this because i am a little lost and my teacher isn't much help because he won't respond to email frequently and i only have class once a week. If this is a problem or if anyone believes i should not be asking anyone here for help please tell me so i can stop posting and you wont have to hear about it.

There's no problem with what you're asking, you're doing fine. But the chances of you bumping into a compiler bug with simple code like this are astronomically low. That's all I mean.

This is the second thread today I've read where someone is just writing random code and praying for it to make sense to the compiler. STOP! You just can't learn to program like that.
For every little thing you don't know how to do, DON'T JUST GUESS how to do it. You won't get it right. To learn C or C++ you absolutely MUST spend most of your time learning (e.g. from a book) and when you've read how to do something then and only then do you actually write the line of code to do it.
There are no shortcuts.

I work on a project with close to a million lines of code in VS2005 and afaik we haven't seen any compiler bug. Chances are you never will either!

My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger

Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Yes, blaiming the compiler in this case is like blaiming the tyre manufacturer for a puncture. If you ran over a nail or screw, it's not their fault. If you can SHOW that the tyre was incorrectly produced, it's their fault. Most punctures you can't - you may not be able to find the nail/screw/glass or whatever that caused the puncture, but it doesn't make it Dunlop's or Michelin's fault.

Like iMalc, I work on large projects. I have, in the last 20 years as a professional programmer, seen half a dozen or so compiler bugs. It is slightly more likely if you do "strange things". One that comes to mind was a "bad optimization" in a windows x86 compiler (Not Microsoft). It generated code that would restore the stack first, then restore registers from a negative offset on the stack. Which works fine when you are in user-mode, but not when the code runs in kernel mode - especially not when this code is JUST after the "enable interrupt" - because sooner or later, an interrupt happens, splat - the top of the stack is now containing your interrupt context, then we restore registers from the splatted area, and bang, bad things happen. That was about 7 years ago, and I was doing really unusual things with this compiler. [and I managed to work around it by fiddling with some optimization switches to make the compiler choose a different way to produce the function epilogue].

Also, the more "unusual" the compiler is, the more likely it is that it's got bugs.

--
Mats

Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

- I suggest you start-out with a program that gets one value from the user, and saves that value using a pointer. Then write a cout line that displays the value. When that works, do the same with the other 3 coordinates.

- Then, write a function that does nothing but displays the 4 coordinates. Don't forget to make a function portotype, a function definition, and a function call.

- When that works, add the calculation to your function.

...Or, you might want to simplify it even more... You can try first writing the program without using pointers or a seperate function. Then, you can add those "features" one at a time. The idea is to write and debug one or two lines at a time, so that you know where your errors are, you will have fewer errors to deal with at one time, and you can more easily debug them.

int _tmain(int argc, _TCHAR* argv[])

Is this the way you learned in class? It's microsoft-specific. (int main() also works with the Microsoft compiler.)

Quoting myself...

Originally Posted by DougDbug

I have some general advice for you...

Don't try to write the whole program at once. If you write the whole program before compiling, programming is going to be very frustrating.

Always start-out with a little Hello World type program.... When that's working, add one or two lines of code, then test-compile and test-run.... Repeat 'till done.

If you use this method, you won't get a bunch of errors at one time, and you will know exactly which lines have caused the error.

This does NOT mean that you can write the code in "line-number order" a few lines at a time! (A program won't compile if you simply chop-off the 2nd half!)....

....If you use this technique, programming will be a lot more fun! Professional programmers use similar techniques. Of course, they are not test-compiling every one or two lines. But, they are working on huge programs and they do write (and test) their code in managable chunks.

I'm NOT saying that "trial-and-error" is a good programming technique. You should have a design and a plan, and you should understand what you are doing. But, you probably won't make it through beginning programming without some "experimentation". And, it is good programming practice to test your code as you are developing it.

Ok well i was not trying to blame the complier, someone told me compilers can have bugs. I am very new at this and i am trying my best. I have been reading, i do have books. I would like to thank you all for the help as well. The explanation of starting simple with one variable then working the program up is one of the best tips i have heard and i am putting it to use, thank you all again.

Yes, it happens that compilers have bugs. One problem I was loosely involved with in the past was when a "machine generated" function of 90000+ lines of code would generate code that crashed. But for your average small piece of code, using a "good" compiler, it's very unlikely that you will hit a compiler bug.

Glad that we could help you get "wiser".

--
Mats

Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.