Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Contract Review Period Extended
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-09-06 11:57:20

On Thu, Sep 6, 2012 at 7:05 AM, ecyrbe <ecyrbe_at_[hidden]> wrote:
> I vote NO for the inclusion of the contract library in Boost.

Thanks a lot for submitting a review!

> I do agree that the work done is really interresting, but i don't think
> that using MACROS are the way to add this functionnality.

Sure this'd be ideal but... do you have any suggestion on how to
implement Contract Programming within C++ without using macro? I
thought about this problem a lot (that of "not using macros" was even
an original goal when I started creating the library 4+ years ago) but
I had to conclude it's impossible... For example (and there are more
examples like this) how would you implement the following CP
requirements without macros?
1. If a function is not public, don't check class invariants.
2. Subcontracting.

> Here are some thoughts why i think it should not be accepted:
> - i don't think that concepts should be part of the library. concepts and
> contract programming should not be mixed, they do not adress the same
> problem, they have not the same scope.

I disagree. Contracts specify how the program interface should behave
at run-time. Concepts specify how the program interface should behave
at compile-time. They both specify how the program interface is
intended to behave only some of the specifications can be checked at
compile-time while other can only be checked at run-time.

> The first is used at execution time,
> the other at compile time.

Yes, but as I said they are both used to program specifications.

> - langage extensions

If by language extensions you mean "compiler specific extensions of
C++ declaration features" I can make an attempt to support the most
common ones (MSVC's __declspec, etc):
Do you have any specific extension in mind? Also if you really need to
use a compiler-specific extension that is not supported you could
probably wrap the contracted funciton (if this is effective it might
ultimately depend on the particular extension...):

int f ( int x ) __my_compiler_decl_extension(1, "abc")

    int (f_impl) ( int x )
        precondition( x >= 0 )
        postcondition( auto result = return, result == x * x )
) {
    // ...

> , c+11 syntax,

I will support C++11 declaration features:
As for the syntax, the lib declaration syntax is somewhat different
from both C++11 and C++03 declaration syntax.

> can't be really used, thus limiting the
> real benefit of this design.
> - compiler syntax error can be more cryptic to analyse with macro
> encapsulation.

Yes, compiler errors in the declarations are cryptic because of the
macros :( I can try to improve this a bit but there are fundamental
limitation of what can be done with the pp:

> * What is your evaluation of the design?
> Despite the fact that i do not agree with the design taken to implement
> contract programming, i have to say that this library has some good macro
> design. A really nice job.
> * What is your evaluation of the implementation?
> i 'm not found of macros... so i can't comment on that.
> * What is your evaluation of the documentation?
> A really good job was done.
> * What is your evaluation of the potential usefulness of the library?
> A contract programming library could benefit boost. But i don't think that
> this library could be really used in production software industry beacause
> of it's use of macros.
> * Did you try to use the library? With what compiler? Did you have any
> problems?
> No.
> * How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> I only took the time to read the documentation.
> * Are you knowledgeable about the problem domain?
> I still use eiffel contract programming, so i think i'm a knowledgeable
> user of contract programming.

Thanks :)

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