dick@silicon.csci.csusb.edu (Dr. Richard Botting) wrote:
>This makes me wonder whether standard libraries may need
>to be, kind of, multiple level.

This kind of thing could be good, but it is hard to
agree on the details (i.e. hard to standardise) at this
time.

However, with namespaces, one can have both the
standard STL as well as using the MAXTAL implementation
(because my implementation lives in its own namespace).

This isn't quite what you want, but is probably the
closest C++ can come to it.

In the case of the inheritance structure of the
exception classes I argued strongly that the standard
should specify ABSTRACT classes derived using
virtual inheritance -- but the committee thought
otherwise.

So .. if you prefer my implementation, you just use
namespace MAXTAL and you have the full object oriented
exceptions, and if you use the namespace 'std' you get
the fixed value oriented exceptions.


Not ideal, but namespaces are the best we've got
for supporting multiple libraries -- and they do a fairly
good job considering the specs were produced by
a committee :-)


--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



---
[ 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. ]

khan@xraylith.wisc.edu (Mumit Khan) wrote:
>
>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.

    The reasons is that the performance guarrantees would not
be met. I personally find that a bit weak: often performance
is less an issue than utility. However, there is no point
at all having separate iteratotr categories for forward, bidirectional
and random iterators otherwise, since mathematically
they're entirely equivalent.

    There is a simple and general way to fix the problem .....

>Would the following (or some more efficient rendition of thereof) be
>something that is a candidate for an "extended" STL library?
>template <class BidirectionalIterator, class T>
>inline void __generalized_sort (
>    BidirectionalIterator first,
>    BidirectionalIterator last,
>    bidirectional_iterator_tag,
>    T*

   but while it may be more efficient, this technique isn't
general.

   A general way is to use a bidirectional to random access
iterator range adaptor. Basically, some simple delegation
can be used to convert any iterator kind into any other.
The most useful case is converting input iterators into
forward iterators. [It took me about a day to get that
working]

   Note that such adapted iterators can be very slow:
however random acess on a singly linked list container (for example)
is possible by simply running down the whole list every time.



--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ 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. ]

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. ]