Boost Testing :
Subject: [Boost-testing] [concept_checking] How is this intended to be used.
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-24 16:43:20
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.
Its still not clear to me and I have a couple of questions.
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.
..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.
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. 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.
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
So what's the recommended/intended usage of the concepts checking
That's the first question. Here is the second one:
I understand that violating a constant constraint will generate a syntax
error at the point of violation and this will preven the program from
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:
which would flag this at the point of invocation?
Thanks in advance.