3

I've been scratching my head on this one, and after sifting through all the other postings I think I've come up at a loss.

I decided I wanted to practice some template coding and operator overloading in C++, and so I figured a quick and dirty LinkList implementation would go fairly far. I quickly hacked up a node and list class set, as follows:

template <class T>
class Node{
public:
  Node* getNext(){ return Next; }

private:
  Node* Next;
  T data;
};

template <class T>
class List{
public:
  List& operator++();

private:
  Node<T>* nptr;
};

template <class T>
List<T>& List<T>::operator++(){
  if( nptr->getNext() ){
    nptr = nptr->getNext();
  }
  return *this;
}

main call:
int main(){
  List<int>* listObj = new listObj<int>();
  ...push on some nodes with random values...
  ++listObj;
  KABOOM
}

I'm keeping the code brief for readability. Assume that I always initialize Next to NULL when I make a node, that there's a push function to add more nodes to the end which also sets the last node's 'Next' variable to that new node, and that nptr also starts off initialized as NULL. I've tested all the "assumed" functionality (construction, initialization, pushing nodes) and I can even pack the operator++ function as just a increment function...

void Increment(){
  if( nptr->getNext() ){
    nptr = nptr->getNext();
  }
}

call:
listObj->Increment();

...and that works just fine. In otherwords: the compiler isn't assigning my version of ++foo to any uses in the code! I can even prove this with the debugger, watching it increment the address of the List object rather then updating nptr like I want.

Now, I saw a suggestion of friending the function here that I gave a try:

friend List& operator++(){
  if( nptr->getNext() ){
    nptr = nptr->getNext();
  }
  return *this;
}

However when I do, I get a compilation error:

List& operator++() must have an argument of class or enumerated type

Hard-headed programmer that I am, I figured it wanted me to scope out the incoming RHS, which naturally also didn't work. I'm forgoing writing out that broken path of reasoning because I'm fairly confident it wasn't the right direction.

So given that the compiler seems happy with my code (or at least isn't upset about it because its not actually assigning it anywhere), why is it still grabbing the non-templated version of the operator and treating it like an int? How would I go about correcting the code to get the compiler to use the provided function instead?

Thanks in advance!

Community
  • 1
  • 1
  • I am not sure if that explains your problems, but the way you define the `operator++` function outside the class is not correct. You need to put `template ` in front of it, and then define it as `List& List::operator++()`. – jogojapan Sep 17 '12 at 06:37
  • You don't show it, but you _do_ initialize the `nptr` member? don't you? – Some programmer dude Sep 17 '12 at 06:47
  • To the two comments: typo on part my when writing this out (thank you, fixed) and yes I do (to NULL before I start pushing nodes into the list). – Broken Gyros Sep 17 '12 at 06:50
  • The whole way you're trying to define the linked list is completely memory-leak unsafe. You can do it like this in a garbage-collected language, but in C++ this is only fine with smart pointers. The more idiomatic way (that's what `std::list` also does) is to RAII the entire list as one unit. — Either way, you don't want to have a `List::operator++`. It's not the list that's "incremented" but the _place in the list you're looking at_, so you want something like `List::iterator::operator++`. – leftaroundabout Sep 17 '12 at 07:09

1 Answers1

3

User-defined operators are never applicable to built-in types like pointers. If anything, you need to dereference the pointer to your List before using the increment operator:

++*listObj;

Without the * the built-in increment operator is used which is clearly not what you want. I'm assuming that your KABOOM actually dereferences your pointer, though: You generally want to show the exact code where things go wrong an you want to be more precise about what actually goes wrong. I'm also assuming that you created actually compile code rather than what you quoted...

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • Though it is true that often the problem is somewhere in not quoted code, in this case it is clear that it's as simple as this: using the operator on the pointer instead of the object. – Gorpik Sep 17 '12 at 06:55
  • Yes, yes and yes. This was a trimmed down snippet, missing most of the useful functionality that actually fills the test cases with data. KABOOM was my odd way of saying "it seg-faults here" which was, as it turns out, an access request for the data in the node. Also, facepalming on dereferencing, thank you! – Broken Gyros Sep 17 '12 at 06:58