Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

list::sort() and greater<T>

9 views
Skip to first unread message

Arild Kvalbein

unread,
Apr 13, 2002, 10:38:40 AM4/13/02
to
I'm a little confused about the way the second form of the list::sort()
function. According to the documentation, the greater<T> predicate should
return x>y for (const T& x, const T& y).
The documentation for the list::sort() function on the other hand says
(about the two forms of the function):

1: imposes the order !(*Pj < *Pi) whenever i<j
2: imposes the order !pr(*Pj,*Pi) whenever i<j

As far as I can see, this implies that the predicate function pr should be
equivalent to (*Pj<*Pi) (except maybe using other criterias). This seems to
give the correct results with VS SP5, but all examples I have found define
the pr predicate as a greater-than predicate. What am I missing here?

I have double-checked the order of indexes in both MSDN and Dinkumware
documentation. (The Dinkumware documentation calls the predicate "Pre3", and
makes no references to greater<T>).

---
Arild Kvalbein
C-Map Norway A/S
<ar...@c-map.no>


Igor Tandetnik

unread,
Apr 15, 2002, 12:29:06 PM4/15/02
to
Here's the deal. list::sort without the parameter sorts using less<T>
(in other words, <) in the ascending order, smallest at the head,
largest at the tail. list::sort with the parameter is supposed to accept
any predicate and sorts in such a way that, had the predicate been
less<T>, the sorted order would be the same as with parameterless
version. In other words, if Pr(A, B) == true, A will precede B in the
sorted order.

Now, the Dinkumware STL implementation shipped with MSVC6 does not
provide a templated version of list::sort, because of inferior compiler
template support at the time the implementation was frozen. Instead, the
predicate parameter is hardcoded to be greater<T>. This way, you can
sort in ascending order (with parameterless version) or descending order
(with hardcoded parameter), but not in any other order. This "feature"
made it into MSDN documentation, hence the confusion.

Now that the compiler is better, P.J. Plauger, one of the authors of
Dinkumware STL, recommends editing <list> header. Find a line

void sort(_Pr3 _Pr)

and put "template <class _Pr3>" in front of it, so it looks like

template <class _Pr3> // added line
void sort(_Pr3 _Pr)

Do the same to merge:

template <class _Pr3> // added line
void merge(_Myt& _X, _Pr3 _Pr)

You need to change both, since sort uses merge internally. This makes
std::list C++ standard-compliant. While you are at it, consider applying
the fixes from

http://www.dinkumware.com/vc_fixes.html

--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

"Arild Kvalbein" <ar...@c-map.no> wrote in message
news:a99fta$jtb$1...@oslo-nntp.eunet.no...

0 new messages