Re: [boost] Formal Review: Concept Checking Library

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2000-11-20 23:13:20

Hi Matt,

Thanks for looking at this for the third time!

On Mon, 20 Nov 2000, Matthew Austern wrote:
>  - Potential disadvantage, which really needs more study:
>    does this actually do what it promises?  Are the error 
>    messages from concept checking really easier to understand
>    than the error messages we have without it?  That's especially
>    a concern if we're taking about a very simple template, like
>    for_each, and a very complicated concept checking macro.
>    (Aside: I think that some of the GNU people are doing 
>    experiments where the front end would recognize concept 
>    checking assertions and use them when generating error 
>    messages.  Concept checking that straddles the library/
>    compiler boundary might be a promising direction to go in.)

Some kind of compiler support would be fantastic!

Also, another short-term thing we can experiment with is the naming of
things like the "constraints()" member function to maximize its
readability for users. Perhaps changing "constraints()" to
"requirement_violation()" or "requirement_violation_error()" might help?
Any other possibilities? Some people at the Erfurt conference mentioned
that just seeing "LessThanComparable::constraints()" in the error might
not be enough. The previous version of concept checks was better in this
regard, but it was too unwieldy.

>  - An advantage or disadvantage, depending on how you look at
>    it: concept checking exposes a lot of cases where user
>    code just happens to work, even though the specs never
>    guarantee that it's supposed to.  (For example,
>    std::map<const int, int> doesn't work with the latest
>    SGI STL, but it did work with an earlier version.)  By
>    and large, I think this is an advantage; it's good for
>    these things to break visibly.

Also, there are going to be situations where we find out the specs don't
say what they mean and need to be changed. And of course, sometimes the
concept checks will be applied incorrectly and will need to be fixed. This
will definitely be an ongoing work...

>  - I keep hoping that there might be a way to eliminate the
>    use of macros.  Token pasting, in particular, is distasteful.
>    On the other hand, I can certainly see the advantage of
>    sparing users the sight of disgusting constructs like
>    taking the address of a function pointer and putting the
>    whole thing in a never-executed do/while loop.

I've been thinking about this too, but needed a kick-in-the-butt
to really move on it :) I'll look into a macro-free method.

>  - Something that's missing: an explanation of the low-level
>    constructs that appear in concept_checks.hpp.  Users who
>    want to write their own concept checks need to understand
>    not just how to write a constraints() member function, but
>    also specifics like require_boolean_expr and 
>    ignore_unused_variable_warning.  I can use the code in
>    concept_checks.hpp as a model, but users should be able
>    to get that from the documentation.

Will do.

>  - A stylistic issue (and here I'm showing my ignorance of
>    standard BOOST usage): Is it appropriate to have variables
>    with names like __f, and _First, and macros with names like
>    __STL_DEFINE_BINARY_OPERATOR_CONSTRAINT?  Names like that
>    are reserved for the implementation.  What I don't know is
>    whether this file is considered implementation code or
>    user code.

That was a mistake. I've changed to use BOOST_DEFINE...
and will be changing the variable names.

Thanks again!

Jeremy

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