|
|
Boost Testing : |
Subject: Re: [Boost-testing] [concept_checking] How is this intended to be used.
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-24 17:01:04
on Sat Jan 24 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> I've been looking over the documentation for concept checking.
> At the same time, I'm looking at the implementation of boost::iterators
> as an example of how the concept library is meant to be used.
Great!
> Its still not clear to me and I have a couple of questions.
I'll try to help.
> But before I ask them, I should state what my pre-conceptions
> of the library are:
>
> In the serialization library there are number of constraints upon
> the types which are permitted to be passed as arguments
> to templates and functions. For example
>
> const T & t;
> ar << t;
>
> requires that T be a serializable type.
>
> So if the user says
>
> ar << U;
>
> and U is not a serialiable type he might get a 1500 line error
> message - which should teach him not to do that.
>
> My understanding is that by using the concept checking library
> I can give him more useful information.
Usually it improves error messages.
> ..libs/concept_check/using_concept_check.htm describes how
> the concept library is meant to be used which seems to agree with
> my understanding as described above.
>
> Here would be a good place to correct any misunderstanding
> I have so far.
Well, fine so far, but you only got half of what the library does. The
other half -- using archetypes -- helps you ensure that your concept
requirement specification covers all the requirements that are actually
imposed by your implementation. In other words, if you wrote a function
that used operator- on a pair of iterators, yet only documented that the
iterators were required to be bidirectional iterators, you'd find out.
> However, when I consider implementing this, it would seem
> that I would include ../serialization/concepts.hpp in a bunch
> of headers and insert BOOST_CONCEPT_REQUIRES... macros in all
> the top level API for templates and functions.
Yeah, that's roughly it.
> I'm a little
> reluctant to undertake such an ambitious edeaver without double
> checking so I pick another library (not really at random) to see
> how concept checking was used there.
You might also look at the graph library.
> It looks like concept checking is not used by default. That is,
> I would have expected that every usage of boost.iterator would
> include the iterator_concept.hpp headers and subject every usage
> to the concept checks. But I've found that this is not the case.
> I only found concept checks to be used in the tests for derivative
> libraries (e.g. filter_iterator). The seems inconsistent with the
> the description of the usage as described in
> ..libs/concept_check/using_concept_check.htm
If you mean that there are no concept checks for iterator_facade and
iterator_adaptor, I think there are a few reasons. The main one is
probably that CRTP doesn't lend itself to concept checking, because the
argument type is incomplete at the point where the checks would occur.
Also, those components have highly conditional requirements -- "if you
want your iterator to model concept X, you need to provide operation Y."
Caveat: Jeremy Siek did all the original concept checking stuff for the
iterator library.
> So what's the recommended/intended usage of the concepts checking
> library.
>
> That's the first question.
In general, you would add concept checks to all the function and class
templates in your public API, and use archetypes to test their
specifications.
> Here is the second one:
>
> I understand that violating a constant
concept
> constraint will generate a syntax error at the point of violation
Well, a compile-time error, anyway.
> and this will preven the program from being compiled.
OK
> But suppose I have another case:
>
> T * t; // T is a type with serialization trait "no_tracking"
> ar << t;
>
> This is not an error - but would almost always be a bad idea and
> contrary to what the user intended. Is there something like:
>
> BOOST_CONCEPT_RECOMMENDS(boost::serialization::tracking_level<T> >=
> boost::serialization::tracked) which would flag this at the point of
> invocation?
Nope, nothing like that. The concept check library produces hard
errors, and is concerned with requirements, not advice. In other words,
warnings are outside the scope of this library. There are other
facilities in Boost for that sort of thing.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com