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
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
> 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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk