|
Boost : |
Subject: Re: [boost] [polygon] Overload resolution for operators fails
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2009-09-02 05:15:00
2009/9/1 Simonson, Lucanus J <lucanus.j.simonson_at_[hidden]>:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk