Use of overloaded comparison operator> in C++ in conjunction with a getter function

Question

I'm struggling with a problem concerning the overloading of the binary comparison operator >. By design, it is supposed to compare two cards and return either 1 (if the left-hand-side argument is bigger) or 0 (in the opposite case).

Here's a brief description of the problem:

class Card includes, among other stuff, the variables int suit and int value as private data members. I've declared the overloaded operator function as follows:

int operator>(const Card& lhs, const Card& rhs);

Because it needs to access private data members of class Card, it is declared with the friend qualifier in the class declaration.

The function itself is confirmed to work as described. The real problem lies with providing the two arguments by calling a 'getter' function of the following form:

 Card &Node::getCardRef() const{
       Card& ref = *c;
       return ref;
 }

where the variable c is of type Card * and points to a valid object of type Card. Also, an instance of class Node represents a node in a singly-linked list.

Combining the two functions in the following manner causes a segfault (specifically, in gdb terms "In Card &Node::getCardRef(): this = 0x0"):

 if (node.getCardRef() > node.getNext()->getCardRef()){   

 /* do wondrous stuff */

  }

Also, when isolated, Card &Node::getCardRef() seems to produce desired results.

Answer 1

"In Card &Node::getCardRef(): this = 0x0")

if (node.getCardRef() > node.getNext()->getCardRef()){   

Node::getCardRef is called twice in that code fragment. The first time as a result of the . operator, so we can be reasonably certain^* that its this will be valid.

The other call to Node::getCardRef is the result of the -> operator. It is entirely likely that the left-hand-side of the -> is 0 (thus, this will be 0, also).

It is very likely the case that node.getNext() is returning 0. Singly-linked lists usually indicate the end-of-list condition by returning a null pointer.

I guess that you are comparing the final item on your linked list with the null item that doesn't follow it.

---

^{*: we can be reasonably certain, but not 100% certain. It is possible that node contains a corrupt reference, or that a previous wild pointer has corrupted our local variables. In my experience, null pointers are much more likely than null references.}