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
archetype.
> > 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
restrictions are:
- 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
compiled?
> > - 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).
Best regards,
Robert