On 08/27/12 22:28, Steven Watanabe wrote: Thanks for the prompt reply Steven.

AMDG

On 08/27/2012 05:39 PM, Larry Evans wrote:

...

1. typename Concept

The concept that we're specializing concept_interface for.

which uses the singular Concept instead of the plural Concepts, suggesting the Concept is not an mpl::vector<> of any sort.

I think I stated quite clearly in several places that an MPL sequence of Concepts *is a* Concept.

Ah yes. I remember now. Here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... it says: Any MPL Forward Sequence whose elements are concepts is also a concept. and here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... it says: the library allows us to combine several concepts into a single concept using an MPL sequence. Sorry for not remembering. Maybe the concept_interface reference: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... should provide a link to conceptdef.html. After all, when reading such a reference, a person generally expects to see all that's needed to understand that reference or a link to additional information needed to understand the reference. Having to read all the docs and remember what was said somewhere in those docs is, IMO, too hard, and liable to lead to someone, such as myself, misunderstanding. Now, the following questions concern the test code (compute_bases.cpp) attached to my previous post. The output of that test code shows that one of the superclasses of any<requirements_t> is: concept_interface < requirements_t . . .

However, I can't think of a use case for providing such a superclass. The unspecialized concept_interface definition: template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base {}; has an empty body; hence, the only use of putting such a concept_interface into one of the superclasses of an any (as opposed to just using Base) is to allow for a specialization of it. That's completely unexpected to me, and I suspect, to others. Also, the Concepts in Depth tutorial: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... provides no examples where the 1st template argument to concept_interface is an mpl sequence of other concepts, leading the casual reader to jump to the conclusion that the Concept arg to concept_interface is *not* an mpl sequence. Could you please provide a use case for such a concept_interface specialization so users could understand when it might be useful? The specialization provided in the test code when: #define OVERLOAD_SIMPLE certainly is not much use since it hides the intended simple member function in concept_interface<::simple<C>,...>. TIA. -regards, Larry

On 08/28/12 07:22, Larry Evans wrote: [snip]

Now, the following questions concern the test code (compute_bases.cpp) attached to my previous post. The output of that test code shows that one of the superclasses of any<requirements_t> is:

concept_interface < requirements_t . . .

...

However, I can't think of a use case for providing such a superclass. The unspecialized concept_interface definition:

template<class Concept, class Base, class ID, class Enable = void> struct concept_interface : Base {};

has an empty body; hence, the only use of putting such a concept_interface into one of the superclasses of an any (as opposed to just using Base) is to allow for a specialization of it. That's completely unexpected to me, and I suspect, to others. Also, the Concepts in Depth tutorial:

http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...

provides no examples where the 1st template argument to concept_interface is an mpl sequence of other concepts, leading the casual reader to jump to the conclusion that the Concept arg to concept_interface is *not* an mpl sequence.

Could you please provide a use case for such a concept_interface specialization so users could understand when it might be useful?

[snip] iterator.hpp provides such a use case: template<class T, class Reference, class DifferenceType, class ValueType> struct iterator< ::boost::no_traversal_tag, T, Reference, DifferenceType, ValueType> : boost::mpl::vector< copy_constructible<T>, constructible<T()>, equality_comparable<T>, dereferenceable<typename iterator_reference<Reference, ValueType>::type, T>, assignable<T> > { typedef ValueType value_type; typedef typename iterator_reference<Reference, ValueType>::type reference; typedef DifferenceType difference_type; }; template<class T, class Reference, class DifferenceType, class ValueType> struct iterator< ::boost::incrementable_traversal_tag, T, Reference, DifferenceType, ValueType> : boost::mpl::vector< iterator< ::boost::no_traversal_tag, T, Reference, DifferenceType>, incrementable<T> > { typedef ValueType value_type; typedef typename iterator_reference<Reference, ValueType>::type reference; typedef DifferenceType difference_type; }; template<class T, class Reference, class DifferenceType, class ValueType> struct iterator< ::boost::forward_traversal_tag, T, Reference, DifferenceType, ValueType> : iterator< ::boost::incrementable_traversal_tag, T, Reference, DifferenceType, ValueType> {}; template< class T = _self, class Reference = boost::use_default, class DifferenceType = std::ptrdiff_t

struct forward_iterator : iterator<boost::forward_traversal_tag, T, Reference, DifferenceType> {};