and it errors when call makeempty() function
when i run it on borland C++ 3.0 it is ok but Dev it not...
i don't know why that..
could you help me to fix it?
thanks !
{sorry my english is not very good! :X)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i found a simple problem .head is not a node ,head is a point .when list has only point ,head ->prev can not be NULL ,because head doesn't have it ...
the problem is as simple as i can not find it...
thanks for all !!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-09
In Borland C++ your code compiles with warnings:
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
p1.c:
Warning W8027 p1.c 72: Functions containing while are not expanded inline
Warning W8027 p1.c 82: Functions containing while are not expanded inline
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
!! OK. Compilation C++ (-Vd)
It compiles OK on gcc, it just crashes when you run it. It crashes on the last call to delete_first() in the while loop. If you remove the loop and replace it with eight calls to delete_first() it's fine, and you get a '0' when it displays the list. If you add a ninth call it crashes. It can't delete the final element in the list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I was just speaking in plain English. We can't all be as clever as you are. If something deletes items from a list one at a time until it gets to the last item then fails, we normal people would say "it can't delete the final element in the list". I was merely trying to point him to the particular function call that caused it to crash for me, namely the call to delete_first() when the displayed list has been reduced to one element. Sheesh.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-10
If you are going to reinvent teh wheel by creating your own linked list at least give it a different name that teh one provided in th e standard library!
You did know that this functionality was part of the standard library already right!? ;-)
I feel compelled to point out the use of deprecated headers is discouraged (not least by the conspicuous warning message emitted by the compiler when you use them!).
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i asked my teacher and my teacher can not expland why that ...
he only said :"we are human ,and computer is computer ,it is not human so some program u write it can not run right with your mind ...."
i think he is right...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your "teacher" is an idiot.
The code may compile.
The code has a bug.
The executable may run to completion.
The executable has a major bug.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-11
Maybe it was lost in translation but your teacher comes accross as a bit of a cod-philosopher. This is not teh time for philosophy. What I imagine he was saying was that teh computer does exactly what you tell it and the trouble is what you are telling it is not what you think you are telling it. Trust me - he is not blaming the computer! ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-11
OK enough nonsense.
In these lines:
> head=head->next;
> head->prev=NULL;
what do you suppose happens if head->next is NULL? Answer: head->prev would be an attempt to dereference a null pointer.
The following at least prevents it from crashing.
> head = head->next ;
> if( head != NULL )
> {
> head->prev = NULL;
> }
But I still would not like to bet that the code is correct - I haven't looked that hard. The problem becomes obvious if you were to use a debugger. Why don't programming classes ever seem to teach this essential tool!?
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-11
> when i run it on borland C++ 3.0 it is ok but Dev it not...
It ran but it was still wrong. The 32bit code generated by Dev-C++ (or rather Mingw/GCC) allows better use of the processors memory protection mechanisms so will trap errors that are ignored in 16 bit code. This is not a good thing, in the 16 bit code you will find out about the error at some point, the trouble is it will be nowhere near the actual cause of the problem, and so will be very hard to debug. But you need the debugger in the first instance to tell you exactly where the run-time error occurred. Unfortunately Dev-C++'s debugger sucks - I used MS VC++2005 Express.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i even didn't know why i'm wrong .
and this is my think...
<a href="http://photobucket.com" target="_blank"><img src="http://i117.photobucket.com/albums/o48/anhtrue/test.jpg" border="0" alt="Photo Sharing and Video Hosting at Photobucket"></a>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i even didn't know why i'm wrong .
and this is my think...
<a href="http://photobucket.com" target="_blank"><img src="http://i117.photobucket.com/albums/o48/anhtrue/test.jpg" border="0" alt="Photo Sharing and Video Hosting at Photobucket"></a>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i writed a programma :
and it is source code:
include <iostream.h>
include <conio.h>
class list;
class node
{
private:
int data;
node next;
node prev;
public:
node ()
{
data=0;
next=NULL;
prev=NULL;
}
node (int newdata)
{
data=newdata;
next=NULL;
prev=NULL;
}
friend class list;
};
class list
{
private:
node *head;
public:
list():head(0){}
};
int main()
{
list alist;
for (int i=0;i<10;i++)
alist.insert_first(i);
alist.display();
cout<<endl;
cout<<"call delete_first() function!"<<endl;
alist.delete_first();
alist.display();
}
and it errors when call makeempty() function
when i run it on borland C++ 3.0 it is ok but Dev it not...
i don't know why that..
could you help me to fix it?
thanks !
{sorry my english is not very good! :X)
thanks for all helps!
i have just fixed this problem .
and this is correct code :
bool delete_first()
{
if (head==NULL)
{
cout<<"no object to delete"<<endl;
return 0;
}
else
{
node * temp=head;
if (head->next!=0)
{
head=head->next;
head->prev=NULL;
delete temp;
}
else
{
head=NULL;
delete temp;
}
}
}
i found a simple problem .head is not a node ,head is a point .when list has only point ,head ->prev can not be NULL ,because head doesn't have it ...
the problem is as simple as i can not find it...
thanks for all !!!
In Borland C++ your code compiles with warnings:
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
p1.c:
Warning W8027 p1.c 72: Functions containing while are not expanded inline
Warning W8027 p1.c 82: Functions containing while are not expanded inline
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
!! OK. Compilation C++ (-Vd)
And run with this output
9 8 7 6 5 4 3 2 1 0
call delete_first() function!
8 7 6 5 4 3 2 1 0
call makeempty() function!
After that it gives a fatal error and abort the execution. So, if the GNU gcc compiler gives you a compile-time error, is clever that the Borland one.
It compiles OK on gcc, it just crashes when you run it. It crashes on the last call to delete_first() in the while loop. If you remove the loop and replace it with eight calls to delete_first() it's fine, and you get a '0' when it displays the list. If you add a ninth call it crashes. It can't delete the final element in the list.
"It can't delete the final element in the list."
Wrong. The code is, as virtually always, the problem.
Clever programmers list to me, but do not follow me.
Soma
Sorry, I was just speaking in plain English. We can't all be as clever as you are. If something deletes items from a list one at a time until it gets to the last item then fails, we normal people would say "it can't delete the final element in the list". I was merely trying to point him to the particular function call that caused it to crash for me, namely the call to delete_first() when the displayed list has been reduced to one element. Sheesh.
If you are going to reinvent teh wheel by creating your own linked list at least give it a different name that teh one provided in th e standard library!
You did know that this functionality was part of the standard library already right!? ;-)
I feel compelled to point out the use of deprecated headers is discouraged (not least by the conspicuous warning message emitted by the compiler when you use them!).
Clifford
thanks for help !!!
i asked my teacher and my teacher can not expland why that ...
he only said :"we are human ,and computer is computer ,it is not human so some program u write it can not run right with your mind ...."
i think he is right...
Your "teacher" is an idiot.
The code may compile.
The code has a bug.
The executable may run to completion.
The executable has a major bug.
Soma
Maybe it was lost in translation but your teacher comes accross as a bit of a cod-philosopher. This is not teh time for philosophy. What I imagine he was saying was that teh computer does exactly what you tell it and the trouble is what you are telling it is not what you think you are telling it. Trust me - he is not blaming the computer! ;-)
OK enough nonsense.
In these lines:
> head=head->next;
> head->prev=NULL;
what do you suppose happens if head->next is NULL? Answer: head->prev would be an attempt to dereference a null pointer.
The following at least prevents it from crashing.
> head = head->next ;
> if( head != NULL )
> {
> head->prev = NULL;
> }
But I still would not like to bet that the code is correct - I haven't looked that hard. The problem becomes obvious if you were to use a debugger. Why don't programming classes ever seem to teach this essential tool!?
Clifford
> when i run it on borland C++ 3.0 it is ok but Dev it not...
It ran but it was still wrong. The 32bit code generated by Dev-C++ (or rather Mingw/GCC) allows better use of the processors memory protection mechanisms so will trap errors that are ignored in 16 bit code. This is not a good thing, in the 16 bit code you will find out about the error at some point, the trouble is it will be nowhere near the actual cause of the problem, and so will be very hard to debug. But you need the debugger in the first instance to tell you exactly where the run-time error occurred. Unfortunately Dev-C++'s debugger sucks - I used MS VC++2005 Express.
i even didn't know why i'm wrong .
and this is my think...
<a href="http://photobucket.com" target="_blank"><img src="http://i117.photobucket.com/albums/o48/anhtrue/test.jpg" border="0" alt="Photo Sharing and Video Hosting at Photobucket"></a>
i even didn't know why i'm wrong .
and this is my think...
<a href="http://photobucket.com" target="_blank"><img src="http://i117.photobucket.com/albums/o48/anhtrue/test.jpg" border="0" alt="Photo Sharing and Video Hosting at Photobucket"></a>
sorry my first image some wrong ,if u can ,please fix it for me ,thanks
You have already been given a fix. You are not listening!