Re: [boost] Review: concept checks.

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2000-11-20 10:11:38

On Mon, 20 Nov 2000, John Maddock wrote:
> Under "Creating Concept Checking Classes" you use "prefix" several times
> when you mean "suffix".

Fixed.

> However VC6 will instantiate all member functions of a template at the time
> that the template is instantiated - obviously this is non standard
> behaviour - and I don't know how this interacts with implicit default
> constructors, but it may be worth looking into (if necessary one workaround
> would be to add a template constructor - this would prevent the default
> constructor from being auto-generated without being instantiated itself).

I'll look into this...

> Under "Programing With Concepts", you rightly indicate that concepts should
> be minimal, and then go on the define LessThanComparable as having all the
> comparison operators.  I don't agree with this at all.  The defining
> document is the standard, and that requires that the LessThanComparable
> concept implement operator< and nothing else.  The example you give is
> std::stable_sort, but again the standard makes it clear that this requires
> only operator< _and nothing else_, not even an operator==.

Ahh, another place where the SGI STL docs differ from the standard.
Hmm, I'll have to change to match the standard... though I think
Matt's definition is better. Perhaps this is a candidate for a DR.

> Under "Implementation",
> You have used a do{}while loop to scope your dummy variable, is this
> actually required?  Could you not just use:
> 
> #define REQUIRE(__type_var, __concept) \
> { \
>   void (__concept##_concept <__type_var>::*__x)() = \
>     BOOST_FPTR __concept##_concept <__type_var>::constraints; \
>  (void) __x; }

I used do{}while out of habit... just {} should be fine.

> On the whole this looks fine: in an ideal world I would have liked an
> implementation that generated neither code nor data, but this appears not
> to be possible.  (Footnote: I have played around with an alternative that
> used the sizeof operator to convert expressions to
> integral-constant-expressions.  With this it's possible to implement the
> REQUIRES macro as a typedef, that can be used at namespace/function or
> class scope.  Unfortunately I found problems with concept-checking code
> that should have failed being compiled silently).  Given that your
> implementation does generate code, I think I would like to see concept
> checking turned off when NDEBUG is defined.  I appreciate that there are
> some compilers that elliminate unused code at link time, but equally there
> are many others that do not do so (Borland's compiler for one).

Ok, will add the #if for NDEBUG.

> I notice that boost/pending has both concept_archetypes.hpp and
> concept_skeletons.hpp, these seem to do the same thing - or am I missing
> something?

Oops, the skeletons one should go away... it was renamed to archetypes.

> Test Code
> ~~~~~~~
> 
> None of the test programmes build with Borland C++, on further examination
> this appears to be due to a non-standard standard library from Rogue Wave. 
> I also note that you have added #if's to the code to allow the test
> programs to build with other compilers that ship with non-standard
> libraries, the MSVC one seems to be particularly troubling as it just
> comments out the whole of stl_concept_checks.cpp reducing it to:
> 
> int main() { return 0; }
> 
> IMO this is deeply misleading, if a library is non-standard in any way then
> this file _should not compile_.

Okidoke. I guess this is where we need a testing harnass. So we
can have "expected failures". I just don't want people to
look at the compile results and think that concept checking doesn't 
work on VC++.

> I think I would like to see the test programs split slightly:
> 
> concept_checks_test.cpp : new file feeds archetypes into concept checks,
> just checks that the compiler can cope with concept checking code.
> class_concept_checks_test.cpp : new file feeds archetypes into concept
> checks used at class scope, just checks that the compiler can cope with
> concept checking code.
> 
> stl_concept_checks.cpp: validates standard library types.
> stl_concept_covering.cpp: validates standard algorithms.
> 
> The first of these three should pretty well always compile, the second if
> the compiler supports function-pointer non-template params, and the last
> two, only if the standard library is fully conformant.

Great suggestions. Will do!

> Future Directions
> ~~~~~~~~~~~
> 
> I like the concept coverage classes a lot, however what I would really like
> is a set of wrappers that perform both compile time checking and run time
> checking.  For example an input iterator has to be used in a particular way
> - with alternating calls to operator++ and operator*, and obviously we
> can't go past the end of the sequence.  These are the kind of things that
> can only be checked at run time, I appreciate that the SGI STL has a debug
> mode that incorporates this kind of checking, but not all of us routinely
> use that library (and sometimes we write our own iterators and algorithms
> rather than using the standard supplied ones).  This is not a criticism of
> the concept checking library, really it's a request for a whole new library
> (!) :->

Sounds neat :)

Cheers,

Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek_at_[hidden]
 Univ. of Notre Dame         work phone: [phone]
----------------------------------------------------------------------