Re: Standard Matrix interfaces

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.

Helmut