This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [libstdc++] New implementation of concept checking


On Tue, Apr 03, 2001 at 10:42:53PM +0200, Toon Moene wrote:
> Phil Edwards wrote:
> 
> >    [To those of you in the studio audience who are wondering "what the
> >     heck is Boost and what makes their code any good?" I can only say
> 
> Surprisingly, that's _not_ the question that came to my mind.  Rather:
> What's concept checking ? [ I guess it's something that comes before
> implementation checking .... ]

Someone else asked me the same thing privately, which showed me that I
had forgotten to post the URL.  Basically, concept checking is attempting
to enforce -- via code -- requirements which are traditionally only in
documentation.  It's all done at compile time, and one of the goals is to
provide useful error messages pointing out the exact problem.  Below is
an edited-and-still-too-long version of my response to the private email.

One implementation was already in libstdc++, but it was buggy and we had
to turn it off.

Phil

===============================================================
The Boost implementation is at:

    http://www.boost.org/libs/concept_check/concept_check.htm

Probably the hardest part of using the STL is that many of the requirements
on the user-defined types of objects passed to STL template functions or
instantiated by STL template classes aren't specified in terms of function
signatures, but rather in terms of behavior.  "Objects of type Foo must be
comparable for equality," for example, leaving open the issues of global
function vs member function, exact restrictions on operator==, and so forth.

Matt Austern's book sums it up really well when he's talking about iterators:
anything which /acts/ like an iterator /is/ an iterator.  Enforcing the
requirements is difficult because there are no keywords like const and
private and mutable to help the user.

Jeremy worked up some methods by which code exercising a given
requirement can be packed up in little formal template classes which
he calls "concepts," in line with what Austern uses in his book.  Frex,
the EqualityComparableConcept creates two objects of the same type and
then does "x == y;".  If the user instantiates the code with his own
type, and it compiles, then he /knows/ the requirements have been met.
If it doesn't compile, then the error messages from types with names like
EqualityComparableConcept will direct the user to the problem -- better
to check all the concepts at once, ASAP, than wait until the user happens
to call a function depending on a previously-untried behavior concept,
only to have it fail to compile with some incomprehensible error.

The trick is getting the compiler to instantiate the code, and compile the
code, but never actually execute /any/ of the code, even when things like
dead-code elimination aren't being used.

Anyhow, Jeremy worked up the concept code, and Matt put it into the SGI
STL, but it had problems.  Jeremy then did a complete rework, and now
it's much much better.
===============================================================


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]