From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-07 21:28:23
Matthias Schabel wrote:
> Exactly - for arbitrary tag types, you really just need a set container
> since order of the various tags is irrelevant. also, if there was some
> way to specify the compile time sorting criterion so that all duplicate
> tags were guaranteed to be adjacent, that would enable me to eliminate
> one order of N in the algorithms off the bat. What I mean is, say
> we're doing dimensional analysis with some tags :
>
> struct tag1 { };
> struct tag2 { };
>
> if it was guaranteed that iterating through
>
> mpl::set<dim<tag1,1>,dim<tag2,-1>,dim<tag1,2> >
>
> could be defined by sorting on some unique integer type identifier
> derived from the tags tag1 and tag2 so that all terms containing tag1
> appeared adjacent sequentially, then collapsing duplicates in the set
> could be made much more efficient.
>
I think this is the only crucial missing piece! I agree that the best
way is to somehow give the tags an ordering and to store them in sorted
order. Is there some way to have each tag "inherit" from a common "base"
and be assigned an underlying integer index?
Ideally, you want to be able to write code that uses, say, 3 different
units and then be able to add new code that defines a new units without
having to redo all the types.
If this is not attainable, what is the best we can do?