From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-26 18:07:02
>>About the "point concept". I've looked at the concepts, downloaded and
>>tried the concept compiler.
>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.
>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: but I know that  is other peoples'
>preferred style. No doubt once we look at the concepts for everything
>else there will be myriad other similar choices. 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
>" argument is "right", and I don't think there's a solution that
>keeps both happy. 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.
Thanks for your comments and indeed, I was somewhat confused about the
concepts. I think the Boost.Concepts plus documentatation will be the
right way. In the documentation there are some comments about it but
that's obviously not enough. Will work on it.
The library is more or less designed as you mention it, the points are
as small as possible, minimalistic, with algorithms working on them.
There is not yet an overwhelming amount of algorithms, I admit, many
other libraries have much more. But that will grow and can also be
positive, things can be changed at this stage.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk