Concepts are in C++0x!

September 25, 2008 by Douglas Gregor

Last Saturday in San Francisco, the ISO C++ committee voted to accept the concepts proposals into the upcoming Candidate Draft (CD) for C++0x. In all, thirteen proposals related to concepts were voted into the CD, covering the core language, foundational concepts, iterators, containers, algorithms, and more. In the next few weeks, the CD should be available for comments, as will the final versions of each of the proposals.

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.

Introduction to Concepts Article at DevX

August 25, 2008 by Douglas Gregor

DevX has a special report on C++0x, which includes an introductory article about concepts:

  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.

Default Implementations of Associated Functions

July 23, 2007 by Douglas Gregor

The concepts specification has contained wording to permit default implementations of associated functions “forever”, which permits one to write concepts that state a set of related operations (e.g., == and !=) while only requiring that the user provide one of those operations. This allows algorithms to be expressed more cleanly without pushing many more requirements on the user. It’s somewhat like using relops in your algorithms or using the Boost.Operators library on your data types, but it applies only within constrained templates. For example, here we write the EqualityComparable concept with both != and ==, related through a default implementation:

auto  concept EqualityComparable {
  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.

ConceptGCC — BoostCon Edition is now available

May 10, 2007 by Douglas Gregor

BoostCon 2007 is coming up next week, and will be full of interesting sessions on Boost and C++0x. I’ll be giving a half-day tutorial on concepts, and have rolled a special version of ConceptGCC just for this occasion (and, to fix a critical bug or two that affects my slides). The BoostCon edition of ConceptGCC contains the following improvements:

  • 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::iterator is again a RandomAccessIterator.
  • Added Semiregular and Regular concepts.
  • Added support for delegating constructors (for real this time).
  • Added the DerivedFrom concept.

The DerivedFrom concept

May 8, 2007 by Douglas Gregor

We recently decided that we needed a new concept, DerivedFrom, to express the requirement for an inheritance relationship between two types. This concept has the following definition:

  concept DerivedFrom { /*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
  requires DerivedFrom
  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.

Requirement Propagation and CopyConstructible

May 3, 2007 by Douglas Gregor

The concepts proposal contains a feature called “requirement
propagation” (formerly referred to as “constraint propagation”), which
implicitly defines constraints based on the declaration of a
template. If you didn’t know that requirement propagation existed,
don’t worry; it’s a behind-the-scenes feature that reduces the size of
requirements clauses.

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 is
implicitly added to the requirements clause. [ Example:

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

--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 {
    T operator-(T);
  }
  template
  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 requires CopyConstructible
  T negate(const T& x) { return -x; }

The New Old Iterator Concepts

May 3, 2007 by Douglas Gregor

The C++ community has known for a long time that the STL iterator requirements are too strict. There have been various attempts at refactoring the iterator concepts to loosen the requirements (thus permitting more iterator-like entities to be iterators).

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::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!

Wanted: Doxygen Hacker

April 24, 2007 by Douglas Gregor

Doxygen is a great tool for turning C++ code and comments into reference documentation. We would absolutely love to use Doxygen in the ConceptGCC standard library, and in other libraries that are using Concepts in C++, but there’s one big snag: Doxygen doesn’t parse concepts, or requirements clauses, or any of the new constructs introduced into C++0x.

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 in C++0x

April 24, 2007 by Douglas Gregor

Variadic templates have now been accepted into C++0x and will be in the next C++0x working paper. Variadic templates have the distinction of being the only C++0x feature that has made it completely through the Core Working Group and into the working paper within a single committee meeting.

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

Concepts Go “To Core”

April 18, 2007 by Douglas Gregor

The Evolution Working Group of the ISO C++ committee just voted the main concepts proposal “to core”, with two minor additions:

* We will add a built-in concept BaseOf
* We will add concept map friends

Moving “to core” means that concepts will go into C++0x as soon as the formal wording is agreed upon. This process could take a while, but at this point it is unlikely that any significant details will change.

Two add-on proposals were discussed.

1) Jeremy Siek proposed scoped concept maps (committee document N2098). The Evolution Working Group is strongly in favor of this feature (votes: 15-10-0-0-0, for those that like to track such things).

2) Bjarne Stroustrup and Gabriel Dos Reis proposed the reintroduction of || constraints (N2221). The Evolution Working Group is against this feature (votes: 1-5-3-8-9).

Update: The Evolution Working Group decided to use ‘&&’ to separate concepts in the a requirements clause, instead of using ‘,’ as in the latest proposal and ConceptGCC.