Simonson, Lucanus J wrote:
My preference would be to have a circle data type, a sphere data type and a hypersphere data type. Only the hypersphere would be parameterized on dimension. The user would pick the object that is named for what they want. If a user wants a circle they are going to be frustrated and confounded that we provide them nsphere<2>. There is something of a conceptual disconnect between circle and sphere.
Steven Watanabe:
What is wrong with typedef nsphere<2> circle;
Nothing. I'm not against saving typing with templates, I just don't want to do it at the expense of readability and intuitiveness of the library API. Some compilers will report the typedef name circle in errors and warnings, while others will report nsphere<2>, which could hurt readability of compiler errors. Also, there is more at issue here than what to name the geometry objects the library provides. The more important issue is whether there is a separate circle concept, sphere concept and nsphere concept. Circle and sphere could potentially be related to nsphere in some manner, both circle and sphere might satisfy nsphere, for instance, but not necessarily the other way around. We might use inheritance or specialization to produce a certain effect with concepts. Something that satisfies circle would also satisfy nsphere, because circle could be derived from nsphere, but nsphere would not satisfy circle unless it was 2D. I was thinking something like the following might be a good idea: template<int n> struct hypersphere_concept { ... }; struct sphere : hypershpere_concept<3> { //optionally add stuff specific to sphere concept not applicable to nsphere ... }; struct circle : hypersphere_concept<2> { //optionally add stuff specific to circle not applicable to nsphere ... }; This general pattern should be applicable everywhere, and is similar to what I'm doing with the generic geometry type system in my library. Luke