Programs that change behaviour under debug and normal execution are just as likely to change behaviour on a different machine, a different day, a different version of windows or anything in fact that changes teh execution environment.
The program is flawed in all cases, it is just that the result of the flaw is non-deterministic because the data that is being corrupted in different in all cases - sometimes catastrophic and detectable by teh OS and sometimes not.
The solution is simply to take care of your code quality and safety especially with respect to pointer manipulation, array bounds, and dynamic memory usage.
Unfortunately posting fragments of code is not always helpful, the error could have occurred elsewhere and the result of some later operation on already corrupted data causes the crash.
From the code you posted for Meet_team::retrieve_team_athletes() I assume you have confirmed that the index pat->meet_ath_ID_num does not exceed the bounds of Pt_ath[]. In that case my suspicion would fall next onto the Athelete::Athelete() constructor, and possibly the validity of the pmt parameter you are passing to Meet_team::retrieve_team_athletes(), since these occur before the crash location and you have not provided any information on theses.
As a general comment, creating arrays with 'magic-numbers' is an error prone practice that never yields maintainable code. You should use static const integers (or less desireably #define'ed macros) to specify array sizes. That way you have a value which you can use to add bounds checking code to avoid errors, as well as being able to easily modify the capacity of your arrays. A possibly better approach would to be use <vector> types rather than arrays, since these are intrinsically much safer that arrays and can reduce the necessity for bounds checking by use of exception handling.
I suspect that the reason that this thread has gone on for so long is that you have not yet posted the code that contains the actual error, and also because you have posted so much code there is so much else to discuss and critique that is just missing the point and distracting from the problem in hand.
I think the solution lies in helping you learn effective debugging and fault finding techniques, since such problems are difficult to find from just fragments of the code when you have no idea where the real problem lies. If you post all teh code, it is likley that no one will be willing to trawl through it all or even build it, and you will just get random stabs at specific points in your code that may or may not have anything to do with this specific problem.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
your feedback isn't of much use from a programming point of view, as you still didn't provide any details about our suggestions to determine what exactly the nature of your program is (that is, whether it's dependent on the underlying data files or if it's independent of the data).
This is the only way to determine where you need to continue troubleshooting your problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Programs that change behaviour under debug and normal execution are just as likely to change behaviour on a different machine, a different day, a different version of windows or anything in fact that changes teh execution environment.
The program is flawed in all cases, it is just that the result of the flaw is non-deterministic because the data that is being corrupted in different in all cases - sometimes catastrophic and detectable by teh OS and sometimes not.
The solution is simply to take care of your code quality and safety especially with respect to pointer manipulation, array bounds, and dynamic memory usage.
Unfortunately posting fragments of code is not always helpful, the error could have occurred elsewhere and the result of some later operation on already corrupted data causes the crash.
From the code you posted for Meet_team::retrieve_team_athletes() I assume you have confirmed that the index pat->meet_ath_ID_num does not exceed the bounds of Pt_ath[]. In that case my suspicion would fall next onto the Athelete::Athelete() constructor, and possibly the validity of the pmt parameter you are passing to Meet_team::retrieve_team_athletes(), since these occur before the crash location and you have not provided any information on theses.
As a general comment, creating arrays with 'magic-numbers' is an error prone practice that never yields maintainable code. You should use static const integers (or less desireably #define'ed macros) to specify array sizes. That way you have a value which you can use to add bounds checking code to avoid errors, as well as being able to easily modify the capacity of your arrays. A possibly better approach would to be use <vector> types rather than arrays, since these are intrinsically much safer that arrays and can reduce the necessity for bounds checking by use of exception handling.
I suspect that the reason that this thread has gone on for so long is that you have not yet posted the code that contains the actual error, and also because you have posted so much code there is so much else to discuss and critique that is just missing the point and distracting from the problem in hand.
I think the solution lies in helping you learn effective debugging and fault finding techniques, since such problems are difficult to find from just fragments of the code when you have no idea where the real problem lies. If you post all teh code, it is likley that no one will be willing to trawl through it all or even build it, and you will just get random stabs at specific points in your code that may or may not have anything to do with this specific problem.
Clifford
I'm at home now using Dev-C++ 4.9.9.2 on a Gateway with Windows 98.
I tried running the program (without debug) and it appears to run fine. Running with debug seems to work fine also.
I will try rebuilding an empty project when I get back to school/work.
From what I have seen with couts, the problem is when I use the getline function.
your feedback isn't of much use from a programming point of view, as you still didn't provide any details about our suggestions to determine what exactly the nature of your program is (that is, whether it's dependent on the underlying data files or if it's independent of the data).
This is the only way to determine where you need to continue troubleshooting your problem.