llllllllllllllll
Printable View
llllllllllllllll
In ReadFile you should be reading from a file not from the keyboard. Surely those scanf's should be fscanf's. Also drop the ncircles parameter completely as that variable is global as are s and t which can also be dropped.
cccc
the variables you pass into the function are all GLOBAL. that means they can be accessed from everywhere. The only parameter that function needs is the filename. fscanf is slightly different to scanf. it requires a FILE* too. scanf reads only from the keyboard assuming stdin hasn't been redirected.
At the moment, you open a file for reading, try to get input from the keyboard, then close the file.
int fscanf ( FILE * stream, const char * format, ... );
thats the prototype for fscanf. See the first parameter is the file pointer which is why you got that error.
scanf is equivalent to fscanf( stdin, .......... ) which is why it never needs that parameter. its hardwired.
fff
For starters change it to
change the call to ReadFile in main to only pass the filename.Code:void ReadFile( const char* filename )
change the scanf's to fscanf's with the FILE* as the first parameter.
oooo
Give up programming its not for you!
Ever going to do anything in particular with that open file pointed to by the FILE* called file??Code:FILE *file;
if (( file = fopen( filename, "r" )) == NULL )
[[[[
btw you will also need to drop the asterix here
i<*ncircles
as ncircles is a global int, not an int* so dereferencing it is completely wrong.
fscanf( file, .............. )
how hard can it be. you open the file but never read from it. You have to tell the fscanf where to read from.
qqqq
Use your debugger and find out. Learning to debug your code is part of learning to program. work out on pen and paper what values you expect in variables and watch to see whats actually happening as you step through your code. When you see something unexpected, work out what went wrong and fix it.
aaa
You wrote the code, therefore you must have known what every variable, function, line of code does.Quote:
Originally Posted by sadam
Therefore, what is stopping you from debugging your own code? You wrote it, right? So why can't you debug something you wrote? As was stated, learning to debug your programs is part of learning how to program. So asking us to do the work you're supposed to have done is almost and maybe, just as bad as one of us writing the code for you.
Regards,
Paul McKenzie
gggggggggggg
Most bugs dont cause the compiler to spit out an error. Most occur during runtime. For this you need to attach the debugger and step through your code watching the variables closely as i have already told you. You need to know what to expect, so as to see when something went wrong. When you find variables that hold values that are unexpected, if you are singlestepping your code you will see exactly where it happens and so be able to start working on solving the errors.
In future as you write each function, test it to ensure what you think is happening is actually what is happening.
Why cant you debug your code? What compiler and debugger and IDE are you using? Look in the docs for it to see how to work the debugger. Its time for you to learn.
kkkkkkk
Nope. Not wierd at all. Learn to use your debugger. Use your debugger.
Watch this.
nnn
Everyone who has responded to you can solve the issue. The problem is can you solve it? That requires you to just sit down and learn how to debug your program using the debugger that comes with your compiler.Quote:
Originally Posted by sadam
You didn't do that -- the only thing you did was write a big program, tried to run it, and want us to fix it without any effort on your part to see what is wrong.
Even if you didn't have a debugger, where are the cout statements to help you to know what the values of variables are, what lines of code you're executing, etc.? This is the harder way to debug, but at least it's something, but you didn't even do that.
Regards,
Paul McKenzie
Quote:
Originally Posted by sadam
This program compiles OK. What do you think happens when y is computed (i.e. a divide by zero happens)? Will the program get to the cout statement?Code:#include <iostream>
int main()
{
double x = 1.0;
double y = x / (x - 1.0);
std::cout << y;
}
This program compiles fine. What do you think happens when you assign a value to a NULL address?Code:#include <iostream>
int main()
{
char *p = 0;
*p = 'x';
std::cout << p;
}
Just because a program compiles doesn't mean when you run it, everything is OK. Is that what you were expecting, that all programs "work", and there is no need to debug them?
Regards,
Paul McKenzie
rrrrr
tttttt
One, we wouldn't be able to just look at the code and tell what is wrong. We would need to debug it. An IDE will have an option to debug your program. You can set a breakpoint at a line. From there, you will have options to step through the code. When you get to a function, you can either step over that function or step into that function. Really, if you are going to program in C++, using the debugger is a must.
aaaaaaa
Those are not warnings from the debugger. Those are warnings from the compiler when you are building your program.Quote:
Originally Posted by sadam
The debugger is used when your program has been built, and you are running your program, and you are seeing how your program runs by inspecting the value of variables, setting breakpoints, etc.
Regards,
Paul McKenzie
Someone's thrown their toys out the pram :rolleyes:Quote:
Originally Posted by sadam
I thought it was to keep the teacher and classmates out of it.