Question

I’m trying to sort a vector of objects using a predicate function and I’m getting some segfaults…

I have a class Item and a list of Items in a vector< Item > _items. I needed to sort it according to a display order (numerical member of the class) and I just called a simple sort with a predicate function.

sort(_items.begin(), _items.end(), sort_item_by_display_order);

where the predicate function is

bool sort_item_by_display_order (Item i, Item j)
{
    return i.GetDisplayOrder()>j.GetDisplayOrder();
}

and GetDisplayOrder is

int Item::GetDisplayOrder()
{
    return display_order;
}

but… I got some segfaults while doing this. I then added a counter to the predicate function to check how many times it was called and I discovered that when this crashed the counter was bigger then the size of the vector.

After some reading I changed the code to use iterators instead of using the .begin() and .end() (Shouldn’t this be the same?!)

So what I have now is

vector<Item>::iterator it_start, it_end;
it_start = _items.begin();
it_end = _items.end();
sort(it_start, it_end, sort_item_by_display_order);

with the same predicate function.

And now it doesn’t crash, but… for most of the sorting I do I get more iterations then the size of the vector I am sorting (which is probably normal)

So… What is the difference between calling sort with _items.begin() or _it_start. From what I can tell they are the same right?!

One more note. Item is a simple base class declared as

class Item
{
  private:
  (...)
  public:
  (...)
}

As reference I used http://www.cplusplus.com/reference/algorithm/sort/ and http://www.codeguru.com/forum/showthread.php?t=366064.

In the second link they add a const and & to the predicate function arguments which would make my function something like this

bool sort_item_by_display_order (const Item& i, const Item& j)
{
    return i.GetDisplayOrder()>j.GetDisplayOrder();
}

but I get a compiler error:

Item.cpp|1485|error: passing `const Item' as `this' argument of `int Item::GetDisplayOrder()' discards qualifiers|

arghhh… The question is… What am I doing wrong?

Answer 1

First, it’s completely normal for the comparison function to be called more times than you have elements in the collection. That’s part of what’s meant when we say a sorting algorithm’s complexity is O(n log n), for example. The number of comparisons performed on a collection of size n will be about n × log(n). (In fact, n is pretty much the minimum number of times to call it; otherwise, we wouldn’t even be able to tell whether the collection was already sorted in the first place.)

Second, you get an error when you make the parameters be const references because you’ve declared GetDisplayOrder as a non-const method. You’re not allowed to call non-const member functions on a const object because the compiler assumes the method will attempt to modify the object, even though in this case it doesn’t modify anything. Add const to the end of the declaration and definition:

int GetDisplayOrder() const;

int Item::GetDisplayOrder() const {
  return display_order;
}

Finally, there’s the matter of the segmentation faults. The code you’ve shown here isn’t enough to pinpoint a cause. You’re correct that changing the way you pass the iterators to sort shouldn’t have any effect. My suspicion is that your Item class needs a copy constructor and an assignment operator, but that they either aren’t implemented, or they’re not implemented properly. Sorting a vector obviously involves moving items around in the collection, and that requires a working assignment operator. Passing those items to your original comparison function, which accepted parameters by value instead of by const reference, requires a working copy constructor. If you’re doing any dynamic memory allocation (such as with new or malloc) you need to make sure you either make a “deep copy” of the memory when you assign or copy an object, or you figure out a way for multiple objects to share the same allocation. If multiple objects think they all own the same block of memory, one of them is likely to free that memory before the others are finished with it, and that can certainly lead to segmentation faults (as you access freed memory).