Boost logo

Boost :

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.
> 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.
> 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.


> (-) 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();
        //~// }

        void push_back(const T& element)
          //~// precondition {
          //~// size() < max_size();
          //~// }
          //~// postcondition {
          //~// size() == oldof(this)->size() + 1;
          //~// }
        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.


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