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.