-
1 Attachment(s)
Heap Corruption during run time.
Hello, I am having a problem with my code. I am trying to delete an array, after I created a bigger one, and copied all the values from the previous to the new one, but when i try to delete the old one, I get : heap corruption detected after normal block. Please help me. Here is the code:
this is the add function:
Code:
bool IntArrayList::add(Number& num)
{
if(m_Arr[0] == NULL)///If array is empty put the first element at 0 index
{
m_Arr[0] = #
m_Size += 1;
return true;
}
else
{
int in_place = SearchInsertPlace();///find the place where you store another element
if(in_place != -1)///there is still place available
{
m_Arr[in_place] = #
m_Size += 1;
return true;
}
else///if no free places, create new array
{
m_Arr = CreateNewArray(m_Arr);
in_place = SearchInsertPlace();
m_Arr[in_place] = #
return true;
}
}
}
this is the function that creates the new array:
Code:
Number** IntArrayList::CreateNewArray(Number** arr)
{
m_ArraySize *= 2;
Number** newArray = new Number*[m_ArraySize];
for(int i=0 ; i<m_ArraySize ; i++)
newArray[i]=NULL;
for(int i = 0 ; i < m_Size ; i++ )/// creating new array.
{
newArray[i] = m_Arr[i];
m_Arr[i]=NULL;
}
//for(int i = 0 ; i < m_Size ; i++)/// delete old array.
// delete m_Arr[i];
delete []m_Arr;
return newArray;
}
thanks!
-
Re: Heap Corruption during run time.
In your add function, you're passing in a Number& and storing the address. Since we have to guess here, I'd guess that the number you're passing in is a local that goes out of scope, so you're storing and trying to delete the address of an object that no longer exists.
-
Re: Heap Corruption during run time.
thanks, so I don't need to delete the old one?
-
Re: Heap Corruption during run time.
You shouldn't store the address of a local object that goes out of scope. If you're doing something like
Code:
Number num;
myList.add(num);
you're writing buggy code. As soon as num goes out of scope, you have an invalid pointer.
-
Re: Heap Corruption during run time.
Why not just use the STL std::vector?
-
Re: Heap Corruption during run time.
can't use the stl. it's a homework, so they want us to write everything by ourselves to practice.
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
EdwardKes
can't use the stl. it's a homework, so they want us to write everything by ourselves to practice.
But with the questions you're asking, why was this given as an exercise, especially with a complex language such as C++? I bet that 100% of the students will get something wrong.
The only persons who can write a dynamic array class properly are intermediate (and even that may not be enough) to advanced C++ programmers. I have yet to see a student or beginner write a dynamic array class properly. The student versions are either always buggy, or have such glaring holes that are easily demonstrated by simple test programs.
What I'm saying is that I hope that the teacher sees the attempts and points out the mistakes.
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
EdwardKes
Hello, I am having a problem with my code. I am trying to delete an array, after I created a bigger one, and copied all the values from the previous to the new one,
You should really post all of this code instead of just describing it. We don't know if that code also has problems.
In addition, where is your test program? Another thing that students or beginners tend to do is write test programs that will avoid the bugs in the code, giving the false impression that the code "works".
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
What exactly did the assignment require? Were any of the class definitions/methods provided or have you devised your own?
In a c++ class I wouldn't expect a member function to have a definition of
Code:
Number** IntArrayList::CreateNewArray(Number** arr)
I would expect a private function with a definition something like
Code:
void IntArrayList:: ResizeArray()
In add you have
Code:
m_Arr = CreateNewArray(m_Arr);
If I understand your class (and it is always better and of much more use to post the whole program as suggested by Paul), m_Arr is a member variable of the class - so why is CreateNewArray taking as argument a variable to which it has access and returning a pointer to a pointer which is then assigned back to the class member variable?:confused: How is m_Arr defined in the class?
-
Re: Heap Corruption during run time.
Please tell your teacher that they need to stop giving you guys idiotic restrictions that only serve to make you work AGAINST established industry standards. It's teachers like that which end up giving us improperly prepared recruits where the first thing we have to do when they come to work for us is weeks of trying to stomp out bad coding practices.
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
EdwardKes
Code:
bool IntArrayList::add(Number& num)
{
if(m_Arr[0] == NULL)///If array is empty put the first element at 0 index
{
m_Arr[0] = #
m_Size += 1;
return true;
}
else
{
int in_place = SearchInsertPlace();///find the place where you store another element
if(in_place != -1)///there is still place available
{
m_Arr[in_place] = #
m_Size += 1;
return true;
}
else///if no free places, create new array
{
m_Arr = CreateNewArray(m_Arr);
in_place = SearchInsertPlace();
m_Arr[in_place] = #
return true;
}
}
}
There are so many things wrong with this both from a technical POV as a design POV that I'm not even sure I know where to start.
lets have a start
technical: why are you testing for m_arr[0] being NULL when the obvious check is if size == 0
design: why does your class even assume there will always be an allocated array, it should handle "empty" better by not requiring an allocated array when no such array has been needed yet.
technical: m_Arr[0] = #
why are you storing a pointer to a local stackbased variable ?
design: why does an add function return true, when it makes more sense to return an index to the added array element or a iterator to the added element.
technical SearchInsertPlace();
it's unclear if this function only does a search or also makes room for the add. The name seems to indicate it doesnt. Byt in the "there is still place" branch there doesn't seem to be any code that takes care of moving all the elements up by one.
design: this also assumes that the search functions knows that there isn't any more room, so either it's name is in approproate, or you have gaping functionality holes here.
design: every possible branch in your code seems to return true, so what's the point of always returning the same value ?
I can't even tell if all of this is a matter of incomplete/confusing assignment given by the teacher, or you not properly following said assignment.
-
Re: Heap Corruption during run time.
I agree. The assignment is not meant for beginners, and possibly not even for intermediate programmers. Why teachers in beginner or close to beginner classes seem to always give these type of assignments is beyond me, unless the teacher is trying to prove a larger point when it comes to C++.
As I stated, I bet that 100% of the students in this class makes some sort of mistake, even ones that the teacher cannot detect (but some of us here would see at first glance). All assignments like this do is give the student who thinks they got a working program believe that the program actually is really working or usable, and not wrought with issues, mistakes, etc..
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
OReubens
Please tell your teacher that they need to stop giving you guys idiotic restrictions that only serve to make you work AGAINST established industry standards. It's teachers like that which end up giving us improperly prepared recruits where the first thing we have to do when they come to work for us is weeks of trying to stomp out bad coding practices.
I agree. IMO part of the 'problem' is that whilst students are taught how to write correct c++ syntax, they are not taught properly how to design a program - what the classes should be, what are the required functions, what are the desired interfaces of the classes/functions etc. Also some teachers try to provide non-trivial assignments that use the knowledge that has been taught so far which can involve programming 'contortions' to do something that is either already present in the language (including the STL) or which in the real world would be programmed using a feature of the language that has not yet been covered on the course so the students don't know about it - or worse have been told not to use it. Also some c++ courses do not cover the STL or templates in any great detail so students who have passed the course (and often have a certificate) don't even know all of the facilities available that can be used - never mind how best to use them! No wonder so many new recruits have bad coding practices. I feel sorry for the students as some are being badly let down by their course tutors. I often wonder exactly what knowlege these 'teachers' have themselves. I once came across a c 'teacher' who was literally teaching from a book and whose knowledge of c was one chapter ahead of what was being taught!
IMO what is needed is a proper formal accreditation scheme for c/c++ teachers (similar to Microsoft MCT).
-
Re: Heap Corruption during run time.
IMO this is the reason why Java is more readily taught in schools over C++. The Java student is never assigned anything like this. Not only that, the Java student is taught to use what is available in the JDK, therefore the backflips and gymnastics that teachers enforce onto a C++ beginner practically never occurs for the Java student.
In short, the Java student is creating usable programs, while the C++ student is wasting time creating buggy "IntArrayLists".
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
Paul McKenzie
IMO this is the reason why Java is more readily taught in schools over C++. The Java student is never assigned anything like this. Not only that, the Java student is taught to use what is available in the JDK, therefore the backflips and gymnastics that teachers enforce onto a C++ beginner practically never occurs for the Java student.
In short, the Java student is creating usable programs, while the C++ student is wasting time creating buggy "IntArrayLists".
Probably because Java/JDK is taught integrated as a 'whole' - whereas c++ tends to be taught as four distinct parts 'the c part of c++, classes, STL and Templates. Many courses just do the 'c' part and elementary classes - with proper class design, STL and templates only getting a cursory mention. IMO c++ should be taught the same way as Java - as an integrated whole with students using - and encouraged to use - all of the available features as needed.
-
Re: Heap Corruption during run time.
but there's no reason why the java approach can't be applied to C++ just as easily. C++ viewn as just "C with objects", without the STL, without templates and without all the other things that separate it from it's granddaddy C (C++ has since evolved on it's own path not even following C anymore) is a concept that is outdated by many years now. THis might have been a useful approach when nobody knew C++ and C++ was still little more than a preprocessor for C. But it's gone way beyond that now.
It's like teaching someone to drive a car... By first telling them how to tend to a horse and making them drive around in a horse carriage for a whole year.
Even if you did teach the class by first teaching C, and then migrating over to C++, this assignment is bad because it makes not much sense if you look at it from a C p.o.v. and it's silly as a C++ p.o.v. because you're better off using STL.
I'm not saying there is no merit to teaching someone how to write a container, but then you'd do this because you want to do something STL doesn't provide and even then you'd make sure that students know about ths STL approach to things, so that the container they need to design is usable with the rest of the STL algorithms etc. (hardly a beginners class but hey).
-
Re: Heap Corruption during run time.
Quote:
but there's no reason why the java approach can't be applied to C++ just as easily.
Agreed, but try getting the teachers to do this!:cry:
PS I think the benefit of the java approach is starting to filter through as there is now an 'early object' version of the well known Deitel 'c++ How to program' book that also covers c++11 (although I haven't yet seen a copy so can't comment upon how good it is).
http://www.amazon.co.uk/How-Program-...0008707&sr=1-2
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
2kaud
Agreed, but try getting the teachers to do this!:cry:
Then you get those who will say "but C++ programmers who learn the "high-level" way without learning the low-level details first will not be good programmers".
The problem with that statement is that this "C++ programmer who doesn't know low-level details" doesn't exist, or I have yet to meet such a programmer. It's plain foolish to think that a C++ programmer who knows how to use design patterns, STL, boost, MFC, etc. to structure a well-written, modular, easily maintained program can't manipulate a few pointers or know how to use char*, dynamically allocated memory, strcat or strcmp() properly.
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
Paul McKenzie
Then you get those who will say "but C++ programmers who learn the "high-level" way without learning the low-level details first will not be good programmers".
But if you are using c++ 'correctly' - ie high level - how often do you need the low-level detail? IMO if you are regularly using the 'low level detail' (unless you really are twiddling bits) then you are not using c++ properly.
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
2kaud
But if you are using c++ 'correctly' - ie high level - how often do you need the low-level detail? IMO if you are regularly using the 'low level detail' (unless you really are twiddling bits) then you are not using c++ properly.
I know. But you still get those responses from die-hards who believe that teaching low-level details should be done first.
So the way I counter their argument is to show me this (mythical) C++ programmer who, if need be, can't write a module or get involved in some low-level coding. So far, no such programmer can be produced.
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
-
Re: Heap Corruption during run time.
Frankly guys, how is the OP to benefit from the last posts? I feel that many threads ends up in a a lot of posts that blame the teachers of teaching the wrong stuff and giving the wrong type of excercises but that's not what the board is about is it? Shouldn't every post be focused on trying to help the OP the best we can?
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
S_M_A
Frankly guys, how is the OP to benefit from the last posts? I feel that many threads ends up in a a lot of posts that blame the teachers of teaching the wrong stuff
I'm still waiting for the OP to post the other functions instead of descriptions of what he/she did. That is what I asked for, and so far, nothing.
Also, a test program to see how these classes and functions are being used and called wasn't posted so we see what the flow was that ultimately led to the crash.
Regards,
Paul McKenzie
-
Re: Heap Corruption during run time.
Quote:
Originally Posted by
Paul McKenzie
I'm still waiting for the OP to post the other functions instead of descriptions of what he/she did. That is what I asked for, and so far, nothing.
Also, a test program to see how these classes and functions are being used and called wasn't posted so we see what the flow was that ultimately led to the crash.
Regards,
Paul McKenzie
I agree with S_M_A. Railing against the nature of the assignment doesn't really help the student. We who have been doing it for a while, know how goofy some of these assignments are, but the student is still required to implement them.
Regardless, I pointed out what I think is the likely cause in post #2. It would be kind of nice if the OP would comment on that.
-
Re: Heap Corruption during run time.
Maybe we should ask for a "What C++ teachers should teach and why" forum (and of course the other langauges as well)? After all, we all do represent the industry and we do know what we want people that just graduated to know.