Hi Lucanus,
b. New users must feel comfortable with the API (implies OO)
Do you write "implies OO" as in "implies member functions"? If so consider that lots of people, specially here, consider that tempate free-functions are just one OO-style. That Meyer's article Joel pointed out explains why.
[goals snipped]
If "implies OO" is not a synonynm for "member functions" then I can come up with a design that meets every single goal listed, to the letter, yet following the conventional BGL-style (which is actually rooted in the STL style... the BGL just improved it) Assuming you disagree, can you show us which goal(s) _need_ the approach you choosed instead of the "functional" one? Unless you consider member functions and "old school" OO-style a goal in it self. Note: your library design in on the edge of not being "generic programming" but merely parametrized old school object-oriented programming. It has some genericity scent since at least you can adapt legacy types, but your insistence on member functions in monolithic classes just pushes the design away from generic-programming toward simple template trickery to have class A "mimic" class B. But past the "mimification" (sorry) is just old-schold OO programming.
Also, because I wanted to ease the adoption of the library by new users and target improving the productivity of my users I chose to follow more traditional monolithic class design style instead of the new free function style
What makes you think this actually eases the adoption by new users? Because is "more traditional"? If it *still* where, you would have a point. But it isn't. The now traditional approach is the STL approach (it's more than a decade old!)
and make the amount of work they needed to do to use and understand how to use the library as small as possible.
For users that use my built in types there is practically zero learning curve. For users that adapt their own types there is a modest learning curve and minimal implementation effort required to partially specialize the ConceptMap class for each. Because the adaptors are grouped together as static member functions of a class it is very obvious what I expect the user to provide.
In short, my goal was to integrate into and extend the legacy geometry type systems of as many legacy applications as possible as quickly as possible with the minimum of effort and complaining from new users so that they could start realizing the performance and developer productivity benefits that my library provides. >
Please notice that the statements above clearly indicate that you are making fundamental design desicions based on the presumption of what style of API is "more natural" to the expected users base. So let me ask you this: is your intention to keep this library mainly targeted to Intel programmers? Or is the main target the C++ community at large now? If you are submmitting to boost then it ought to be the modern C+ users out there which are quite familiar and confortable with STL-style frameworks, perhaps even as much as with "old"-style non-truly-generic APIs.
To do that I had to follow some of the conventions for how geometry type systems are expected to behave, which means no free functions.
Can you explain that? Why and how are geometry type systems expected to use member functions instead of free functions? Fernando