From NodeClass.h:


You have no data member in the node class called pnext or pNext. The pnext in red above is NOT a data member of the node class.

From NodeClass.cpp:


This line above is assuming that there is a data member in the node class called pNext. There is not, so I assume you are getting an error here when compiling.

okay, I made pnext a data member of node, and I corrected all the pNexts and made them pnext.

Now, it will print all the inserts fine, but then the program ends and gives me an error dialog box killing the program

So you added line 7?

If so, I hope you are not still using the name pnext in lines 8 and 11 because that could be confusing to have a function parameter with the same name as a data member. You should probably post your updated code.

well...yes...all I did was add line 7.

I'm really making a mess of this aren't I? Could that be what's killing the program when it runs?

The more I change, the more lost I get


This is now the header, but after your last post, I'm sure it's not right

and the node cpp


Here is the list header

Well, what does pnext represent? Generally a linked list will store two things. One, it stores some data, which I assume is what infoIn is. Two, it stores a pointer to the next node in the list, which I assume is what next represents. I don't know what pnext represents. Generally, and this can vary, you'll have a node class that looks something like this (to make things easy, I'm going to make everything public, even though usually some things are private.


Data could be any class or struct of some type. It's the data that you are storing. In your case you would probably replace:

with:


You can have a variety of different insertion and deletion functions and constructors, all of which will be passed zero or more parameters. The names of these parameters should NEVER be next or infoIn to avoid confusion.

For example, if you wanted to insert a new node with data at the end of the list, you might have a function like this:


Note infoin versus infoIn . C++ is case-sensitive, so the names are different. Also notice that the node class DOES NOT contain the front node in the linked list. Somewhere this needs to be kept track of, but not in the node class. If the node class has an Insert method, it needs to have that information passed to it or have access to it in some other way. In this case, it's passed. On the other hand, you could have a list class (not a node class) that does store the front node:


The point of all this is to point out that what you shouldn't store more than you have to in the node class and any parameters you pass to any constructor or any other method must have a different name than any data member of the node class to avoid confusion.

Hopefully this helps clarify rather than confuse.

so as usual..I overcomplicated it for myself...ookay...try again I guess...lol

do I even need a copy constructor in the node class?

and I took out the references to next in the node class.

to explain my pointer variables...

plist is the head of the list

ptrav is the front, head, temp pointer that traverses the nodes looking for the correct insertion/deletion point

pprev is the rear, tail, temp2 pointer that keeps track of the previously visited node

pnext is the pointer to the next node

Here is the revised header class

and the cpp file

Is there any order to the Contributor class? If so, is this to be an ordered linked list, as in


the order being determined by the "value" of Contributor? In that case, when you insert, you could be inserting into the middle of the list. Or are you always inserting to the beginning or the end of the list. I saw earlier that you have a list class in addition to the node class. So consider having your Delete and Insert functions be list functions. list has access to plist, where node does not unless it is passed plist as a parameter. Regarding what you should have in your node class, quite possibly have only constructors and a destructor (assuming data members are public). Which constructors you need will depend on the program, but I'd consider these could work:


You may want to just go with these two and not have a node copy constructor. I think at this stage it's easier to just assign pnext to be null in both of these constructors.

If you make things private later, you'll need to add some methods, but simplify life and keep them public for now, in my opinion.

For sure, do not have this function:

Remember the rule about not naming your parameters with the same name as the data member name. If you did want to keep it (I probably wouldn't), rename the parameter:


Frankly, I'd keep my node class minimal and have the list::Insert and list::Delete function handle the responsibility of making sure plist and pnext point to the correct node, so I might just have the list class have the two constructors and destructor, and later if you make things private, some "get" and "set" functions in the node class.

The important thing is to decide what class has what responsibility and stick with it. I'd have the list class do most of the work. There's no right or wrong answer, except if you can't decide what class does what, in which case you'll almost certainly have problems. You need to decide whether this is an ordered or unordered linked list. If it's unordered, stick any new node into the front or the back of the list. Sticking it in the front would mean less traversal. If it's ordered and you're inserting, traverse till you find a node whose Contributor value is greater than or equal to the new node's Contributor value and stick it in front of that node. If there is no node that's greater than or equal, stick the new node in the back. Any insertion or deletion will require tidying up of the plist and/or pnext pointers.

The list class does indeed do most of the work. All my list manipulation happens there (insert etc)

It is an ordered list, and the insert puts everything in the correct order. With the current files, the delete gives no outward appearance that it's doing anything and then the OS kills the file. I'm quite sure this has to do with what you're telling me.

I'll change the node class again and we'll see where we end up this time. Just a passing thought, could my contributor class files be interfering some how?

Anything's possible, but I haven't seen your updated node and list classes with the constructors and Insert and Delete functions. It's one of those things where you have to either post the new code each time or explain that you've done nothing to change the old code. Fastest way is probably to just zip all of the files each time and then post the zip file each time you post if you've changed anything at all.

Vernon, thank you for your help. I finally figured it out. I was using assignment in a couple places where I meant to be doing comparison/equality