Simonson, Lucanus J wrote:
Fernando wrote:
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. Yes, I read the Meyer's article and other similar articles encouraging non-member, non-friend functions. I think it is safe to say that my data structures are fully encapsulated through a minimal and sufficient interface, the ConceptMap. In addition to that I add a minimal and sufficient interface between the library functions in the Concept class and the ConceptMap, allowing even the concept map to change without needing to change my library functions. I achieve all the goals Meyer's describes already. If I have achieved the goal already, why should I change the code?
Are you serious? It's all over the article: opt for free functions whenever possible. In your case, you opt for member functions always. Can you honestly say that a class with 100+ member functions is minimal?
To be frank, I think the developers at Intel are representative of the C++ community at large. I designed the public API for the lowest common denominator of C++ developer, not the elite. I want everyone to be able to be easily productive with the library immediately. Inside Intel the target user is the common man in a cube hacking away at C++ code, desperate to get off the critical path of a microprocessor project, and as open source it is a university student trying to get a term project or research experiment done by his deadline.
Again, I ask, aren't they familiar with STL and in particular STL algorithms? STL algorithms are free functions. There's nothing difficult or scary about free functions. It's just syntax. If they are not familiar with STL algorithms as you imply, I'd say, as C++ programmers, they better be. To be honest, I think you are underestimating the C++ community at large if you think that Intel is a representative of it.
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?
Because the people from whom I collected requirements for the ideal computational geometry library told me that was what they wanted. They also wanted it to be generic. I wanted good encapsulation. I managed to come up with a design that did all of those things. Why would I sacrifice one requirement in order to achieve another in a different way?
Because there's a better way. And, IMO, it is our duty, as knowledgable C++ folks, to educate the "lowest common denominator of C++ developer", not to introduce various unsafe reinterpret_casts or static_casts, just to satisfy a certain syntax style and certainly not to advocate fat class interfaces. Ok, I'm through with this thread. Let me end it with this with a quote from Scott Meyers's article: "It's time to abandon the traditional, but inaccurate, ideas of what it means to be object-oriented. Are you a true encapsulation believer? If so, I know you'll embrace non-friend non-member functions with the fervor they deserve." Think STL! Think STL algorithms! :-) Regards -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net