Help me fix my mess!!!!

Ok, I created a mess, and I am in 36 complier errors. Now, I fixed most of what I know how to fix but some of the errors I don't know how to fix and I am taking a different approach to this problem.

The program is supposed to ask a student what is name and grades are, then it is supposed to get grades from a student and write them to a file using dynamic memory allocation. I will post the code first and if anyone needs to see the billions of errors I can post the log file.

OS: XP Tablet PC Edition.
Complier: Visual C++ 2005 express

Code:

---

#include <iostream>
#include <cmath>
#include <iostream>

using namespace std;

class Student
{
public:
        void calculate();
        void writeToFile();
        char name[20];
        int age, grade;
        int numtests;
        int i = 0;
        int *iPtr;
        };

int main()
{
        Student stud;
        //Ask for students name
        cout << "Enter the student's name: ";
        cin.get(stud.name, 20, '\n'); 
        cout << "Enter the student's age and grade seperated by a space: ";
        cin >> stud.age >> stud.grade;
        stud.calculate();
        stud.writeToFile();
        return 0;
}
       
       
        //Calculate grades
        void calculate()
        {
                Student st;
                cout << "Enter the number of tests you are entering: ";
                cin >> st.numtests;
                int * st.iPtr = new int[st.numtests];
                for (int st.i=0; st.i<st.numtests; st.i++)
                {
                        cout << "Enter test score #" << st.i + 1 << " : ";
                        cin >> st.iPtr[i];
                }
        }

       
        //WritetoFile function
        int writeToFile()
        {
                Student stu;
                ifstream a_file;
                cout << "Now writing data to file.....";
                ofstream a_file("grades.txt");
                if (a_file.is_open() )
                {
                        cout << "The file opened incorrectly, program terminating.";
                        return 0;
                }
                else
                {
                        a_file << "The student's name is: " << stu.name << endl;
                        a_file << "The student's grade is: " << stu.grade << endl;
                        for (int stu.i = 0; stu.i < stu.numtests; stu.i++;)
                        {
                                a_file << "Test score #" << stu.i + 1 << " is " << stu.iPtr[stu.i] << endl;
                                cout << "Data finished writing to file.";
                                delete [] stu.iPtr;
                        }
                }
        }

---

This will now compile. I did not run it to see if it actually works as it should. A big tip: compile ALOT more often!

Code:

---

#include <iostream>
#include <cmath>
#include <fstream>

using namespace std;

class Student
{
public:
        void calculate();
        int writeToFile();
        char name[20];
        int age, grade;
        int numtests;
        int i;
        int *iPtr;
        };

int main()
{
        Student stud;
        //Ask for students name
        cout << "Enter the student's name: ";
        cin.get(stud.name, 20, '\n'); 
        cout << "Enter the student's age and grade seperated by a space: ";
        cin >> stud.age >> stud.grade;
        stud.calculate();
        stud.writeToFile();
        return 0;
}
       
       
        //Calculate grades
void Student::calculate()
        {
                Student st;
                cout << "Enter the number of tests you are entering: ";
                cin >> st.numtests;
                st.iPtr = new int[st.numtests];
                for (st.i=0; st.i<st.numtests; st.i++)
                {
                        cout << "Enter test score #" << st.i + 1 << " : ";
                        cin >> st.iPtr[st.i];
                }
        }

       
        //WritetoFile function
        int Student::writeToFile()
        {
                Student stu;
                cout << "Now writing data to file.....";
                fstream a_file("grades.txt");
                if (a_file.is_open() )
                {
                        cout << "The file opened incorrectly, program terminating.";
                        return 0;
                }
                else
                {
                        a_file << "The student's name is: " << stu.name << endl;
                        a_file << "The student's grade is: " << stu.grade << endl;
                        for (stu.i = 0; stu.i < stu.numtests; stu.i++)
                        {
                                a_file << "Test score #" << stu.i + 1 << " is " << stu.iPtr[stu.i] << endl;
                                cout << "Data finished writing to file.";
                                delete [] stu.iPtr;
                        }
                }
        }

---

Usually when there are a billion errors, they are results of previous errors, so the first 2-3 errors would be the only real errors, and you should have posted them at least.

void calculate() should be void Student::calculate(), and int writeToFile() should be int Student::writeToFile() and I wont correct more than that unless I see the exact errors.

Quote:

---

Originally Posted by MadCow257

A big tip: compile ALOT more often!

---

No, no, no. That's horrible practice. You should know exactly what your code will do when you compile without compiling it. Guessing and checking is one of the most basic mistakes a new programmer can make. Compile when you need to, but save, save, save all the time. You should always have backup copies and old versions you can go back to if you need.

I really hope you're joking, Sly...

About what? People that compile every time they make a new statement?

Not at all. If you need to compile your code and run it to know what it's going to do then you should be studying up better on what you're doing. You should have a very, very sturdy foundation before you should ever need to compile. In the case of the program above, there would be no need to compile it until it's finished. It's short, it's very direct to what it's doing. There should be no suprises when he does compile it and just reading through the code should be enough to know what happens when it's compiled.

Oh and as for that program... one thing bugs me...

Code:

---

for (st.i=0; st.i<st.numtests; st.i++)

---

I really don't think it's nessassary for the control variable in the for loop to be a member of the class.

Thanks for the reply and everything works except that the file isn't created.


On a side note, how do you tell where you want to file to be placed?

You specify the path name when you create it. Otherwise it's placed in the current directory which is the directory the program is run from.

Quote:

---

Originally Posted by SlyMaelstrom

About what? People that compile every time they make a new statement?

Not at all. If you need to compile your code and run it to know what it's going to do then you should be studying up better on what you're doing.

---

I disagree. Compiling often is good practice. In C++ there are several gotchas when it comes to syntax. Get someone to remove a semi-colon at the end of a class declaration and see how long it takes you to find! If you compile frequently, you can be fairly sure that the error was introduced in the last few lines you typed.

Quote:

---

Originally Posted by SlyMaelstrom

You should have a very, very sturdy foundation

---

agreed. and the only way to get that is too have a syntactically correct program, which only the compiler can gaurentee.

Quote:

---

before you should ever need to compile.

---

why? the compiler is a tool. use it.

>> If you need to compile your code and run it to know what it's going to do then you should be studying up better on what you're doing.

Actually, if you compile and run the code often you have already learned a valuable lesson. You don't compile and run to know what the code will do (some beginners might, but that doesn't mean that the practice itself is bad). You compile and run to verify that your most recent changes do what you expect and don't screw anything else up.

Quote:

---

Originally Posted by Daved

You compile and run to verify that your most recent changes do what you expect and don't screw anything else up.

---

Thats exactly why I compile and run often. Once you get a base down that compiles and works, you probably don't want to leave compiling off too long so know what recent changes might have screwed something up.

Not everything you program has a guide/chapter/tutorial, like making a stack in college, so you might not know exactly what you're doing, or you might find changes/improvements/etc. that may possibly screw things up.

Sure, guessing might be bad practice (a common example would be pointers), and the person should probably go read up on it more, but thats if they dont go varify, and thats not the fault of compiling often. It more just a beginner thing to not check on what they are unsure of.

Compiling often would also give you a lead on something you aren't sure on, so you can go read up on it, versus leaving it and working with that (say vector) problem which you would be using and having to change a lot of code later because of. (As well as a slur of errors to go along with it).

Quote:

---

Originally Posted by Daved

You compile and run to verify that your most recent changes do what you expect and don't screw anything else up.

---

That's what I disagree with, though. To me, compiling a program every few lines is like speaking in a second language, but asking someone if you said it right, every few sentences. It's not bad when you're learning, but if you're intending to learn the language, you should learn it by knowing it and not by checking yourself constantly. You should have the confidence in what your doing enough to do it without checking your knowledge.

As for syntax errors. Maybe it's just the compilers I use, but they've all given a line number when I get an error, so finding a missing semi-colon or something similar hasn't really been a problem. In fact, I've never had an issue with finding a syntax error thus far in my career. Keep in mind I've never written a program consisting of more than lets say 2000 lines and 4 or 5 classes.

Quote:

---

Originally Posted by SlyMaelstrom

That's what I disagree with, though. To me, compiling a program every few lines is like speaking in a second language, but asking someone if you said it right, every few sentences. It's not bad when you're learning, but if you're intending to learn the language, you should learn it by knowing it and not by checking yourself constantly. You should have the confidence in what your doing enough to do it without checking your knowledge.

---

Even while keeping in mind that not everyone has a well setout C++ beginners book or college course? Many people out there simply reading tutorials wont get indepth information and knowledge, and therefor possibly no confidence.

Either way the problems are going to be corrected though, so checking to make sure its not screwed up would be advantageous and eventually the person should grow confidence.

I could see this with this for basic C++ programs, possibly a stack/heap/anagram/logic problem/text game/etc program. I know I barely compile at all (usually until the program is done) with those. Of course when you get to adding onto the initial design I find the advantage of checking often better than risking it on confidence.

However when you're getting into 3-5 classes when working with openGL/flash/win32, IMO it'd be more of an advantage to check than to be so confident. For example I change a lot of lines to encapsulate some openGL code and which crashed after I finished and to this day I don't know which modification I made screwed it up. I've got a 4 class, 1100 line, project for a windows based website in actionscript and I'm not confident in the least. I did dramastically reprogram it and add 200 lines without compiling, but after that I had a lot of bugs to weed out, and needed to compile often. I probably have different feelings towards it because I seriously never know how Flash is going to react next.

good point Dae.

say I design an application. I start work on it and am confident that I know what every single piece of code does. the application ends up to be 30 lines. I hit compile and get 30 errors (a little co-incidental, but you get the point). now I have to fix these errors, which will usually involve changing some statements/expressions on each line. it would have been easier for me to compile the first 5 or 6 lines when I am finished them then discover the errors. that way I am not left with bunches of errors, and can fix them as they occur, not all at once. the benefit of fixing them while they occur is that I can also fix my design plan at the same time to suit the changes.

point being is that you should not be compiling your code after every single statement, and if that is the case maybe you are in over your head and need to slow down. but compiling something that you are unsure about is not wrong, because chances are the compiler will give you a good explanation about exactly where and why the error occured, which is useful info for fixing it. I'd rather fix the error and then modify my design plan than end up with a mess of code that involves a total re-design.

you might think that compiling oftenly is a waste of time, when if you are not a pro C++ programmer it could actually save you time, in the event that you spend hours coding a 30 line application with 30 errors :eek: :p

>> You should have the confidence in what your doing enough to do it without checking your knowledge.

Again, that's not the reason for doing it. It is not about checking your knowledge. It is about being productive and using the most effective techniques to get the job done. Whether it is a single file program with only a main() function, or a project with 5000+ files, compiling often is a tool to help you find and fix errors faster. This doesn't mean you must take it to extremes. If I write a simple test program to help answer a question here, I won't compile it until I have written the entire thing. But I compile all the time when adding code to the application I work on.

Besides, you said that the advice given by MadCow257 to Starr was horrible practice. If somebody writes a full program and compiles for the first time to get 36 errors, they are certainly not ready to code without compiling often.


>> Thanks for the reply and everything works except that the file isn't created. On a side note, how do you tell where you want to file to be placed?

You might consider starting a new thread with your code and question. The code ofstream a_file("grades.txt"); opens a file called grades.txt in the current directory, which is usually the same directory where the executable file is. You can use a full path to put it in a different directory (e.g. "C:\\grades.txt").

>No, no, no. That's horrible practice.
What utter tosh!!!

For newbies, compiling early and often is a good idea.
Which is better
1. Write a few lines, compile, get a couple of errors which can be fixed and move on.

2. Write pages and pages of code, compile and find way too many errors to deal with, then dump the whole mess on a message board asking for help.

You don't have to run the code every time you compile, and many compilers have a 'check syntax' mode which is very quick.

I don't see why newbies should be doing code that nets them a few errors every few lines. To me, what your saying sounds like "What's better for a skier, go down a double-diamond and stop every few feet so when you fall you go down real easy or go as far as you can so when you fall you break your leg." and my reply to your question would be, they're doing a program too advanced for their level if they're getting that many errors.

Learning something can be a painfully slow process for anyone, but I found from experience (and I don't mean programming) that it's better to learn at an appropriate pace and learn it well before you move on. And what that means is "no errors at all". So it seems impractical for me to see a guy running into so many errors when if he was learning properly he should only be having trouble with the current task he is learning.

You must know how people who go to these tutorials are. They start with lesson one and are on to lesson 10 within the hour. The next morning they're learning OpenGL and they don't even know how to properly make a loop. Programming, in theory, seems like a very simple thing, especially to intelligent people, which most of the people on this forum are. But it's completely different in practice and the reason we see so many errors in such a basic program is not because the OP was in over his head and didn't compile enough, it's because he may have rushed himself and got to his current program before he should have.

Anyway, that's just how I feel on the subject. Feel free to disagree and push your perspective, I'm willing to hear it. I've listened to all your points thus far, it's just I've heard it all before and thought about it. To me, it just doesn't seem like good practice.

Using the compiler as a substitute for knowing your language and being careful about spelling is WRONG WRONG WRONG.

Personally I hate every compiler error, they indicate a flaw in my knowledge of the language constructs I try to use which means my understanding of the language itself is incomplete.
While they can be helpful to point out things like honest typos, those too I should have caught.

And when you're working on large programs where a compilation cycle means claiming resources on a server for several hours or days you'd better make sure your code compiles first time or you're soon looking at some angry colleagues.
And no, that's not at all an exaggeration, I've worked on projects where there were millions of lines of code over hundreds of sources which would take 48-72 hours to do a full build on a dedicated machine. If you aren't sure of your code, you don't request it be built because basically there can be only a single build per week starting friday afternoon and hopefully complete sometime monday morning.

Quote:

---

Originally Posted by Salem

>No, no, no. That's horrible practice.
What utter tosh!!!

For newbies, compiling early and often is a good idea.
Which is better
1. Write a few lines, compile, get a couple of errors which can be fixed and move on.

2. Write pages and pages of code, compile and find way too many errors to deal with, then dump the whole mess on a message board asking for help.

---

Neither.
Write a little bit of code you understand. And only add code you are reasonably comfortable with, don't just write and write and hope it may compile.
Write and understand and KNOW it will compile.
If you then get runtime errors there was something wrong with your logic and understanding, but you at least got syntactically correct code.

If you can't do that, you're not yet at the stage where you should write large programs anyway.

I usually compile after I finish a function or two. If I am doing something simple I usually don't compile until the end of the program.


I use this line of code but when I go to the C:\ drive the file is not there.
fstream a_file("C:\grades.txt");

>> fstream a_file("C:\grades.txt");

You didn't copy my suggestion correctly. You need to use \\ instead of \ because \ is an escape character.

Sly, to be honest, if the largest program you've ever written is 2000 lines, you're not really qualified to give advice on this topic.

Quote:

---

Originally Posted by jwenting

I've worked on projects where there were millions of lines of code over hundreds of sources which would take 48-72 hours to do a full build on a dedicated machine. If you aren't sure of your code, you don't request it be built because basically there can be only a single build per week starting friday afternoon and hopefully complete sometime monday morning.

---

I've worked on similar projects (a 5 million line mainframe travel reservation system, to be precise) where a full build takes a day or two. In that situation, there are several solutions.

1) No program that big should produce a single monolithic executable. The project should be refactored to build several smaller dlls, or use some sort of component system (CORBA, COM, .NET, take your pick)

2) If that can't happen (and obviously it's a big project so it takes time), YOU ABSOLUTLEY MUST COMPILE OFTEN. Not build, compile. If you submit a change for the weekly build that you haven't compiled, you're in trouble.

3) All of your changes should also be built into a small unit-testable module, which can be built quickly.

Quote:

---

Originally Posted by jwenting

Personally I hate every compiler error, they indicate a flaw in my knowledge of the language constructs I try to use which means my understanding of the language itself is incomplete.
While they can be helpful to point out things like honest typos, those too I should have caught.

---

Sorry, that is complete bull......... A good C++ programmer will design his classes in such a way that even a syntactically correct but incorrect use will generate a compile-time error.

for example, to borrow from Scott Meyers (effective C++ 3rd ed item 18) you could design a Date class like this

Code:

---

class Date
{
    int day, month;
public:
    Date(int d, int m);
};

---

but then an american comes along and goes

Code:

---

// hmm need a date for christmas
Date xmasDay(12, 25); // oh crap

---

whereas you can instead use something like

Code:

---

class Date
{
public:
    enum Month
    {
        jan, feb,mar // etc
    };
    Date(int d, Month m);
private:
    int  day;
    Month month;
};

// hmm need a date for christmas
// Date xmasDay(12, 25); // hmm compiler error
Date xmasDay(25, Date::dec); // fixed before runtime!! woohoo

---

obviously this is a trivial example (and that is bordeline pseudo-code, so don't bother criticizing the style), but it illustrates the concept of using the compiler to enforce design constraints

I agree with whoever said "only write a few lines and then compile". But I would modify it to: "Only write as many lines as you are absolutely certain are correct, and when you write a line that you aren't sure about, compile to check it." I've heard professors give this advice before, and I generally agree. As you get more experienced, you naturally will go longer and longer without compiling, and then, even when you screw up and get 103 compile errors, it's still pretty easy to clean up in less than 5 minutes.

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

Quote:

---

Originally Posted by SlyMaelstrom

You must know how people who go to these tutorials are. They start with lesson one and are on to lesson 10 within the hour. The next morning they're learning OpenGL and they don't even know how to properly make a loop.

---

If they were smart, they bookmarked the tutorials, and can referance them to help fix their code. Yes, some people are impatient and want to jump into game making right away (I assume that is why you chose OpenGL as an example) but sometimes, starting with the complicated stuff makes things easier for people in the long run. There is a sequence one CAN go through to learn a language, but no one agrees on the exacts. Almost all will agree, start in console and move from there. Depending on your background (*nix vs windows) the console is the important one and GUIs are just extra.

But most people come from a M$ enviorment and believe that GUI is the most important part so they rush to it. I don't think shooting them down for the style is a good idea, let them learn the lesson, and maybe, they will dedicate enough and learn that stuff first (probably not though) I learned a lot from trying to do things beyond my ability, and compiling every 100 or so lines. Now I can go 1000 lines and not need to compile very often (of course I still have some minor syntax errors especially when I am learning new APIs and or a new language) My largest program is a 15k line program, while that is small compared to the 5mil (OOP was made for a reason) line programs you guys have worked with, I don't think it makes me any less qualified to comment on early programming learning.

Sticking to the VERY basics one is likely to get bored when learning, I prefer to challenge myself, which makes me a little more likely to make mistakes, making compilinig more often useful. In the workplace, on huge applications, people are no longer writing programs with the near sole purpose of learning, they are writting them because they are being paid and are professionals. So please don't try and compare that to the learning process. That is like saying one should be completely professional and adultlike while still a child.

Quote:

---

Originally Posted by Starr

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

---

Never used VS, but building compiles all the linked files each time, compile will just rebuild the partst that have changed. Atleast that is my understanding. Just try the difference between compile and rebuild.

Quote:

---

Originally Posted by Starr

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

---

'compiling' means compiling an individual .cpp to an object file.
'building' refers to the process of compiling every .cpp that needs it (i.e. if it or a header it includes has changed) and then linking all the object files to produce an exe (or a dll or a lib)

obviously building takes a lot longer then compiling, especially once you get past more then one or two source files. In fact the term building can often encompass building several projects (libraries and exes) at once.

Wraithan, I never said you weren't qualified to comment on 'early programming learning'. However, if your experience is limited to a 2k line program in C++, you shouldn't go around making authorative statements about best practice for building in C++, as Sly was.

Chaos, you've gotten so far off the inital subject matter it baffles me. Here we are looking at a situation where a guy has a program under 100 lines and someone said "compile often" to it. 100 lines, not 1,000,000 or more. I in no way made any statement that says how often you compile that size of a program as I have no way of making that judgement. If you were to tell me that you should compile everytime you make a minor change on a system that's currently running and being updated, I'd agree with you. That's not what we're discussing though. So, if you want to say I have no say on this matter and I was making conclusions on things I have no experience in then you better know what I and everyone else here is talking about.

What is the point of typing in 100+ lines and then compiling to get 100+ errors, when the average noob can't even write "hello world" without generating syntax errors.

As IfYouSaySo summarised, you program within your ability of making mistakes and being able to fix the result.

Sure, the pros can type all day and generate only a few errors, most of which will be obvious typos.

Whilst the average pro could probably write a module off the bat and make it compile first time, there is little chance that it would run perfectly each time, nor for example pass lint first time.

I don't know if you remember the early MS Office spellcheck that didn't highlight misspelled words. It just had the ability to run a program and it would check your errors. Did you ever use it?

How often did you run it? Every line? I know that I would only run it when I was finished, and that's no matter how many errors I knew I would have. It's a time on task matter. I keep my mind on writing the code, then I go back and fix errors. If I make an update to code, I make the update, then I compile to see if it all went well.

To me it doesn't matter how new you are, you should never be doing code that generates more errors than you can handle. If you can't get through a "Hello World" program with little error then perhaps you shouldn't go further than that until you can. This is my whole point. People do something, and make mistakes, they do it again, and make less mistakes but still a decent amount. An amount that they just brush off as small mistakes and then they move on. They continue the same method piling on mistakes until they reach a program and get overwhelmed. I don't like seeing people in this situation and it doesn't have to happen this way.

Please don't compare what I'm saying to anything but a learning programmer compiling a lot. I'm not talking about updating and maintaining a project that's in use and needs to be coded perfect at all updates. If you want to tell me you should compile all the time with that, then I say fine. You're right. This is different though, I'm talking about a learning process, not an efficiency or precision thing.

Obviously, many new programmers must complete homework assignments, so sticking to code that matches their abilities doesn't work for them. This is a common problem. One example might be this case, where the OP had 36 compiler errors after attempting to code the entire solution.

One piece of advice that would have helped the OP and would help others in a similar situation is to compile more often. Write less code before you compile it and make sure that your thinking is correct. Note that you don't compile your code more often to find out what the code you wrote does, but rather to verify that it does what you think it does.

>> No, no, no. That's horrible practice.
All else aside, that comment implied that a programmer should code an entire solution before compiling. IMO (and the opinion of most everybody else), that is completely wrong.

We are all human, and humans make mistakes. The benefits of finding and fixing mistakes earlier rather than later far outweigh any disadvantages of new coders relying on compiling and running without understanding their code.

Well, if it helps I don't take any class. I teach myself.


Now I am getting a wierd error when I try to run a program, I added a new function to obtain the averages of the grades entered. But I get a warning on build and an error when trying to run it. It says that I am using an uninitialized variable and it says the variable that I am using that isn't initialized is the instance of the Student class I made. It is starting to irritate me a bit.

post the code.

Ok, here is the error: "warning C4700: uninitialized local variable 'stude' used"

And here is the code (You guys are so great! :))

Code:

---

#include <iostream>
#include <cmath>
#include <fstream>

using namespace std;

class Student
{
public:
        void calculate();
        int writeToFile();
        void average();
        char name[20];
        int age, grade;
        int numtests;
        int i;
        int *iPtr;
        float avg;
};

int main()
{
        Student stud;
        //Ask for students name
        cout << "Enter the student's name: ";
        cin.get(stud.name, 20, '\n'); 
        cout << "Enter the student's age and grade seperated by a space: ";
        cin >> stud.age >> stud.grade;
        stud.calculate();
        stud.average();
        stud.writeToFile();
        cout <<"\n";
        return 0;
}


//Calculate grades
void Student::calculate()
{
        Student st;
        cout << "Enter the number of tests you are entering: ";
        cin >> st.numtests;
        st.iPtr = new int[st.numtests];
        for (st.i=0; st.i<st.numtests; st.i++)
        {
        cout << "Enter test score #" << st.i + 1 << " : ";
        cin >> st.iPtr[st.i];
        }
}

//Calculate Averages
void Student::average()
{
        Student stude;
        cout << "Calculating the average of your percentages.....\n";
        for (stude.i=0; stude.i < stude.numtests; stude.i++) //The warning points to this line
        {
                stude.avg += stude.iPtr[stude.i];
        }
        stude.avg /= stude.numtests;
        cout << "The agervage of the percentiles = " << stude.avg << endl;
}


//WritetoFile function
int Student::writeToFile()
{
        Student stu;
        cout << "Now writing data to file.....";
        fstream a_file("C:\\grades.txt");
        if (a_file.is_open() )
        {
                cout << "The file opened incorrectly, program terminating.";
                return 0;
        }
        else
        {
                a_file << "The student's name is: " << stu.name << endl;
                a_file << "The student's grade is: " << stu.grade << endl;
                for (stu.i = 0; stu.i < stu.numtests; stu.i++)
                {
                        a_file << "Test score #" << stu.i + 1 << " is " << stu.iPtr[stu.i] << endl;
                        delete [] stu.iPtr;
                }
                a_file << "The average of the test grades is: " << stu.avg << endl;
                a_file.close();
                cout << "Data finished writing and file closed......";
        }
        return 0;
}

---

Its because the initialization of numtests in calculate() is to a local object, which gets deleted at the end of that function. So that object you've created in average() has a fresh numtests (not the one from calculate, unless you passed it by reference). However, since you are doing all of this inside Student's methods you can use Student's variables without declaring an object of Student. Thats the whole point of encapsulation.

So change it to something somewhat like below.

Code:

---

//Calculate grades
void Student::calculate()
{
        cout << "Enter the number of tests you are entering: ";
        cin >> numtests;
        iPtr = new int[numtests];
        for (i=0; i<numtests; i++)
        {
        cout << "Enter test score #" << i + 1 << " : ";
        cin >> iPtr[i];
        }
}

//Calculate Averages
void Student::average()
{
        cout << "Calculating the average of your percentages.....\n";
        for (i=0; i < numtests; i++)
        {
                avg += iPtr[i];
        }
        avg /= numtests;
        cout << "The agervage of the percentiles = " << avg << endl;
}


//WritetoFile function
int Student::writeToFile()
{

        cout << "Now writing data to file.....";
        fstream a_file("C:\\grades.txt");
        if (a_file.is_open() )
        {
                cout << "The file opened incorrectly, program terminating.";
                return 0;
        }
        else
        {
                a_file << "The student's name is: " << name << endl;
                a_file << "The student's grade is: " << grade << endl;
                for (i = 0; i < numtests; i++)
                {
                        a_file << "Test score #" << i + 1 << " is " << iPtr[i] << endl;
                        delete [] iPtr;
                }
                a_file << "The average of the test grades is: " << stu.avg << endl;
                a_file.close();
                cout << "Data finished writing and file closed......";
        }
        return 0;
}

---

Some other advice would be:

- Like said before, I'd lose the i member variable, and simply create a local on in the functions.

- Think about making the member variables private, so only the methods access them, and make methods to retrieve the variables if necessary (getter/setters).

- You might want to make the member variables prefix m_ so that you can easily tell the difference between local ones.