
Hello all, Shall Boost.Contract static static assertions? 1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why? 2) In my experience, I never used static assertions within the contracts. However, I am thinking to provide them because they might be useful to better document contract interfaces with assertions that can be efficiently evaluated at compile-time. For example: template<typename T> struct x { CONTRACT_CLASS( (x) ) public: CONTRACT_FUNCTION( (public) (void) (f)( (T)(val) ) (precondition)( (static)(sizeof(T) <= sizeof(long)) // static assertion (checked at compile-time) (val != 0) // run-time assertion ) ({ ... }) }; This code will use one of the BOOST_MPL_ASSERT() to assert the static condition in the precondition function generated by the CONTRACT_FUNCTION() macro. I think this is similar to asserting BOOST_MPL_ASSERT((sizeof(T) <= sizeof(long))) in the function body or at class scope. However, having the static assertion in the contracts has the following advantages: (+) The static assertion compilation and check can be selectively enabled/disabled when preconditions/postcondition/invariants are turned on/off using CONTRACT_CHECK_PRECONDITON/etc. (+) It more clearly documents that the (static) requirement `sizeof(T) <= sizeof(long)` is added by the function f (instead of the class or some other member function). -- Lorenzo

On Thu, May 13, 2010 at 4:24 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Lorenzo Caminiti skrev:
Shall Boost.Contract static static assertions?
1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why?
static_assert was added to the language.
Makes sense. Do you think it would be valuable for my library to support static assertions? -- Lorenzo

----- Original Message ----- From: "Lorenzo Caminiti" <lorcaminiti@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, May 13, 2010 10:32 PM Subject: Re: [boost] [contract] static assertions
On Thu, May 13, 2010 at 4:24 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Lorenzo Caminiti skrev:
Shall Boost.Contract static static assertions?
1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why?
static_assert was added to the language.
Makes sense.
Do you think it would be valuable for my library to support static assertions?
If what you want is a uniform way you could always forward to the Boost.StaticAssert library. Boost.Mpl provide also some interesting variants that could also be forwarded. Best, Vicente

On Sat, May 15, 2010 at 8:50 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
----- Original Message ----- From: "Lorenzo Caminiti" <lorcaminiti@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, May 13, 2010 10:32 PM Subject: Re: [boost] [contract] static assertions
On Thu, May 13, 2010 at 4:24 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Lorenzo Caminiti skrev:
Shall Boost.Contract static static assertions?
1) N1962 removed static assertions previously added by revisions N1866 and N1773 of the same proposal -- why?
static_assert was added to the language.
Makes sense.
Do you think it would be valuable for my library to support static assertions?
If what you want is a uniform way you could always forward to the Boost.StaticAssert library. Boost.Mpl provide also some interesting variants that could also be forwarded.
Yes, I have implemented this in the past couple of days. Something like `(precondition)( (static)(boost::is_const<T>) )` expands using `BOOST_MPL_ASSERT_MSG()` and it works quite nicely. Now that I have implemented Boost.ConceptCheck and Boost.Parameter support within Boost.Contract, there are quite a few ways to check static conditions: 1) Boost.ConceptCheck concepts -- as usual at the template parameter level. 2) Boost.Parameter parameter type requirements -- as usual at the function parameter level. 3) Boost.Contract static assertions -- at the precondition/postcondition/class-invariant level. Even if all these checks evaluate at compile-time, they are all semantically different. I will make sure to document them and provide examples. Thanks. -- Lorenzo
participants (3)
-
Lorenzo Caminiti
-
Thorsten Ottosen
-
vicente.botet