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

On 07/03/11 19:40, Joachim Faulhaber wrote:

2011/3/7 John Reid:

...

On 07/03/11 14:49, John Reid wrote:

...

#include

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