Le 07/06/14 07:18, pfultz2 a écrit :
Does your library define just traits or try to emulate Concept Lite? I'm not quite sure what you are asking. The library doesn't do everything that Concepts Lite does. It lets you define concept-like predicates(commonly called a type trait in C++) in a similiar manner as Concepts Lite does. It does do template constraints as well, but this is just done using `enable_if`. Also, it won't resolve ambiguity between overloads like Concepts Lite does. However, I am thinking about implementing a mechanism for this. Perhaps something like this:
struct advance1 { template<class Iterator> TICK_OVERLOAD_REQUIRES(is_random_access_iterator<Iterator>);
template<class Iterator> void operator()(Iterator& it, int n) const { it += n; }
};
struct advance2 { template<class Iterator> TICK_OVERLOAD_REQUIRES(is_input_iterator<Iterator>);
template<class Iterator> void operator()(Iterator& it, int n) const { while (n--) ++it; }
};
tick::overload
advance = {}; However, this is fairly verbose even with the help of macros. It just might be easier to add some `not`s to the requires clause. Have you read the Concept-Based Overloadingin Eric's blog [1]? Eric uses a dispatching schema on which the Concept definition is the tag dispatcher.
// iterator_concept
template<typename T>
using iterator_concept =
concepts::most_refined<
typelist<
concepts::RandomAccessIterator,
concepts::BidirectionalIterator,
concepts::ForwardIterator,
concepts::InputIterator,
concepts::WeakInputIterator>, T>;
template<typename T>
using iterator_concept_t = meta_apply
Now, non-template members can be disabled, but they need to be made templated, like this:
template<class Base> struct A : Base { template
There might be a way to workaround the issue using universal references. I haven't really looked into it. No, this is a real limitation.
Best, Vicente. [1] http://ericniebler.com/2013/11/23/concept-checking-in-c11/