Boost logo

Boost :

Subject: Re: [boost] [contract] static_assert in contracts or not?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-18 02:35:25

Le 18/09/12 06:14, Lorenzo Caminiti a écrit :
> On Sun, Sep 16, 2012 at 11:56 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Le 17/09/12 05:26, Lorenzo Caminiti a écrit :
>>> On Sun, Sep 16, 2012 at 6:31 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>>> on Mon Sep 03 2012, Andrzej Krzemienski <> 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 ;)
I'm referring to traits included in the standard. See Type
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


Boost list run by bdawes at, gregod at, cpdaniel at, john at