|
|
Boost Testing : |
Subject: Re: [Boost-testing] [concept_checking] How is this intended to beused.
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-25 12:23:55
David Abrahams wrote:
>> 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,
What I mean is that if I include some iterator - say filter_iterator in
my code, concept checking won't be applied since its not included.
This would seem to indicate that the concept library is not being
used to achieve its intended - and to my mind - most compelling
purpose. So either
a) I'm miss understanding how the library works (entirely possible),
b) Its fulfilling the purpose of helping users check thier programs in
a way that is not obvious to me.
c) It's being used sole as an aid to developers of the iterator
library to check consistency. I can see the utility of this, but at this
point
it's not my main interest.
>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.
Hmmmm - the serialization library uses CRTP as well.
>Also, those components have highly conditional requirements --
> "if you want your iterator to model concept X, you need to provide
> operation Y."
And it does a lot of this - e.g. One could serialize an rvalue if
it is untracked.
>> 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.
I'm aware of this. But its very appealing to leverage on the whole
concept checking infrastructure to provide advice as well as rules.
I would seem to me that this could be implemented by just creating
a slightly different definition of the BOOST_CONCEPT.. macros.
And finally, I would be very interesting if someone were to write
and article - "Canonical C++ Template Library" which would take a very
small library:
a) implement the library
b) implement the concepts and archetypes
c) show how to check the concepts with archtypes
c) show how to create documentation semi-automagically
from the above. If someone had nothing else to do, it would
be very interesting to see something like a Hyped up Oxygen.
(H2O ?) for templates.
d) show how to create tests semi-automagically
from the above.
By semi-automagically I mean a straight forward one to one
mapping of the concept checking code to the tests and
documentation. Of course someone might want to undertake
to write programs for doing this, which would be an
interesting endeavor.
I don't really expect anyone to undertake such a project
as it is such a narrow and arcane area - but interesting
to speculate upon.
Thanks for helping me understand this.
Robert Ramey