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 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
On Sun, Sep 16, 2012 at 6:31 PM, Dave Abrahams <dave@boostpro.com> wrote: 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 ;) I'm referring to traits included in the standard. See 20.9.4.3 Type
Le 18/09/12 06:14, Lorenzo Caminiti a écrit : properties [meta.unary.prop] C++ International Standard
In C++11 there are some traits as has_copy_constructor, has_trivial_copy_constructtor, ... True.
Sorry, the names are is_copy_constructible, is trivially_copyable, ...
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
I don't know if this this is a valid argument. I would say that we need "enable_if" to avoid instantiation that will result on compiler error and static assertions to report bad instantiations at compile time.
(if Boost.Contract will ever support both, I'll have to document why that is the case). I guess the preceding is just a good justification.
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.
Yeah, this will be great. I think this could be done before including enable_if as the user can take advantage of these traits independently of whether the class's user uses Boost.Contract or not. I you want I could help proposing the addition of these traits in Boost.TypeTraits so that they can be specialized by the user and by Boost.Contract in particular. Best, Vicente