on 15.08.2009 at 13:14 joel wrote :
Well, the problem is not the design per itself. What usually happens with such lib is that you have tons of different user types that all want disjoint set of features. use DRY (don't repeat yourself) idiom i got it
Matrix lib always looks easy to do. Except they are not. I can toss you tons of questions : will you support openMP, well it seems trivial to me
threading, i dream about a way like
MPI,
#include <the_lib/lib.h> #include <the_lib/threading.h> //enabling threading for the_lib that would be perfect for me possibly
SIMD definitely yes
extensions, there must be a common way for common users
will you embed loop level optimization based on expression introspection ? sooner or later
Will you interface looks like matlab, maple or mathematica ? i prefer to model STL interfaces where appropriate in general: as common as possible
etc ... Not even counting the things we barely scratched like storage mode, allocation mode etc... of course it is such a missingd feature it must be there
That's why I'm avoiding to comment your code cause I'm developing something similar but for a somehow different audience than yours and my view will prolly be radically different than yours. but i can get some useful stuff from a radically different design and utilize it to make the design better
I can also only reiterate the fact that I have a somehow large code base for such a thing that's maybe worth reusing. sorry but i didn't get the point
Three heads are better than two I think. indeed
-- Pavel