🚀 go-pugleaf

I've received a few notes already in response to my recent post on a
survey regarding STL's (so-called) user-unfriendly-ness and asking
suggestions on what we can do about it. I'm sure more's on the way, 
and I'd like to ask people to post it to the forum as well send me a 
copy via email if possible; this way more people get to read it right 
away and react to it. Also, if you send me email replies to these 
questions posted in an open forum, I would assume by default that you 
do *not* mind if I repost these on the newsgroup for the sake of 
openness; if you would rather that I not mention your post and/or
name, please do let me know in your note -- MK

In article <4378m2$1n86@news.doit.wisc.edu>,
I <khan@xraylith.wisc.edu> had written:
>
>2. What kind of changes would you like to see in the interface to the
>   STL algorithms? The thread started with Tony Cook using the begin/
>   end iterator in find algorithm (which I consider essential since I 
>   do partial searches all the time) as an example if I remember
>   correctly. Cook suggests find() return a bool and modify the iterator 
>   argument ... 
>
>4. Member functions that are also available as algorithms: eg., list<T>
>   provides a sort member (uses '<' relation), but STL also provides
>   a generalized sort() algorithm where you provide your custom 
>   comparator. Is the list<T>::sort() necessary? If so, why?
>


2 people have already mentioned that they're dismayed by the fact
that some algorithms explicitly exclude certain containers; eg., Cay
Hosrtmann asks why the sort algorithm does not work with lists. My
first reaction to this is that I think of STL algorithms to work on
specific type of iterators as opposed to work on specific types of
containers. Hence the sort algorithm, which, as implemented, needs 
random access to the elements in the container, requires random access 
iterators to work with and list<T> gets left in the dust. Do others 
feel strongly about it? Also, there is a simple way out. The following 
code will make sort algorithm work on ALL types of containers, include 
list<T> albeit not as efficiently as it would on a container that 
supports random access iterators.

Would the following (or some more efficient rendition of thereof) be 
something that is a candidate for an "extended" STL library?

===
//
// slightly modified STL standard sort() algorithm to not exclude 
// containers that do not support Random Access Iterators. Uses the 
// same interface as HP reference sort(first, last) interface.
//
// This code used with libg++ STL tweaks the infamous "template 
// unification failed" problem in all version of, so caveat emptore. 
// OS STL<ToolKit> works around this gcc problem.
//
// Mumit Khan <khan@xraylith.wisc.edu>
// 
//
#include <algo.h>
#include <deque.h>

template <class RandomAccessIterator, class T>
inline void __generalized_sort (
    RandomAccessIterator first, 
    RandomAccessIterator last,
    random_access_iterator_tag,
    T*
) {
    sort(first, last);
}

//
// highly inefficient, but proves the point.
//
template <class BidirectionalIterator, class T>
inline void __generalized_sort (
    BidirectionalIterator first, 
    BidirectionalIterator last,
    bidirectional_iterator_tag,
    T*
) {
    deque<T> deque1;
    copy(first, last, back_inserter(deque1));
    sort(deque1.begin(), deque1.end());
    copy(deque1.begin(), deque1.end(), first);
}

template <class BidirectionalIterator>
inline void generalized_sort (
    BidirectionalIterator first, 
    BidirectionalIterator last
) {
    __generalized_sort(
	first, last, iterator_category(first), value_type(first)
    );
}

==

regards,
mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]