Re: [boost] [Review] Boost.Contract Review Period Extended

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.
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_4_1/doc/html/contract__/concepts.html

> 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):
http://sourceforge.net/apps/trac/contractpp/ticket/69
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")
{
    f_impl(x);
}

CONTRACT_FUNCTION(
    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:
http://sourceforge.net/apps/trac/contractpp/ticket/61
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:
http://sourceforge.net/apps/trac/contractpp/ticket/44

>   * 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 :)
--Lorenzo