Phil Endecott wrote:
Barend Gehrels wrote:
About the "point concept". I've looked at the concepts, downloaded and tried the concept compiler.
Hi Barend,
Other people have expressed a desire that you describe your library in terms of concepts I agree with that, see e.g. John Femiani's messages.
Based on the comment quoted above I wonder if perhaps you have misunderstood what is being asked for. I don't think anyone is asking for code that will run on ConceptGCC. I would be quite happy for you to simply write your _documentation_ in terms of concepts.
Exactly!
If we take your point class as an archetype of your point concept, I think that this means that algorithm implementations have to use the operator[] notation while "user" code can choose to use .x()/.y() notation. For what it's worth, as a potential algorithm author I'm not at all enthusiastic about that:
Me too.
but I know that [] is other peoples' preferred style.
[integer] implies that the elements have the same type.
No doubt once we look at the concepts for everything else there will be myriad other similar choices.
Yes. Fusion style at_c<N>(p) comes to mind.
I fear what it comes down to is this: if you present a minimalistic library, people will focus on and disagree about these details; neither side of the ".x vs [0]" argument is "right", and I don't think there's a solution that keeps both happy.
Yes.
Only by presenting a library that has compelling merit of its own (for example within its algorithms) will you get people to set aside their stylistic preferences and follow your concepts.
Adaptability with existing and future point classes and geometry/ graphics libraries is a compelling point; and one that should not be taken lightly. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net