@naraku9333
OK, easy ones first...
| ...since you add a back pointer in the class, why not add a second link in Node? |
Two node*'s in the node structure? Would they be prev and next ?
I didn't want to get into a doubly linked list here (just wrap this singly linked case). Were you thinking of something else?
| I'm not a huge fan of the idea of the insert_asc function, it doesn't make sense to me unless the list is already sorted. |
Of course. The function is there in order to make it
possible to create an ordered list. It would have to be used exclusively for adding nodes to the list.
| I would also have just one data member (std::pair?), might be easier to covert to a template. |
I agree. The node with two separate data fields is devons design choice.
I went with it because we were working on devonrevenge's list.
At this point I would just go straight for a template class version.
Now for the harder one...
| Maybe make the Node struct private? |
The issue here for me is access to data in the list.
Normally, when I'm tinkering with a list class I've written myself I will even (hold onto something) leave front public, so I may freely
mangle manipulate the list in the main().
We probably want to do better than that here.
Note that we presently have no access to the data in the list.
We have no front() or back(). None of our member functions return a node pointer and front is private so there is no way to obtain a pointer to front in the main().
If we make the node structure private then this list is
really on lockdown.
I'd say that until we have fully functional iterator objects setup (which is beyond my skill level), the best we can do is to permit the use of nodes in the main(), provide a get_front() which returns a pointer to front
by value NOT by reference (so the user cannot re assign front itself), and then warn the user not to mess with the values of link, which are exposed to him/her.
Your thoughts?
Q: So is that the primary difference beween an iterator into a list and a node*?
An iterator exposes the data in a node, but hides the links?
Another issue concerns any front() which might be written.
It gets too convoluted due to there being two data fields in a node.
( would it be void front( int*& rpInt, string*& rpWord ) so we can change num and word in the node through these pointers? )
We'd probably be better off just working through node*'s for now.