2009/9/1 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
How is your interval container library coming along? It was pointed out by one of the reviewer that my interval concept was lacking an interval set concept, which made me think of you and your work.
Thanks for your interest. I'm planning to submit for review within a few days.
If I have a generic function with a given name and a function of the same name exists that accepts your type explicitly the compiler will prefer the better match. I have to give my functions names, and I prefer to give them simple and intuitive names. This increases the odds that there is a name collision. The namespace helps, but operator syntax doesn't benefit.
If your type has operators defined for it that conflict with my operators you will have to qualify your calls to my operators with the namespace
(1) What is troublesome here is, that the better matching but semantically false operator is *silently* chosen. If a user uses boost::polygon which some thirdparty::polygon_sequence, which happens to implement operator +=, which is not unnatural for a sequence type, she will innocently and unconsciously produce false code using both components right. It may even happen, that the thirdparty::polygon_sequence::operator+= does the right thing most of the time, and only fails in special circumstances. I do not attribute this problem to your design. It's more a deficiency of the language. c++0x concepts (that we unfortunately won't get) would be helpful. Nevertheless, I think this is a problem we should be aware of. At least it should be mentioned in the docs in a section that refers to requirements on client types used with boost::polygon. (2) But this was only one of two problems I had. After removing operator+= from the custom type, the compiler still did not resolve the call of += to the intended instantiation from boost::polygon. This is unfortunate, because a whole suite of Laws in my law based tester can not be used out of the box, since the Law's implementations are exploiting the syntactical equality of operators (without namespace qualification). In contrast to point (1) I can not see why the compiler refueses to use your unqualified operators in this case.
Thanks for taking the time to look at my library, what you are doing with loki looks very interesting, Luke
Thanks for contribution this work Joachim