On Sun, Sep 16, 2012 at 11:56 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 17/09/12 05:26, Lorenzo Caminiti a écrit :
On Sun, Sep 16, 2012 at 6:31 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Sep 03 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote:
I do not know if Boost.ConceptCheck offers the capability of verifying any boolean predicate.
Sure; even if the concept isn't already in the library, you can easily write it.
So if we can program a static boolean predicate then we can program a ConceptCheck concept that will statically assert it and make it fail at compile-time. I guess however that the opposite is not true. There are conditions that can be programmed to generate a hard compiler failure (e.g., using ConceptCheck) but we cannot create a boolean meta-function for them (e.g., to use enable-if and/or SFINAE-like concepts).
For example we can program CopyConstructible but we cannot program has_copy_constructor--am I correct? Is that true with C++11 expression SFINAE as well?
This depends on the c++ version as some traits need compiler help.
Compiler help outside the standard (either C++03 or C++11) doesn't count ;)
In C++11 there are some traits as has_copy_constructor, has_trivial_copy_constructtor, ...
True.
If that is the case, there can be type requirements that we can only program using hard-failing-concepts (ConceptCheck concepts within Contract's check clause) but not using SFINAE-concepts (possible future Boost.Contract's requires clause).
You are surely right, but it is less evident for c++11.
True.
Do you have an example?
Not on top of my head, I'll probably have examples after studying N3351. In any case, this is just an argument to have /both/ hard-error-concepts and enable-if-concepts (if Boost.Contract will ever support both, I'll have to document why that is the case). BTW, now that I'm thinking about it, if you use Boost.Contract to declare a class/function, I /might/ be able to expand some extra code that will support compile-time trait inspection... For example, has_copy_constructor /could/ be made to work for a constructor declared using CONTRACT_CONSTRUCTOR even on C++03 and without extra compiler help... I'll look into this if/when extending Boost.Contract to support N3351-like concepts. Thanks, --Lorenzo