On 2014-08-05 17:29, Robert Ramey wrote:
I believe that "C++ Concept" was originally defined by the following web page or writing contemporary to it. https://www.sgi.com/tech/stl/stl_introduction.html . A relevent quote is
"One very important question to ask about any template function, not just about STL algorithms, is what the set of types is that may correctly be substituted for the formal template parameters. Clearly, for example, int* or double* may be substituted for find's formal template parameter InputIterator. "
It's somewhat off topic, but I'm going to take the opportunity to point out https://www.sgi.com/tech/stl/doc_introduction.html . I've come to believe that C++ libraries - in particular parameterized types, are best described by the documentation approach embodied in this link. It is sufficiently formal where it has to be - but not so formal that one gets too bogged down. I've made a big point of this inhttp://rrsd.com/blincubator.com/requirements_documentation/ . My criticism of the HANA documentation is really that it fails to follow this format and content. I haven't read enough documentation on Hana to comment on that, but I agree in principle that uniformity, consistency, use of concepts etc are extremely useful to enhance documentation. I have my doubts though, that
One of the objections raised to my criticism is that this form of documentation is in some sense not modern, specific to STL, or in some way not a good model for all C++ libraries. It is this idea which I reject - totally. Library authors would be best served by producing this form of documentation (concurrently with code) and not spend any time re-inventing their own documentation form. Use this one and spend your time on coding! As of now, I'd say that the STL documentation provides a good starting
"we call such a set of type requirements a /concept/. [...] We say that a type /conforms to a concept/, or that it /is a model of a concept/, if it satisfies all of those requirements". the STL documentation structure can be used as-is in a reasonable way for every library. For instance I would not know how to do that for sqlpp11, but I would love to discuss it over a beer at CppCon. point for the documentation structure of most libraries (maybe all, I don't know). But adaptations might be required to make it fit to specific libraries.
Another interesting quote is:
"Concepts are not a part of the C++ language; there is no way to declare a concept in a program, or to declare that a particular type is a model of a concept. "
[...]
But with C++11 it's much more interesting. I just came upon:
http://en.cppreference.com/w/cpp/concept
which echoes my views on the whole subject. I don't have the C++11 spec - but I'm assuming/hoping that these type requirements are part of it. This section only defines the named type requirements.
But wait!!!! there's more !!!
For A good number of the concepts - example DefaultConstructable http://en.cppreference.com/w/cpp/concept/DefaultConstructible -there exists a constexpr function such as http://en.cppreference.com/w/cpp/types/is_default_constructible .
Small correction: These are not constexpr functions, they are template structs with a value.
So in this case we DO have concepts built into the language (libraries). Making a concept checking class would be as simple is:
template<class T> struct DefaultConstructible { static_assert(std::is_default_constructible<T>::value, "Class is not default constructible"); }; Personally, I would say that is_default_constructible already is the concept checking template. What you do with it is another question. You can use in combination with static_assert if you want to emit a hard error or you could use it with enable if, if you want to suppress non-matching instances.
Making a new concept class is pretty simple - leave as an excursive for the reader
But wait - there's even more!!!!
if there were a type trait defined for each concept - we would have type dispatching based on named type requirements - example
std::enable_ifstd::is_default_constructible<T> void f(const T &t);
It makes for a coherent and complete system from coding to documentation. Since most of this is "form filling" it's easy, mechanical and almost guaranteed to be correct. It certainly is a good foundation. It might get a bit more complex if you have variadic templates and/or constraints for the current set of
This works, if f is a template itself, but not if it is a function
inside a template like this:
template<typename T>
struct X
{
typename std::enable_if
This is the direction we (Boost and all of C++) need to go. That is, we've known what to do for some time we just have to start doing more.
Cheers, Roland