small library: design problem

Hi everyone, I've got a question regarding a design problem i'm facing with a small library i began to write couple of weeks ago. This is the situation: I've defined a main templated class A that contains the core functionality of the algorithm, an algorithm_traits class that's used to configure the algorithm and a set of functors and template functions that are used by A. As speed is my ultimate goal in my current redesign process (that's why i don't really want to call this thing a 'library' in the stl or boost sense where clarity of code is top priority) i needed to have the data inside A 16 byte aligned and reorder A's internal data structures for maximum data locality in the cache. To shield the helper functions from this not-so-beautiful implementation detail i provide iterators for the core data structure of A. The helper functions operate on iterator ranges provided by A.


// of course, this is not meant to compile

template<class FwdIt> void helper1(FwdIt begin, FwdIt end) {}
// ... couple of 'helpers' that do the actual work

template<class T> iterator {};   // shielding the helpers from memory layout
                                 // in the algorithm class
                                 // so it has to know how the core structure
                                 // of algorithm<> is represented in 
                                 // memory

struct algorithm_traits {};

template<class C = algorithm_traits> class algorithm 
{
     array_of_core_structures_thehelpers_work_on a;
     // a std::vector<> in the beatiful version, a 16 byte aligned allocc'ed 
     // pointer pile in the not-so-beautiful but fast version     
};

Now my question is: i don't want to call the library a library until the user can decide whether to use a standard version of the algorithm that would rely on features of the stl or the 16 byte aligned, pointer flinging version. the problem with this is that the only thing versions have in common is the set of helper functions (which do the actual work) as they rely on iterator ranges only (i think choosing iterators for this has proven to be a Good Thing). Do i have to provide two versions of both the algorithm A itself and the iterator class? Is something like specialisation appropriate here? Or should i resort into meta programming techniques (which i'm already using in my code, so i wouldn't introduce new complexity), so i could have only one version of algorithm A that just gets compiled differently based on a parameter in the algorithm_traits (might get messy)? i'd very much appreciate if you shared your ideas on this. hope that i somewhat succeeded in describing the problem.. i'll try to clarify more if needed. best regards, simon -- edit random thoughts: i could probably get away with the last solution (changing the core types via meta programming tricks) quite well. i could just redefine the array_of_core_structures_thehelpers_work_on according to a parameter in the algorithm_traits. then i would only have to supply two types of iterators i.e. one for the beautiful version and one for the not-so-beautiful version. This would result in one algorithm<> class that's changing via meta programming and using either the traditional or the aligned iterator. sounds acceptable to me.. is something like that acceptable for a library too? or just go with the "two seperate libraries, one optimized, one not" approach?.. [Edited by - thesimon on August 3, 2005 9:57:21 AM]

Topic Locked