错误：此声明没有存储或类型说明符

Question

I am getting this message with everything that has Node* (this declaration has no storage or type specifier). Could somebody help and please send me in the right direction?

template <typename type>
Node* Stack<type>::pop() {
Node* retNode; // the node to be return
if(tos == NULL) {
    cerr << "*** Stack empty ***";
    exit(1);
}
else {
    retNode = tos; // store the location of tos
    tos = tos->getLink(); // move to new tos
    retNode->setLink(); // unlink the popped node from the stack
    size -= 1;
}
return retNode;
}

I am sure it's dealing with Node* but I just can't figure out what.

Below are my declarations for the node class that are being used in my stack class. Let me know if you need my declarations for the stack class as well because I just cant see the problem.

template <typename type>
class Node<type>{

private:
type data;
Node *link;

public:
Node(type p_item, Node *p_link);
type getData() const;
Node* getLink() const;
void setData(type p_data);
void setLink(Node *node);
};

Answer 1

Node is a class template, so you cannot use Node or Node * as data types. You must add template arguments in angle brackets, eg Node<int> or Node<char> * etc.

In the specific example you gave, it seems the following would be appropriate:

template <typename type>
Node<type>* Stack<type>::pop() {
  Node<type>* retNode;
  /* ... */
  return retNode;
}

Ie the same type argument that is used for Stack should (probably) be used for Node as well.

Two further notes:

1. It seems odd that, while the Node template appears to implement internal data structures of your stack, Node<type> * pointers are returned by the pop function of the stack. It would seem more natural (and better encapsulation, and more intuitive for the users of your stack) to return type objects.

2. It also seems odd that the pop function calls exit (and thus brings the entire process to a halt) when the stack is empty. Perhaps returning nullptr , or a dummy object, or throwing an exception (or a similar strategy) would be more appropriate.