On 1 Aug 2014 at 9:46, Eric Niebler wrote:
On 08/01/2014 08:22 AM, Robert Ramey wrote:
b) settlement of "best practice in the real world" of implementation of this idea. I recommended Boost Concept Check. Which isn't bad for a start, but isn't perfect either. I ideally I would like to see this used where its a good fit and an alternative for cases where it isn't.
Boost Concept Check is horribly dated and very limited, IMO. For my work on a new range library[*], I built a new concept check library for C++11. You define a concept like:
namespace concepts { struct BidirectionalIterator : refines<ForwardIterator> { template<typename I> auto requires_(I i) -> decltype( concepts::valid_expr( concepts::model_of<Derived>( category_t<I>{}, std::bidirectional_iterator_tag{}), concepts::has_type(--i), concepts::has_type<I>(i--), concepts::same_type(*i, *i--) )); }; }
template<typename I> using BidirectionalIterator = concepts::modelsconcepts::BidirectionalIterator;
Then you can use it like a constexpr Boolean function in enable_if, which can be conveniently wrapped in a simple macro like:
template
void advance(I i, iterator_difference_t<I> n) { // ... }
This is neat, but it still isn't really what I want. What I want is for the tedium of writing STL iterators and containers to go away. I want the compiler to tell me how and why my containers and iterators are incomplete and/or wrong where possible without them being instantiated first, but if instantiated why they're incomplete and/or wrong with the instantiated type(s). I then want to flip that on its head, and have the compiler generate the STL boilerplate for me, so for example I ask the compiler to generate for me these following variants of STL containers all from the same abstract base meta-container: concurrent_unordered_set concurrent_unordered_map concurrent_unordered_multimap ... by me specifying the absolute minimum physical typing necessary to delineate the differences, and then the compiler inferring the rest by stripping it from the system's unordered_map implementation for me so I don't have to. I appreciate that such a language isn't C++, either today or tomorrow. But that is what I would like one day, and it surely is feasible given enough resources thrown at it. And besides, such functionality really would be very cool. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/