Joachim Faulhaber wrote:
2010/3/5 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2010/2/28 Barend Gehrels <barend@geodan.nl>:
and then gives the example " mySet.contains(42)". But contains is NOT an method of std::set, but YES from interval_set. This was confusing. my view on sets here is not governed by std::sets but rather by the mathematical notion of a set or the itl::Set concept that is part of my documentation. In this view the "is element of" function is pretty fundamental and it is available for itl::interval_set and for itl::set as bool T::contains(const domain_type&); [snip] Which is the common interface, the fundamental aspect, that constitutes this semantic kernel? Would that signature contain find(x)? Would it contain contains(x)? Would it provide iterators?
boost::dynamic_bitset does not implement find, it does not implement iterators. Would we therefore say it is not a set? Its signature does not provide contains(x) but it contains test(x), which IMO should be called contains(x). I'm speaking from partial ignorance, but...
Wouldn't it be better to use non-member functions for those operations expected of a set? Then, boost::dynamic_bitset would satisfy itl::contains(bitset, x) because it could be implemented in terms of test(). Likewise, std::set would satisfy because itl::contains(s, x) could be implemented in terms of find().
I use std::set::count for contains.
Using that approach, your concepts would apply to any type for which a specified set of non-member functions can be applied while meeting specific semantic requirements. I should think many more types could be adapted to ITL without needing specific support form ITL with that approach.
The decision to keep a few functions, like
bool T::contains(const domain_type&);
member functions although they could have been implemented as global functions comes from a residual resistance of a brain that has been thinking in OO-designs for too long ;-) Also I found
s.contains(x)
a little more readable than
contains(s,x)
but this is a minor advantage compared to the benefits of the global function that you described concisely. Luke already took the same line in this discussion and I certainly will improve the design in this respect.
That's good to hear. Better interaction with existing std and user defined types en lieu of itl specific types addresses my main concern with the library. So give this a +1 from me. Jeff