With that, I am also closing down the ConceptGCC blog. Now that I am working on a new, open-source C++ compiler, I am not involved in the development of GCC (or ConceptGCC), it no longer makes sense to keep this blog going.  Any future C++- and concepts-related posts will appear over at C++Next.

I think that now is a good time to point out and thank those who have invested significant effort in getting concepts to this point. On the language side, James Widman authored a large portion of the concepts wording, and the standardese is in much, much better shape because of his involvement. John Spicer provided extremely detailed feedback on the concepts wording and helped shape the formulation of concepts. The concepts design comes from work by Gabriel Dos Reis, Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy Siek, Bjarne Stroustrup, and Jeremiah Willcock.

On the library side, Mat Marcus shepherded the library concepts proposals through the Library Working Group, and authored, reviewed, and improved various parts of the conceptualized standard library. Daniel Kruegler provided extremely detailed review of and corrections to essentially every concepts proposal, and authored parts of the conceptualized standard library. Walter Brown, Pablo Halpern, and Alisdair Meredith all provided detailed reviews of and improvements to the library concepts proposals, including authoring several library concepts proposals of their own.

Many others have shaped the final form of concepts, including  David Abrahams, J. Stephen Adamczyk, Matthew Austern, Alberto Ganesh Barbati, Howard Hinnant, Mat Marcus, Alisdair Meredith, David Musser, Sean Parent, Sibylle Schupp, Alexander Stepanov, Alan Talbot, Thomas Witt, and Marcin Zalewski.

Thank you to everyone who has been involved thus far in concepts, but you’re not off the hook yet: there are yet more wording bugs to find, libraries to conceptualize, and dark corners to find.

  http://www.devx.com/SpecialReports/Article/38864

In other concepts news: work on getting concepts into the C++0x standard is still ongoing. With more than 400 pages of specification currently under consideration as part of the concepts proposal, the volume of changes has slowed progress. However, I’m hoping for success at the upcoming C++ committee meeting in San Francisco this September.

auto  concept EqualityComparable<typename T> {
  bool operator==(T, T);
  bool operator!=(T x, T y) { return !(x == y); }
}

This concept will match any type with a suitable operator==, whether or not it has an operator!=. If no operator!= exists, the default implementation of !(x == y) will be used instead. ConceptGCC now supports default implementations, with one caveat: late-checked concept map templates don’t seem to work well with default implementations of associated functions, yet.

• The range-based for loop now deals with temporary containers appropriately.
• Rvalue-reference arguments in associated functions now forward as an rvalue.
• The iterator concepts have been simplified and expanded in scope, providing better support for proxies; vector<bool>::iterator is again a RandomAccessIterator.
• Added Semiregular and Regular concepts.
• Added support for delegating constructors (for real this time).
• Added the DerivedFrom concept.

  concept DerivedFrom<typename Derived, typename Base> { /*unspecified*/ }

DerivedFrom is a compiler-support concept, like SameType. We expect that most of its uses will be to intermingle the object-oriented and generic programming facilities of C++0x, e.g.,

  template<typename T>
  requires DerivedFrom<T, Shape>
  void draw(T& shape) {
    // Can use Shape's member functions via "shape" object.
  }

DerivedFrom is now supported (albeit “lightly tested”) in the development version of ConceptGCC.

There is one aspect of requirement propagation that we would like to
change. As of N2193, [temp.req.prop] paragraph 2 says:

For every type T that appears as an argument or return type in a
function declarator, the requirement std::MoveConstructible<T> is
implicitly added to the requirements clause. [ Example:

    template<EqualityComparable T>
    bool eq(T x, T y); // implicitly adds requirement CopyConstructible<T>

--end example ]

For various reasons, this feature is problematic and has been removed from ConceptGCC. This change will break some “existing” concepts code. For example, the function “negate” below is currently (according to N2193) well-formed:

  auto concept Negatable<typename T> {
    T operator-(T);
  }

  template<Negatable T>
  T negate(const T& x) { return -x; }

ConceptGCC used to compile this. With today’s development version of ConceptGCC, however, we get an error message:

  beep.C: In function 'T negate(const T&)':
  beep.C:6: error: constructor 'T::T(const T&)' is inaccessible

To remedy the error, add a CopyConstructible requirement, so that “negate” can return its value. Formerly, the
compiler would have added this requirement:

  template<Negatable T> requires CopyConstructible<T>
  T negate(const T& x) { return -x; }

In Oxford, Jeremy Siek presented an alternative iterator concept taxonomy that separated access from traversal (the main known issue with the existing iterator requirements), describing using Concepts. Better yet, he updated all of the STL algorithms to use this new concept taxonomy, proving how well it works.

Since then, Jeremy Siek and Alex Stepanov realized that an even simpler change would suffice: in the existing iterator concepts, as modeled by ConceptGCC up until a few days ago, dereferencing a ForwardIterator had to return a “true” C++ reference (e.g., value_type const&) . It turns out that this requirement is very, very rarely used in the STL. So, Jeremy made a very simple change: ForwardIterators, like InputIterators, only require that operator* return something convertible to value_type. Mutable iterators require that one can assign a value_type to the result of operator*. Now, proxy iterators (like the infamous vector<bool>::iterator) can meet all of the iterator concept requirements!

ConceptGCC now has these new, old iterator concepts. With just a minor change, Jeremy and Alex fixed the major problems with iterator concepts… and it’s completely implemented in the development verson of ConceptGCC. Huzzah!

We’re looking for someone willing to implement C++0x support into Doxygen, so that we can produce great reference documentation automatically for ConceptC++ code. Having this functionality would be a huge benefit for C++0x and concepts. Any takers?

Variadic templates are implemented in ConceptGCC alpha 6 and in the experimental C++0x mode in GCC 4.3.