Re: [Boost-users] [ICL] More compilation questions/problems

Subject: Re: [Boost-users] [ICL] More compilation questions/problems
From: John Reid (j.reid_at_[hidden])
Date: 2011-03-08 08:37:10

On 07/03/11 19:40, Joachim Faulhaber wrote:
> 2011/3/7 John Reid<j.reid_at_[hidden]>:
>> On 07/03/11 14:49, John Reid wrote:
>>>
>>> #include<boost/icl/interval.hpp>
>>>
>>> template<  typename IntervalT>
>>> void
>>> check_contains() {
>>> IntervalT interval;
>>> typedef typename IntervalT::domain_type domain_t;
>>> ::boost::icl::contains( interval, domain_t() );
>>> }
>>>
>>> void h() {
>>> namespace icl = ::boost::icl;
>>> check_contains<  icl::continuous_interval<  float>  >();
>>> check_contains<  icl::discrete_interval<  int>  >();
>>> check_contains<  icl::right_open_interval<  float>  >();
>>> check_contains<  icl::left_open_interval<  float>  >();
>>> check_contains<  icl::closed_interval<  float>  >();
>>> check_contains<  icl::open_interval<  float>  >();
>>> }
>>>
>>>
>>> The last 2 lines in h() do not compile whilst the preceeding 4 do. Is
>>> this by design or a bug? Testing elements for membership of a closed or
>>> open interval seems natural enough. I'm using gcc 4.4.3.
>>>
>>> Thanks,
>>> John.
>>
>>
>> Also operator== does not seem to work on closed and open intervals, e.g.
>>
>> icl::closed_interval<  float>() == icl::closed_interval<  float>()
>>
>> does not compile.
>
> Hi John!
>
> thanks for your thorough work on the many instances of ICL class
> templates. The compilation failures of the current examples
>
> icl::closed_interval<  float>()
> icl::open_interval<  float>()
>
> are by design again. The related information can be found in the docs
> http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.html#boost_icl.interface.class_templates
> in: Table 1.6. Usability of interval class templates for discrete or
> continuous domain types.
OK I could have found this in the documentation. It is not always 
obvious from the documentation why some code does not compile. It could 
have been a constraint on the which types are OK to instantiate 
intervals with or how the contains function works.

>
> The reason for this: All icl interval objects, that can be constructed
> are supposed to work with interval containers. If I have an interval
> set
> {[0.0, 2.0]}
> of a continuous domain type using statically bounded closed intervals
> and I want to subtract another closed interval
> {[0.0, 2.0]} - [1.0, 1.0]
> I am unable to represent the result
> {[0.0, 1.0),(1.0, 2.0]}
> with the same kind of statically bounded interval.
>
> Therefore I don't allow statically bounded closed and open intervals
> (the symmetric interval types) to be instantiated with continuous
> types.

I'd rather see the intervals be as general as possible but I can see why 
you've done it this way. In fact having statically bounded open and 
closed intervals in ICL seems quite unnecessary and almost pointless if 
you can only use them with discrete types.

One thing that might help you support the library is to use compile-time 
checks to prevent users instantiating types that the library does not 
support. It would have been easier for me (and presumably others in the 
future) if no code involving closed_interval<float> had compiled rather 
than just a subset of the functions.

Thanks again for ICL and the prompt reply,
John.