Subject: Re: [boost] [concept_check] Some issues
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2011-11-25 20:05:59
> From: Stewart, Robert
> > - The implementation of assignable_archetype defines private
> > default and copy constructors, so for example
> > assignable_archetype<copy_constructible_archetype<>> will not
> > actually be copy constructible. The same for
> > convertible_to_archetype and convertible_from_archetype, but
> > additionally with copy assignment. Is this by purpose?
> I should think that's by design. The archetypes are to validate a
> particular concept checking class, so a copyable or default
> constructible archetype for Assignable would be wrong.
I wouldn't say it's wrong. If you can combine several concepts, you should
be able to combine the corresponding archetypes too. If your template
requires more than one concept (e.g., a type that is BOTH copyable AND
assignable), then without the ability of chaining you would have to write
your own archetypes in all but the most trivial cases.
> Are archetypes are supposed to be composable?
I guess they are since most of them have the Base template parameter.
> Even if so, not all combinations are possible.
Could you give an example of an impossible combination?
> > - copy_constructible_archetype defines public default
> > constructor - again, am I overlooking something or it should
> > not be there?
> I wouldn't think so.
> > - Function and predicate archetypes also seem to provide too
> > wide interface (they are copy constructible and assignable).
> Since you're asking, and I haven't checked to verify it, I presume that
> those operations are not part of the corresponding concepts. If so,
> then I agree they should not be available.
What should be done about this, then? Removing the superfluous functions may
break some tests, but I guess in this case it is even desirable because it
means the tests have errors that were undetected so far. I don't know why a
valid test would depend on a function that should not be a member of an
> > Additionally, they don't allow for archetypes chaining since
> > they lack the Base parameter (with the only exception of
> > binary_predicate_archetype - why the inconsistency?)
> Are they supposed to be generally chainable?
Actually I also wasn't sure before I wrote my previous mail and to verify
this I've written my own set of archetypes to test my library. They look
similarly to the ones in concept_archetype.hpp modulo all the issues I've
mentioned. They also don't provide any function implementations, only
declarations[*]. They seem to work fine with chaining. The only two
- default_constructible_archetype must be on top of any other archetypes
that have any constructors (otherwise the constructors of the derived
archetype would prevent generation of default constructor),
- convertible_from_archetype must be the top-most archetype of all chained
archetypes (because constructors aren't inherited).
Note that there are no such problems with copy_constructible_archetype and
assignable_archetype because the functions are always generated
automatically (unless the base class doesn't have them or makes them
inaccessible - but no other archetype than the two should have them and the
only one that makes them inaccessible is null_archetype, which is always at
the end of the chain).
[*] Why the implementations are provided in concept_archetype.hpp, BTW? Are
there cases where concept checking programs should be linked, not only
> > - Apart from the provided function object concepts and
> > archetypes it seems it would be useful to have a general
> > Callable concept and the corresponding callable_archetype,
> > parameterised with the types of arguments and return value.
> > Wouldn't it be valuable to add them?
> That seems plausible and useful.
Other things I miss are: separation of predicate_archetype from
const_predicate_archetype etc. (currently implementation of the former is
actually the latter) and not requiring const arguments in
*_function_archetype (the constness can be expressed in the template
argument if needed).
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk