Hi Denis, thanks for your input again. You're a good analyzer of code. Maybe you want to consider writing a code review for libraries that are submitted for formal review on the boost developer's list from time to time :) 2011/5/19 Denis <denis@camfex.cz>:

Hi

1. (questionable because it changes the visible interface): rename `left_open` and `right_open` to `right_closed` and `left_closed`.

Reason: interval_bounds is used in bitwise operations with bit=1 means `closed`.

(1) I tried to consider common usage of naming of intervals that is known from math. There seems to tendency to assume closedness as default, while openness is indicated by naming: [x, y] an interval (also closed interval) [x, y) a right open interval (x, y] a left open interval (x, y) an open interval. (2) The bits are chosen so closedness is indicated by 1 and openness is indicated by 0 11 [x, y] an interval (also closed interval) 10 [x, y) a right open interval 01 (x, y] a left open interval 00 (x, y) an open interval.

`left_closed() | open()` resulting in `left_closed()` is more readable than `right_open() | open()` resulting in `left_closed()`.

Also, there are checkers `is_left_closed()` and `is_right_closed()` but not for *_open

... again following common usage [see (1)].

I had to use `class bounded_value` in my program (as in Icl details: calculating lower and upper bound of interval separately, then constructing the interval, bitwise or'ing bounds) and I commented every usage of `right_open()` as `left closed` in order to explain why I use `interval_bounds::right_open()` in constructing the left `bounded_value` of the interval. This resulted in the idea of renaming.

Maybe making bit=1 mean `open` would be less painful for other users ?

You see me inconsolable to hear that you are suffering pain from my library =( There is an concept "interval_bound" http://svn.boost.org/svn/boost/trunk/boost/icl/concept/interval_bounds.hpp that allows you to combine and-ing or-ing etc. of interval_bounds directly. I think that'll reduce your suffering, at least I hope so. Yes, it's missing from the docs. Would you create a ticket? BTW, you may locally extend the concepts in the way you desire and add functions according to you naming rational.

2. define `contains(interval, elt)` as `!below(interval, elt) && !above(interval, elt)` allowing the user to use `below()` and `above()`. Sometimes it is useful.

(3) Thanks for this suggestion. The design of the icl::interval's interface is done under the general requirement of minimality. The concept approach allows you always to add own function templates locally to the concept if you need them.

Anyway, all the versions of `contains()` are made of checking for both bounds.

If you found a suboptimal function implementation, please refer them specifically. I'd appreciate a suggestion for an optimization. You can also create a ticket.

3. It would nice if the functions taking two intervals will have versions taking an element as second argument. I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all the list at the moment) Constructing temporary `close_interval` object in order only to pass it into those functions is cheap with ints but would be expensive with heap-allocated domains (blobs, strings, etc).

This is worth considering. In my own use of intervals within the implementation of interval containers I never encountered the need for such functions ... yet they may be useful in other situations. What do others think? Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de