Click to See Complete Forum and Search --> : Linked List Questions


GraemeW
May 3rd, 2003, 11:00 AM
Evening all,

I am developing a linked list program, im not using the linked list template with the STL.

Im writing my own code rather than relying upon the built in functionality.

I have a class list and one of my operation's

void list::Display( void ) // Display list details
{
ToFirst(); // Move to first node in list
while ( !AtLast() )
{
RetrieveInfo(); // Display info for current node
AdvanceNext(); // Advance to next node in list
}
}

ToFirst, RetrieveInfo (see below) and AdvanceNext are all operations within the same class. I don't think this operation (Display) is working as it should, however I know the operation RetrieveInfo works fine as I have tested it by calling it in my main program.

What I would like to ask is am I calling these functions correctly? I presumed because they were all in the same class I wouldn't need to put something like


list::RetrieveInfo();

RetrieveInfo is a operation which simply outputs the values of that element in the list

Thanks.

Paul McKenzie
May 3rd, 2003, 11:39 AM
Originally posted by GraemeW
Evening all,
What I would like to ask is am I calling these functions correctly? I presumed because they were all in the same class I wouldn't need to put something like


list::RetrieveInfo();


No, you don't need to qualify the member, unless you are calling a parent class's version of RetrieveInfo. Also, don't call your class "list". It will add confusion, since there is a std::list<> class, and a "using namespace std" will screw up your entire class.
Im writing my own code rather than relying upon the built in functionality. One question, why?

Regard,

Paul McKenzie

GraemeW
May 5th, 2003, 02:44 AM
Hi guys,

When I run my program the following piece of code generates a rather nasty looking error...


Project Project.exe raised exception class EAccessViolation with message "Access Violation at address 00406C91. Read of address 00000040'. Process stopped, use step or run to continue.



if (cur->next == NULL)


At first I thought it was because NULL wasn't in quotes and I presumed because it didn't highlight black that it wasn't a keyword.

But I tried puttin it in quotes but no success, what I want is to check whether the pointer "next" is null or not, I can't remember what the other null symbol looks like.

Thanks,

Gabriel Fleseriu
May 5th, 2003, 03:01 AM
Originally posted by GraemeW
Hi guys,

When I run my program the following piece of code generates a rather nasty looking error...




if (cur->next == NULL)


At first I thought it was because NULL wasn't in quotes and I presumed because it didn't highlight black that it wasn't a keyword.

But I tried puttin it in quotes but no success, what I want is to check whether the pointer "next" is null or not, I can't remember what the other null symbol looks like.

Thanks,

NULL is not a keyword, but a macro that many compiler vendors implement. The most common implementation is#define NULL 0
Your code fails because cur->next is no valid pointer, i.e. points to memory not belonging to your process, thus the access violation.

The bug probably is somewhere else in your code -- more exactly there where you should ensure that the end node has a next pointer == 0.

:)

GraemeW
May 5th, 2003, 03:34 AM
Thanks for the reply Gabriel, would it be possible to explain what you mean in a little more detail? Im afraid I couldn't understand exactly what you were suggesting?

I think part of the problem is in my insert operation, I will explain.

I read in some values (either from a file or from a users input through the console) then create a new node in my list by calling the insert operation and passing it the new data

l.Insert( e );




void vehiclelist::Insert( Saloon e ) // Insert node
{
pointerN target = MakeNode( e );

head = target;
cur = target;
prev = NULL;
}



pointerN vehiclelist::MakeNode( Saloon e ) // Makes a new node
{
pointerN p = new node;

p->e = e;
p->next = NULL;

return p;
}


When I run through the program using F8 the insert function doesn't get called properly, for some reason the compiler jumps to this line within file _string.c


: _String_base<_CharT,_Alloc>(__s.get_allocator())


And as such I can't track what pointers are being created. Does anyone know why it jumps to this file and not my insert operation?

Andreas Masur
May 5th, 2003, 04:54 AM
I did not follow this thread that closely, but I assume that Gabriel actually referred to the pointer named 'cur' which will cause an assertion if it is NULL. Given the error message and the line of code this most-likely will give you the trouble (dereferencing a NULL pointer)...

Gabriel Fleseriu
May 5th, 2003, 05:19 AM
First of all, change the class name, as Paul suggested. Use 'my_list' or whatever you want, but not 'list'. Secondly: the code you posted looks ok for me. I cannot tell why it jumps into _string.c. Could you make a small application that reproduces the error and post the code? This way we might have a better chance to pin down the bug.

GraemeW
May 5th, 2003, 07:23 AM
Hi,

I have attached a small project hope this helps. I can't understand why it jumps to the string file.

NEW attachment uploaded

Gabriel Fleseriu
May 5th, 2003, 07:31 AM
The attached file is 0 byte in size (got somehow corrupted). Please repost the attachement.

GraemeW
May 5th, 2003, 08:46 AM
Couldn't attach to old post due to corruption problems.

Thanks for any help you can offer

Gabriel Fleseriu
May 5th, 2003, 09:01 AM
1. In your "saloon.h" file:
#include <string>
using std::string;
using namespace std;


Never ever write using namespace std; in a header file!!! Qualify the names accordingly, i.e. use std::string and so on.

2. In "vehiclelist.cpp":
void vehiclelist::Insert( Saloon e ) // Insert node after current node
{
pointerN target = MakeNode( e );

// head = target;
// cur = target;
// prev = NULL;

target->next = cur->next;
cur->next = target;

}

You don't test whether 'cur' is NULL. That means that inserting in an empty list will fail. The fact that it jumps into string.c is an artifact from point 1. I mentioned (it doesn't do it with my compiler and library -- I get a plain access violation).