Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-03-26 18:16:44

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.


> 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.


> 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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at