Dave Abrahams wrote:
on Mon Feb 18 2013, Jonathan Wakely <jwakely.boost-AT-kayari.org> wrote:
On 18 February 2013 18:30, Andrey Semashev wrote:
On Monday 18 February 2013 15:05:11 Jonathan Wakely wrote:
On 18 February 2013 14:33, Andrey Semashev wrote:
Yes, I'm aware of type traits. It's one thing to do tests/transforms on types and another to test for methods presence and behavior. It's doable but it is much more fragile and dangerous, as you have already discovered with iterator_range.
It's only fragile because iterator_range defines a member which can't be used.
No, it broke with iterator_range. It can break with other types with different signatures and/or semantics of size().
Given that I'm already requiring the type can be used with std::begin() and std::end(), i.e. is range-like, I'm happy to not support types that have a non-range-like size(). If your type quacks like a duck but swims like a fish it doesn't meet my requirements for a duck.
This sounds like the language commonly used in the Python community about (their version of) concepts. <http://grokbase.com/t/python/python-list/02c225syvb/source-code-size-metric-python-and-modern-c#20021207htb5htssa6yj355yhcjbz4wm7y>
There's no "range-like." There's a family of Range concepts: http://www.boost.org/doc/libs/1_53_0/libs/range/doc/html/range/concepts.html http://www.boost.org/community/generic_programming.html#concept
Maybe I'm off base here, but reading the above makes it hard for me to hear the rest of what you wrote.
FWIW - we had a thread a couple of months ago regarding Boost Range concepts, how they were defined and how they were implemented and what they should mean for users of Boost Range. I was dissatisfied with all three of these aspects of Boost Range but couldn't convince anyone else of my point of view. Looking that the documentation/synopsis of iterator_range<T> I see a few things of interest: a) Documentation says that it fullfills the ForwardIteratorRange concept - OK b) But then it includes the size() function - so doesn't that mean that it full fills the concept for RandomAccessRange concept? very confusing. c) shouldn't there be: template<ForwardIteratorRange> class forward_iterator_range { ... }; ... template<RandomIteratorRange> class random_access_iterator_range : public { size_type size() const; }; Boost Range concept doesn't specify size() for a ForwardIteratorRange. But I think this is another mistake since size() could be implemented (in a different way) for iterators fullfilling this concept. Wouldn't restructuring interator_range along the lines of the above resolve all the confusion here? Robert Ramey