Question

OK, I’m trying to write the stack pop method using linked lists for my C++ homework.
Let me just show you the node and list classes first, then tell you the problem:

class Node
{
public:
    int data;
    Node* next;

    Node(int data, Node* next = 0)
    {
        this->data = data;
        this->next = next;
    }
};
class List
{
private:
  Node* head; // no need for the tail when using the list for implementing a stack

public:
    List()
    {
        head = 0;
    }
    void add_to_head(int  data)
    {
        if(head == 0)
        {
            head = new Node(data);
        }
        else 
        {
            head = new Node(data, head);
        }
    }

    Node* get_head()
    {
        return head;
    }

    // this deletes the head element and makes 'head' points to the node after it.
    void delete_head()
    {
        // storing the head so that we could delete it afterwards.
        Node* temp = head;

        // making the head point to the next element.
        head = temp->next;

        // freeing memory from the deleted head.
        delete(temp);
    }
};

Now here’s the stack:

class stack
{
private: 
    List* list;

public:
  stack()
  {
      list = new List();
      flush();
  }
  void push(int value)
  {
      list->add_to_head(value);
  }
  bool pop(int& value_to_fill)
  {
      if(is_empty())
      {
        return false; // underflow...
      }

      value_to_fill = list->get_head()->data;

     // deleting the head. NOTE that head will automatically point to the next element after deletion 
     // (check out the delete_head definition)
     list->delete_head();

     return true; // popping succeed.
  }
  bool peek(int& value_to_fill)
  {
    if(is_empty())
    {
       return false;
    }
    value_to_fill = list->get_head()->data;
    return true;
  }
 // other stuff...
};

Now the problem is with pop and peek, I just don’t find them to be convenient.
pop and peek shouldn’t be given any parameters, but if I do this:

int peek()
{
  if(is_empty())
    // what should I do here?
  return list->get_head()->data;
}
int pop()
{
  if(is_empty())
    // same thing here.

  // deleting the tos then returning it.
  // I know this is not what the pop in the STL stack does, but I like it this way
    int tos = list->get_head()->data;
    list->delete_head();
    return tos;
}

I don’t know what to do when an underflow occurs.
I can’t just return -1 or 0 or something like that, cuz this will look like as if I popped -1 or 0 (tos == -1 or 0)
Is there a way of writing an anti-underflow pop/peek without having to pass anything by reference?

Answer 1

It’s a question of specification. There are several possible solutions:

• Make it a pre-condition of pop that the stack isn’t empty. It is
  the client’s responsibility to ensure this (perhaps by calling
  is_empty() before popping), and a violation of the precondition
  results in an assertion failure.

• Throw an exception if the stack is empty. This is the most obvious
  solution, but probably the least generally applicable.

• Don’t have pop return a value (or have it return your bool). To
  get the top element, you have a separate function, tos(), and a client
  who wants to do both needs two function calls: x = s.tos(); s.pop();.
  This is what the standard does, for example. In practice, it is often
  the preferred method, because for types where copying can throw (e.g.
  std::string), it’s impossible to implement pop to return a value and
  give the strong exception guarantee. (Whether this is a problem or not
  is another issue, but it could be a problem in specific cases, and it is
  the motivation behind the choice in the standard, where none of the pop
  functions return a value.)

In the end, the important thing is for you to define the interface, so
that your user knows what to expect.

And by the way, you don’t need the if in add_to_head. If head ==
NULL, you’re going to call the constructor with the second argument
NULL, so you might as well just pass head in both cases.

(I’ll skip the fact that using a linked list is a remarkably inefficient
way to implement a stack, since the code is obviously a learning
exercise.)