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().
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. Thank you for the hint. Joachim