Boost logo

Boost :

From: helmut.zeisel_at_[hidden]
Date: 2001-08-22 02:46:45

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:

> Interesting! What is the relationshup between
> a 'solver' and the 'interface' of an algorithm?
> [No, I should say 'a collection of algorithms' which solve
> the same problem]
> In particular: using the notion of specialisation,
> an STL algorithm interface still only admits ONE algorithm
> as a solver: you can't have two ways to 'sort' iterators
> of the same _type_, because specialisation is type based.
> That constraint doesn't apply to class based
> (virtual function based) polymorphism.

I am not sure whether I understand you correctly,
but IMHO the template-equivalent to virtual functions
can be achieved using something like traits.

Take some hypothetic container-sort:

struct bubblesort_tag {};
struct quicksort_tag {};
template<typename C> struct container_traits
  typedef quicksort_tag sort_tag;

template<typename Container> void sort(Container& c)
  sort(c,typename container_traits<c>::sort_tag());

template<typename Container> void sort(Container& c, bubblesort_tag)

template<typename Container> void sort(Container& c, quicksort_tag)

For a special Container, you can now use either
the default version or, if you need a different, a special version:

vector<int> v;
sort(v); // default as defined in container_traits<vector<int> >
sort(v,bubblesort_tag()) // special version

If container_traits<vector<int> >::sort_tag is different
from container_traits<list<int> >::sort_tag,
sort will internally call different algorithms for different
container typs.
I do not know whether you count this
as "one" or "several" interfaces ...
But as I understood, you do not like traits anyway.


Boost list run by bdawes at, gregod at, cpdaniel at, john at