What? Did you read the original question?
Yes, and I read every other post here also, including yours.He did indicate that he wanted to navigate bi-directionally in his list.
No, at no point did he indicate that. His original post at no time indicates that his list has 'back' pointers, nor did he ever say he needed to walk it backwards.
In fact, in post #4 he did sayI only know how to move forward in a list and not go backwards.
which is as close as he ever got to indicating anything about the directionality of his list.You go re-read stuff.
I was reading between the lines that he was 'supposed' to extend a list because
Oh, that's your problem. Requirements engineers don't like programmers who like to "read between the lines".because - let's face it - you'd only implement linked-lists in C++ as an exercise. Any commercial dev would use STL.
Bull. You are aware, perhaps, that the STL 'list' container is specifically a linked list? Oh, and that some others may be also? You may not care what I think of the laughable "one-size-fits-all" argument, but you should at least find out what people who are recognized experts think (That is but one example). Any commercial dev would use the most appropriate tool for the task, whether or not that involves the STL.
Olam's code fragment did mention 'tail' ergo to remove the last item in a list he does not need to walk the list to find it. Don't be so quick to criticise other people's attempts to help - especially if you don't read the original posting's question.
Oh, it did, did it? Well, that tells usreams about his code! Very convenient!
To delete the last node in a linked list you need to find the penultimate node, not the last.
Assuming his code is a singly-linked list (which, with what we have been given, is all we can safely assume) he will need to walk the list to find it. If, in fact, he does have a doubly-linked list, then by all means use last->previous.
Don't be so quick to return offense where none is given. And don't start personal attacks when you disagree.
I've been teaching people to program for a long time, and one of the most frustrating obstacles to new programmers is people who answer with all kinds of information about how to improve, or add to, or change their project when a more direct answer is available. The most common cause of this problem is that the helper thinks he has a better understanding of the helpee's problem with but a glance than is warranted. The first step is to be sure you understand the OP's constraints, then advise appropriately. Don't assume more than you've been given. Notice how brk235 kindly asked for more information?