Re: [boost] [Review:Contract] Some questions

Subject: Re: [boost] [Review:Contract] Some questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-08-26 13:04:53

Le 26/08/12 11:16, Vicente J. Botet Escriba a écrit :
Hi,
>
>
> First of all, thanks Lorenzo for your work on pre-processor 
> programming. With this library, you have showed to me how far the 
> pre-processing can go in terms of expressiveness.
>
> I have some questions before doing a complete the review:
>
Hi again,

more comments and questions follows

= member initializers =

Why the following limitation?
"Unfortunately, when member initializers are specified, the constructor 
body must be defined together with its declaration and contract."

= C++03 limitations =

It would be great if you add a section/table with all the limitations, 
as e.g. these ones

* Function and array types cannot be directly used as function parameter 
types within the contract macros ...
* Each function parameter must always specify both its type and its name 
(parameter names can instead by omitted in usual C++ declarations).
* All tokens must be specified in the fixed order listed in the Grammar 
section (it is not possible to specify postconditions before 
preconditions, |volatile| before |const| for member functions, etc).
* Unfortunately, this library does not allow to specify contracts for 
unions.
* Unfortunately, when member initializers are specified, the constructor 
body must be defined together with its declaration and contract

and use some kind of as Warning or Important when documenting them.

= use of deferred =

IMO deferred is related to the time dimension, while I think you are using it on the space dimension. "The function body definition can be separated" is OK, but deferred :(

= _BODY macros =

Why do you need to make a difference between CONTRACT_FREE_BODYand 
CONTRACT_MEMBER_BODY while there is a single CONTRACT_FUNCTION?

What if the user uses CONTRACT_FREE_BODYwhen it should use 
CONTRACT_MEMBER_BODY? It will not have the associated class invariants.
The user will see this error very late when she realize that the 
function is breaking a class invariant (by other means).
I think it will be better if the syntax forces an error in this case. 
What about

template<  typename  T,  T  Default  >
bool  CONTRACT_MEMBER_BODY((natural<T,  Default>),equal)  (  natural  const&  right  )
         const
{
     return  not  less(*this,  right)  &&  not  greater(*this,  right);
}

This will make more homogeneous |CONTRACT_CONSTRUCTOR_BODY|, 
|CONTRACT_DESTRUCTOR_BODY|, and |CONTRACT_MEMBER_BODY.|
What do you think?

= ( void ) || empty macro parameters =
|
For projects that don't care about portability, or just use compilers 
that supports the | empty macro parameters it will be great if they can 
use () instead of ( void ) to represent no parameters.
Could you provide this?

= _TPL macros and performance =

Could you give some figures of the gain of the change of introducing the 
_TPL macros?

= Static assertions =

What is the interest of disabling static assertion when 
|CONTRACT_CONFIG_NO_PRECONDITIONS|, |CONTRACT_CONFIG_NO_POSTCONDITIONS| 
are defined?

= return =

^" *Rationale.* The result type needs to be copyable in order for the 
function itself to return a value so this library can always evaluate 
return value declarations."

This is only true if rvalue references are not supported. Otherwise, for 
MovableOnly types the variable used to store the return value could be a 
rvalue reference and move semantics should be applied.
Even if you don't support C++11, the user can use Boost.Move.

Best,
Vicente