Frequently Asked Questions:
Concepts in C++

Table of contents:

  1. Will concepts be in C++0x?
  2. When will I be able to use concepts?
  3. Will concepts speed up my code?
  4. Will concepts slow down my compiles?
  5. What good are concepts?
  6. Can "ordinary programmers" use concepts?
  7. Is it possible to adapt member functions using concept maps?


1. Will concepts be in C++0x?

Almost surely. The Evolution Working Group of the ISO C++ standard committee has voted to include concepts in C++0x. At present, we are refining the standard wording for the specification of concepts. Concepts require another vote (of the full C++ committee) to move that wording into the C++0x working draft, after which concepts will be "in C++0x." However, C++0x is not officially completed until the ISO C++0x document is ratified, about two years after the C++0x working draft will be completed.


2. When will I be able to use concepts?

Experiment now, use later. You can experiment with concepts now using the prototype ConceptGCC, which implements most of the concepts specification. However, this compiler is far from being production-quality, and is only really good for getting a basic feel for how concepts will work.

With the previous C++ standard, it took several years before programmers could reliably use template features such as class template partial specialization and member templates. We expect the same kind of delay with concepts, because they are a major addition to the language, requiring significant implementation effort by compiler vendors. Moreover, concepts are not yet officially in C++0x, and it is unlikely that any compiler vendor will even begin to implement concepts before they are added into the C++0x working draft.


3. Will concepts speed up my code?

No. The code generated when you use concepts will be almost identical to the code generated when not using concepts.


4. Will concepts slow down my compiles?

Concepts will probably slow down comples in experimental and early implementations, but there is no fundamental reason for the cost of checking concepts to be particularly expensive. This is very much like when function argument checking was introduced. C programmers worried about the cost of checking (which you couldn't do in C then), but found that the minor added cost lead to fewer compiler runs as more errors were found early.


5. What good are concepts?

Concepts allows you to state what a template requires of its arguments. That is, they provide a mechanisms for template argument type checking. As such, they provide better error messages (both for errors in the use of a template and for errors in the definition of a template). This leads to clearer, higher quality, code. Concepts allows your intent to be stated in the code, rather than in the comments. In addition, the use of concepts can lead to simpler, more flexible code by supporting simple overloading of templates based on the concepts of their arguments.


6. Can "ordinary programmers" use concepts?

Yes. If you can use ordinary function argument type checking and ordinary overloading, you can use concepts similarly for templates. The experience of writing templates with concepts is more like writing non-template code than template code, because the compiler diagnoses errors early (when you write the template), and error messages are similar to error messages for non-templates.


7. Is it possible to adapt member functions using concept maps?

No. Only non-member (free) functions and operators written as non-member (free) functions can be adapted using concept maps. Scott Meyers has advised C++ programmers to prefer non-member (free) functions over member functions in his 2003 article, "How Non-Member Functions Improve Encapsulation." The same advice applies to concepts.

There are several reasons for this design decision, but the main reason boils down to a major syntactic problem with expressing adapted member functions in concept maps. The way one writes a member function requirement in a concept is the same way that one writes a definition of a member function outside of the class. For example, here's a concept that requires a member function swap:

  concept MemSwappable<typename T> {
    void T::swap(T&);
  }

Now, let's try to make int, which clearly doesn't have a member function swap, MemSwappable:

  concept_map MemSwappable<int> {
    void int::swap(int&); // ill-formed
  }

The problem, in this case, is that there isn't a way for the compiler's parser to deal with int::swap today: it would be a new idea to use member syntax on built-in types. When the types get more complex, things become very complicated:

  concept_map MemSwappable<int const *> {
    void int const * ::swap(int const *&); // ill-formed
  }

While it might be possible to work around the parsing issues using typedef, the end result is rather messy, requiring users to write many extraneous typedefs just to make their concept maps parseable.