Re: [boost] [Polygon] What does this error mean?

Subject: Re: [boost] [Polygon] What does this error mean?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-09-03 12:02:04

Stewart, Robert wrote:
> Phil Endecott wrote:
>> Simonson, Lucanus J wrot:
>>> The error the above should fix is:
>>> 
>>> /usr/local/src/gtl/boost/polygon/rectangle_concept.hpp:192: error:
>>> no matching function for call to
>>> 'set(boost::polygon::rectangle_data<int>&,
>>> boost::polygon::orientation_2d_enum, std::pair<int, int>)' 
>>> 
>>> Is that error still present?
>> 
>> Ha, actually I hadn't noticed that particular error amongst the
>> kilobytes of other spewage.  It has now gone.  What I am
>> still getting
>> is the "class std::set is not a function" stuff.
>> 
>> I've also added the interval_mutable_traits specialisation
>> that Thomas
>> suggested without any improvement.
>> 
>> I would be interested to hear if anyone thinks that concept checking
>> could make these particular errors any more readable.
> 
> Concept checking would help immensely -- and was what I thought of
> immediately upon seeing Lucanus' reply to your initial query --
> because it would have indicated that std::pair<int,int> was not an
> interval type.  The documentation would then be able to direct you to
> the traits specializations needed to satisfy the failed concept. 
> That is so much more helpful than obscure diagnostics from deep
> within the library.      

If the rectangle concept applied a concept check on the interval_type defined in its traits and we checked the rectangle concept at the interface Phil originally called we would indeed get the error sooner and it could provide a better description of what was wrong.

I think that it might be handy to provide some concept compile time checks that the user can use to verify that their traits are setup correctly.  It might be overkill to perform concept checking on every interface, however.  A simple check is to call the few free functions that directly access the traits.  If these succeed all other interfaces will be valid.

This issue with ADL and set() is something I've seen before.  When I first used std::vector and std::list as models for polygon_concept and polygon_set_concept I ran into it and resolved the problems.

Thanks,
Luke