Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Program to read numbers from a file and say if they are prime
Options
-
11-11-2011 12:39pm#1This program is designed to read a list of numbers from a file and then decide if they are prime or not.
I think one issue may be that its not reading the numbers correctly. Is it reading them as characters and I have to do that weird maths converting them from chars to ints.
Is my logic even remotely correct?#include<stdio.h> int main() { FILE *fp; int numbers[6]; int count=0; char fname[80]; printf("Please enter the name of the file you wish to print: "); gets(fname); fp=fopen (fname, "r"); printf("The contents of the file <%s> are:\n", fname); while (count<6) { fgets:("%d", numbers [count]); count++; } count=0; int isprime=2; while(count<6) { while(isprime<=numbers[count]) if(numbers[count]%isprime==0) break; isprime++; if(isprime==numbers[count]) printf("\n%d is Prime",numbers); count++; } return 0; }
Why is C so hard
:(:(:(:(:(:(:(:(:( 0
Comments
-
-
-
-
-
Why is C so hard:(:(:(:(:(:(:(:(:(
The C you've done so far is pretty straightforward, you haven't hit any subtleties yet. When writing any program you are better off deciding how the program should flow logically and then writing the code to match. A lot of algorithms are written in a kind of pseudocode where it's obvious what's going on but the code isn't valid.
For example, the old "Data Structures and Algorithms" book is written in a Pascal like form but it's trivial to write the C to match.
Looking at your code for a second....
First, don't use the gets() call - it's the call of Satan it really is. Just don't head down that path now and you won't have to regret it later! It's not a big deal now. I'm referring to lack of boundary checks:
You expect the input "foo". The user types "supercalifragalisticexpealidocious". Bang!
You can use "fgets(buffer, 80, stdin);" instead, where 80 is the size of your buffer.fgets:("%d", numbers [count]);
You're mixing all sorts of calls together on that one. Either use fscanf or fgets, not both! fscanf is a little complex to use if you have input that isn't precise - I have a tendency to use fgets(string, length, stream), and then clean up the line and pass it to strtol().
Have a go at using fscanf() first and see can you output the numbers you've read in. That's the hard bit. THEN figure out if they're prime.
You should be able to use something like:
fscanf (fp, "%d", &result);
Note the & before result. That's your introduction to pointers (evil laugh).
Have a go...0 -
Advertisement
-
I should add that fscanf gives me a headache sometimes when it comes to the line feed at the end of each line. So fscanf(fp, "%d", &result); will work for the first number and then the next read is spaces or a line feed and it'll fall over. Pain in the face.
I've a tendency to use fgets, check that, then use sscanf to scan it. At least I don't go mad that way
Get in the habit of using #defines, that way you don't have to remember what number you used where:#define LINE_MAX 80 char line[LINE_MAX]; ... while (fgets(line, LINE_MAX, fp) != NULL) { ret = sscanf(line, "%d", &result); if (ret != 1) /* ie: 1 integer read successfully */ .... oops ... printf("Read an integer: %d\n", result); }Have a go with that ....0 -
-
Or "const int" even!
Or enum which is practically the same as #define with extra semantics. It's a common alternative to #define for int.
enum { LINE_MAX = 80 };
Note that C is not C++. A "const int" is not a "constant integer expression" in C, as it would be in C++. So you can't use it in some places (e.g. a case statement).
Subtle, huh. C is a razor sharp language like that. Easy to cut yourself 0 -
-
I always need to scratch my head a bit on those!
I wasn't correcting you there, just being a little puzzled at the different usage. Which is right of course.
const int and int const are the same but put in a * and things change.
const char * and all that.
The OP must be pretty confused at this point
Edit: Before you say it: const char *p, char const *p are exactly the same. I obviously need caffeine.0 -
Advertisement
-
-
-
This program is designed to read a list of numbers from a file and then decide if they are prime or not.
I think one issue may be that its not reading the numbers correctly. Is it reading them as characters and I have to do that weird maths converting them from chars to ints.
Is my logic even remotely correct?#include<stdio.h> int main() { FILE *fp; int numbers[6]; int count=0; char fname[80]; printf("Please enter the name of the file you wish to print: "); gets(fname); fp=fopen (fname, "r"); printf("The contents of the file <%s> are:\n", fname); while (count<6) { fgets:("%d", numbers [count]); count++; } count=0; int isprime=2; while(count<6) { while(isprime<=numbers[count]) if(numbers[count]%isprime==0) break; isprime++; if(isprime==numbers[count]) printf("\n%d is Prime",numbers); count++; } return 0; }
Why is C so hard:(:(:(:(:(:(:(:(:(
Does that code even terminate?while(isprime<=numbers[count]) if(numbers[count]%isprime==0) break;
Unless "numbers[count]%isprime" is 0, that code is going to run forever, right? It looks like you've forgot to add braces, for the body of that while loop?
You need to go slower.
Test each piece, and make sure each piece does what you think, before adding complexity.
Make your code neat, and nicely formatted.
Given variables names that make sense.
'isprime' is a bad name for that variable. What does that variable do? Why dont you name it, according to what it does?
Indent your code so that the structure of the code is obvious from looking at it.
Write down the algorithm in english first, then in something like the code, and then eventually, write it, piece by piece, in C, testing each piece.
You must move in a careful and disciplined manner, or it'll be very hard to manage the complexity.0 -
-
-
-
-
-
I don't disagree with either of you. The intense level of work on this module is doing just that, making us attempt stuff that we don't have a clue about. Shame, because my other modules are really good. At this stage I'm kind of resolved to try to do my best and if I can at least pass then that's great, then teach it to myself once the course is finished.
Wait til you get to 3rd year (I'm assuming you're in UCD from comments you've made), you'll laugh at your current workload. I have about 3 modules with that amount of work
, one of them with very heavy theory.
(I have heard that that particular lecturer is kinda awful, but getting a book will help)0 -
Wait til you get to 3rd year (I'm assuming you're in UCD from comments you've made), you'll laugh at your current workload. I have about 3 modules with that amount of work, one of them with very heavy theory.
(I have heard that that particular lecturer is kinda awful, but getting a book will help)
I sent you a pm just to check your thoughts on one or two things.0 -
Advertisement
-
Wait until you are in 4th yearWait til you get to 3rd year (I'm assuming you're in UCD from comments you've made), you'll laugh at your current workload. I have about 3 modules with that amount of work, one of them with very heavy theory.
(I have heard that that particular lecturer is kinda awful, but getting a book will help)
... wait until you are in industry with deadlines :pac: 0 -
-
-
-
Why? Surely defines are completely appropriate to these sort of small size mathematical C programs?
Probably true, however an enum can be useful when using a debugger. At least under the first C IDE I used (Turbo C 2.01!) the debugger would display the symbol at well as the value. Pretty useful that. I have no clue what most people use these days. I use printf and command line compilers.I think debuggers are a tool better kept for more advanced use; if you start using them too soon, you can get into the habit of writing programs by band-aiding the bits that don't do what you think;
That's very true. The tendency is to fix it so something happens rather than look at the flow.
But having said that an IDE debugger (rather than something like GDB) is terribly useful just to see what on earth is going on. Being able to see the values actually change as you step through is pretty instructive and makes you see what's happening as the program runs..So, I'd say, back up a bit. Take each small construct that you use, and look at it separately.....Start off by writing a program that reads a list of numbers from a file, and prints them out.
Absolutely. That's what I was trying to say in my post a few days ago. Get each bit working before proceeding to the next part. My next thought was going to be:
"write a separate program that tells you whether a single number is prime or not"
but fergalr has just said that. It's exactly what most programmers do. If I'm uncertain about something I'll knock up a 6 line program just to find out. If it's a complex subroutine, I'll knock up a wrapper program solely to test the subroutine.
Very very few professionals can just open a file and start typing and expect 10 disparate steps to all work together first time. The lower level you go, the harder that gets. Doing it in assembly language is undoable. I've written 100 lines of assembly that worked first time, but the previous step was 40 lines of pseudocode and previous to that, 20 lines of "what I'm doing".
PS: Putting variable declarations/definitions anywhere in the code is not allowed in C. They must be at the top of an enclosing block. Just so you know 0
Advertisement