Hello, I've been quite busy with anything but geometrical things lately. Anyways, right now, I'm intensively working on clarifying vector/matrix interfaces and adding more stuff that could be quite useful (e.g., vectorial iterators for matrices; boost iterator_adaptor is just [pause] cool).
Well... back to the topic. <Patrick's code snip> template< typename T, int N > class X; subletly differs from template< typename T, size_t N > class X1; niuance is in the second template parameter - former accepts T, and int values. Mathematically speaking (I'm by no means a programmer), values of type int are all values in set Z (well, that's theoretically, practically there're numeric limits that are implicated by technical issues), and size_t is a type where valid values are in set N (natural numbers) + zero. So, set Z expands set N and declaring template parameter as size_t is intentional for obvious reasons although it would be nice to have such a type that deals with set N values [1, +inf. [a.k.a. max. num. limit]); instantiation with <T,0> is just meaningless. Actually that's BC++ problem that it cannot digest valid code. On the other hand, workaround would be nice. Is such a workaround possible without sacrifying the clarity of template parameters?.. I've also created libcalc section in sf.net, files will be uploaded soon (currently this section is just empty). Comments and other thoughts are nice, sometimes there're philosophical issues whether add some things or not, e.g., cayley norm. of vectors, on the other hand, aim of the lib would be hom. vectors and matrices in n-dimensional euclidean space and "euclidean" whispers that only euclidean norm. would be intuitive; cross product is another issue... well, generic implementation of cross product would introduce tensors and i'm not very well sure whether n dimensional cross product is that frequently needed (only 3d cross product is implemented "by default") and I think that such specific things can be implemented in certain project if autor of that project thinks there's rationale to do this. I cannot see rationale to implement this in library for general (but not in that sense "we-have-anything-what-you-want-and-even-more-than-you-can-imagine") use. Sometimes generic programming is confused with creating some functional beghemot. Well, after Uni exams are over, I'll be working on this lib. Shortly, I'll give a message where interested people could take a look at this. Respect, Justinas Vygintas D. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost