That is exactly what I am proposing. You hit the nail on the head, there are too many points out there that we would have to interact with. That is the problem I'm solving, that is why I'm submitting the library to boost. assert(boost::point_concept<cgal::Point> cgalpt(10,20) == boost::point(10, 20));
and better yet
//construct a cgal polygon data structure with the boost polygon constructor and assert that it is equal to the boost polygon data structure constructed from the same input vertex sequence. assert(boost::polygon_concept<cgal::Polygon> cgalpoly(itBegin, itEnd) == boost::polygon(itBegin, itEnd));
Smooth as butter.
Luke
John wrote:
Hmm... I hope I am not revealing my ignorance too much here but I have not seen concepts used that way before. In my experience they are used with some macros to force an understandable error at compile time when a data type does not support the required syntax. Do you have some code I can see so I can maybe understand better?
If you think about it, if all concepts were good for was giving us shorter, clearer error msgs they wouldn't be very worthwhile to add to the language. You are not revealing ignorance. To my knowledge people are not using concepts this way before, that is what makes what I'm doing interesting. Bjarne didn't anticipate all the ways the language would be used, and that is what boost is about. I think he does understand the usefulness of concepts (beyond simply cleaning up template errors) but it is hard for him to communicate that to the community until someone like boost shows people what the language features he put in there are good for. You know he told me that it was an uphill battle to get inheritance from the template parameter into the C++ standard in the first place. I about fell of my chair because I remember when I learned from Gysuzi that it was a supported feature of the language I was literally jumping for joy. When I talked to Bjarne last year when he visited intel he suggested that we should take my library and use it as a case study for the improvement adding concepts to the language in the 2009 standard will make. For starters my errors will become more readable.... I have an alpha build of the compiler from the last boost conference, but was too busy implementing the support for 45 degree polygon edges to port my library to use the new language features. My long term goal is to release a version of the library implemented in terms of the concept_map and other features he is adding to the language at the same time the new standard is coming out, that way people will see what is going into the language and how it is being used by the example of the library. Boost is absolutely the right place for people to find that example. People had no idea what templates could really do until boost showed them. That is why I say it doesn't really matter what the library does (it happens to do what my boss needed it to do so that our chips can be built) so much as how, so that people can learn how to do the same in their library programming. Intel legal policy prohibits me from releasing even snippets of code, but I am free to type C++ into an email. Gyuszi already posted some example of how it works, and so have I. I'm trying to fast track license approval, so please be patient. There is about 23,000 lines of code in my library in 60 header files. If represents about one full year of development effort on my part. It is header file only and thread safe. I have integrated it into four different legacy applications through the polygon concept and have a group of native users working with its built in data types to develop new application level code (that is what Gyuszi is doing.) This is my day job and Concepts have made my life easier, my work more productive. class point_data { ... }; template <class T> class point_concept_map {}; template <> class point_concept_map<point_data> { /* define get, set and construct static functions in terms of point_data */ }; /* public because visual studio doesn't support the standard correctly for private inheritance from template argument*/ template <class T> class point_concept : public T { /*define get, set and construct in terms of point_concept_map function and all other member functions in terms of get, set and construct */ }; typedef point point_concept<point_data>; point& foo(point& pt) { //set returns a reference to *this for chaining purposes return pt.set(HORIZONTAL, mypoint.get(VERTICAL)/2); } struct LegacyPoint { int x, int y }; template <> class point_concept_map<LegacyPoint> { /* define in terms of LegacyPoint */ }; template <class T> point_concept<T>& foo2(point_concept<T>& pt) { return pt.set(HORIZONTAL, mypoint.get(VERTICAL/2); } void bar() { LegacyPoint pt; pt.y = 10; foo2(point_concept<LegacyPoint>::mimic(pt)); assert(pt.x == 5); point pt2(0, 10); foo2(pt2); assert(pt2 == point_concept<LegacyPoint>::mimic(pt)); } If you clean up and fill in some of the blanks you ought to be able to get the design pattern and unit test code descriptions I have posted here to compile and work. Lucanus Simonson