Advertisement Jump to content
Sign in to follow this  

small library: design problem

This topic is 4915 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!