Re: [boost] [contract] Macro syntax?

Subject: Re: [boost] [contract] Macro syntax?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-04-06 14:12:52

----- Original Message ----- 
From: "Lorenzo Caminiti" <lorcaminiti_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 06, 2010 3:59 PM
Subject: Re: [boost] [contract] Macro syntax?

> 
> On Sun, Mar 21, 2010 at 4:06 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
>> I see the probelems this could introduce. I think howver thatn we should try to provide interfaces that don't impose the user to repeat redundant information.
> 
> What do you think if I provide both family of macros?
> 
> 1) CONTRACT_CLASS() and CONTRACT_FUNCTION() which follow the relative
> class and function declarations as coded by the programmers.
> 2) CONTRACT_CLASS_DECL() and CONTRACT_FUNCTION_DECL() which also
> automatically program the class and function declarations so
> programmers do not have to code the declarations manually outside the
> contracts.

Yes, this could be an option. 
<snip>
 
> The CONTRACT_XYZ_DECL()  macros have the following pro (+), cons (-),
> and neutrals (~) compared to the CONTRACT_XYZ()  macros:
>    (+) There is no code duplication when using CONTRACT_XYZ_DECL()
> (because the signature tokens only appear within the macro and not
> also before the macro).
>    (+) When using CONTRACT_XYZ_DECL(), the declarations tokens will
> always match the ones in the contract because they are not duplicated.
> When using the CONTRACT_XYZ() macros instead, a mismatch between the
> declaration and the contract signature tokens will generate a compiler
> error in most, but not all, cases.

Right.

>    (-) The code using CONTRACT_XYZ_DECL() is more difficult to read
> to whom does not know the library syntax because all usual C++ syntax
> is gone.

Yes, but the other option is not too readable neither.

>    (-) All compiler errors for the class will appear with the same
> line number because the CONTRACT_CLASS_DECL() macro will expand the
> entire class definition on a single line. I think this is a major
> defect of the CONTRACT_XYZ_DECL() macros because it will make C++
> compiler error even harder to track than they currently are.*

This is a major drawback.

>    (~) The CONTRACT_XYZ_DECL() macros will need to accept additional
> information like inheritance access level, default parameter values,
> exception specifications, etc. However, the CONTRACT_XYZ() macros
> already contain most of the syntactic tokens of class and function
> declarations so this is not much of a complication of the macro
> signature syntax.
> 
> (*) This issue can be avoided by mixing the use of CONTRACT_CLASS()
> with CONTRACT_FUNCTION_DECL() and separating the function definition
> from its declaration. This way both the class and function definition
> code will not be wrapped by any of the CONTRACT macros and the
> compiler error line numbers will retain their usual meaning.

Yes this could improbe the error reporting a little bit.

Lorenzo, As the () syntax is quite ugly, I was wondering if adding a contract preprocessing phase CP_PP could be a option to consider. 
Each contract programming line could be prefixed by a comment such as //~//.

    template<typename T>
    class myvector: public pushable<T> { 
        //~// invariant {
        //~//     (size() == 0) == empty();
        //~// }

    public:
        void push_back(const T& element)
          //~// precondition {
          //~//   size() < max_size();
          //~// }
          //~// postcondition {
          //~//   size() == oldof(this)->size() + 1;
          //~// }
        {
           vector_.push_back(element);
        }
        ....
    private:
        std::vector<T> vector_;
    };

As any CP sentence is commented with a C++ comment this code could work without CP preprocessing.

The CP_PP could generate #line directives so the original lines are preserved when warning or errors message are reported by the compiler.

The generated file could be generated in a specific contract directory so these files can be sees by the compiler before the original ones. The user will just need to add -Icontract directives.

Best,
Vicente