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

Subject: Re: [Boost-users] [ICL] More compilation questions/problems
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-08 09:41:52

2011/3/8 John Reid <j.reid_at_[hidden]>:
> 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:
>>>>
[..]
>> 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.

if you don't find it (you are probably my most experienced and most
thorough user :) other people won't find it all the more.

What troubles me a bit is, that the improvements proposed during the
review are making the ICL obviously more difficult to use. The old
interval template although inferior in design and a little fatter than
statically bounded intervals just worked in all instances, some of
which may now lead to astonishment and make consultation of
documentation or even the author necessary.

> 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.

That's true. I've just implemented all of the possible variants the
check my concepts for completeness. Yet for practical purposes right
open intervals are suitable for all situations.

> 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.

I use BOOST_STATIC_ASSERT and BOOST_CONCEPT_ASSERT but I have not
checked out the all the possibilities to make those compile time
checks maximally informative

> 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,

My pleasure :)
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de