|
|
Boost Testing : |
Subject: Re: [Boost-testing] [concept_checking] How is this intended to beused.
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-25 14:34:35
on Sun Jan 25 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> 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.
What you mean, I think, is that the arguments to filter_iterator<...>
are not concept checked.
> This would seem to indicate that the concept library is not being
> used to achieve its intended - and to my mind - most compelling
> purpose.
Yes, it is not being used to do concept checking for components like
filter_iterator.
> 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.
It's not really being used at all by the Iterator library; it's only
being extended. The iterator library defines concepts, so it provides
associated concept checking classes and archetypes. That allows
algorithm writers who want to use the library's concepts to add the
appropriate concept checks and test that their checks cover the actual
implementations.
>> 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.
For CRTP classes you can only do concept checking inside the member
functions because they are not instantiated until the derived type is
complete.
>>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.
No, that's a different case, much more akin to the traditional use of
concept checking on function templates. Take the top-level algorithm
(operator<< ?) that does the serialization and apply the concept check
there.
>>> 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.
It's simply not possible in general. Many of the things the concept
library checks for can't fail the test without causing a hard
compilation error (e.g. DefaultConstructible).
> I would seem to me that this could be implemented by just creating
> a slightly different definition of the BOOST_CONCEPT.. macros.
Nope; see above.
> And finally, I would be very interesting if someone were to write and
> article - "Canonical C++ Template Library"
nit: "Canonical Generic Library in C++"
Templates != Generic Programming
> 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
Nit: Archetypes aren't used to check concepts. Archetypes are used to
check stated concept requirements of generic functions (and classes)
against their actual implementations, to make sure that the
implementations don't use operations not demanded by the concepts.
> 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.
I have no idea how to do that, but up to this point I think it would be
a great exercise.
> d) show how to create tests semi-automagically
> from the above.
Nor that.
> 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.
Thanks for your interest. Too few people take advantage of the concept
checking library, but it can really help with your generic code and
doc's correctness and rigor. Once you are more comfortable perhaps
you'd like to write that article?
By the way, I think
http://www.generic-programming.org/languages/conceptcpp/tutorial/
probably does most of what you are asking about if you can mentally map
it back from C++0x into C++03 ;-)
Also, I really recommend reading through
http://www.generic-programming.org/about/intro/ before anything else.
It may be the best existing resource for the generic programming
process at the moment.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com