Hi,
Yes, my own is very similar to what you show, except that I think n-dimensional point classes are pointless exercise, if you'll excuse the bad pun. What exactly is the benefit of making the order of the point data type generic? Are we saving typing in the library by merging the 2D and 3D point concepts? Do we pay a penalty for that?
By order you mean the number of coordinates right?
This is actually really important to me. Coordinates in 2D and 3D are important, but 4D coordinates are too (eg, homogeneous or projective coordinate). Quaternians are 4D (well, 4 coordinates), and Plucker cordinates have 5 coordinates. Those are cases I came up with off the top of my head, but I know there are more examples I did not think of yet. There are very valid reasons that the size of a coordinate set should be specified at compile time for cases other than 2 or 3.
Yep this is my point of view too. We're not talking about "merging 2D and 3D" but making generic algorithms Some very simple algorithms like distance or dot product, or even addition and subtraction, have to be implemented in a dimension-agnostic manner. BTW, that was exactly the purpose of my first submission to Barend, when I extrapolated his pythagoras algorithm to make it work with any number of dimensions. As a potential user, it's my first requirement. Some algorithms only make sense for a precise number of dimensions. I guess those ones can just statically check if the point that has the right coordinate_count (or "at least enough" coordinates, don't know yet). If your library is 2D-oriented, I'm obviously not asking you to put the coordinate_count requirement into your concept since you wouldn't use it anyway. It's always the same principle: the concept represents the minimal set of requirements, so it's OK for me like that. Regards Bruno