Simonson, Lucanus J wrote:
For me, requiring a point concept that a has an x() and y() member functions is unnecessary and restricts the usefulness of the library. I could obviously make such a requirement, but I would prefer to have adaptor functions such as: coordinate_type point_interface<T>::getX(const T& point); which allows compatibility with anyone's point concept
Shouldn't generic code ideally work with any type that is conceptually a point, rather than only types that model the point concept they set forth?
You should be able to express this something like "Type T models the Point Concept if there exists a specialisation point_interface<T> having members ....". Can you write a definition like that? I think it would be an interesting thought-experiment to consider how the standard library would look if re-written in this style, e.g. not using std::pair in maps. There are three groups of people affected: - Users with legacy code, who benefit. - Users without legacy code, who have a (perhaps small) extra step on their learning curve. - People writing libraries, who have more work to do. Phil.