Re: [boost] [Review] ITL review questions

Subject: Re: [boost] [Review] ITL review questions
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-02-24 15:04:24

Joachim Faulhaber wrote:
>> I also don't understand why there is an itl::map and itl::set since
>> they don't seem to add anything that can't be easily accomplished
>> with interval_set and interval_map plus the element iterator adaptor
>> or with std::set and std::map.  It just isn't clear to me what they
>> are for. 
> 
> 
> (1) Within the ITL, for all sets and maps there are some functions
> that are uniformly available and that are not implemented for
> std::sets/maps. Some of them are member functions.
> add, subtract : implement generalized addition and subtraction of
> elements and segments
> add_intersection, flip : intersection and symmetric difference
> contains, contained_in : superset/subset relation
> cardinality : extension of size can be infinite for continuous
> interval containers
> iterative_size: number of iteratable entities
> 
> This is done to give all all itl::containers, interval and element
> containers a uniform basic interface that can be used in global
> functions. 

Ok, I would suggest that these member functions be made free functions that accept std::set and std::map as well as itl::interval_map and itl::interval_set.  Wrapping a class to add behaviors defeats generic programming and erects barriers to interoperability.

> (2) For element containers itl::set itl::map set theoretic functions
> are implemented. In an instantiation e.g.
> interval_map<int, itl::set<int> >, sets can therefor be aggregated
> out of 
> the box, if itl::sets/maps are used.

I believe that the same could be accomplished with std::set/map if the set theoretic functions were free functions.

> (3) element_iterators are a pretty recent extension. The idea to
> substitute element containers since element_iterators are available
> is new. One 
> obstacle may be that element_iterators lack some of the properties of
> first class containers, since they only point to transient objects.

You can only provide a const iterator.  You can't get non-const access to the key type of a map or set anyway.  The codomain value of the map would be const with the iterator adaptr and non const with the first class container.

> Also, the absorb_neutrons function seems strangely out of place and
> has no 
>> documentation.  What does it do?
>> 
>> It removes all value pairs, that have neutral elements as associated
>> values 
> from the map.

> Neutron absorption is a fallout of law based testing ;) In many use
> cases value pairs of maps can be deleted, if the associated value is
> a neutral element which keeps the map more minimal. This is desired
> in many cases, but in some it's not.
> 
> Moreover an interval itl::Map of itl::Sets is a model of itl::Set
> only, if 
> it absorbs neutrons.
> 
> For a map that is not a neutron absorber, absorb_neutrons can be
> called to discard those elements explicitly.
> 
> See also
> http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/concepts/map_traits.html
> http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semantics/concept_induction.html

I think you should rename this function to remove_null or something less misleading.

Also, you should probably implement it with a free function and allow the user to specify a value for the neutral element:

template <MapType>
void remove_value(MapType& map, typename MapType::codomain_type neutral_value = typename MapType::codomain_type());

I'm a little confused about what it means for a map to be a neutron absorber.  Does it automatically remove elements with neutral codomain values?  I'm also confused about what a itl::Map of itl::Sets is and how it can be a model of itl::Set.

Regards,
Luke