On Tue, Apr 21, 2009 at 4:31 PM, athor
<thorena@gmail.com> wrote:
A Range does not require copy semantics according to the boost docs.
http://www.boost.org/doc/libs/1_38_0/libs/range/doc/range.html
The SinglePassRangeConcept (and all range concepts using it) requires a
range to be default constructible. (There is a line "T a;" in the concept
The default constructible requirement means an abstract base class can never
implement any Range Concept. If a range does not require any copy semantics,
I don't see why it must be default constructible? Are there any good reasons
I don't know about?
I (Neil Groves) am the current developer of the next version Boost.Range known as Boost.RangeEx I fully intend to release a new version without the default constructible requirement. It should not be a requirement for a Range in my opinion. I am making the assumption that no-one will be particularly upset about loosening a constraint. Anyone wishing to add default construction as a requirement to an algorithm can of course do so by combining the SinglePassRangeConcept etc. with a separate constraint.
A change from "T a;" to "const T& a" in concepts.hpp would do the trick...
Example:
struct AbstractArraySlice
{
int* begin() const = 0;
int* end() const = 0;
};
// FAILS:
BOOST_CONCEPT_ASSERT((SinglePassRangeConcept<AbstractArraySlice>))
Footnote:
I often use abstract base classes to verify my algorithms do not use more
functionality than necessary and it annoys me that I can't use the range
concept check:
I'm sorry you have been annoyed. I hope that the response to your request has been dealt with in a manner that will dissipate the frustration.