On Thu, Sep 6, 2012 at 7:05 AM, ecyrbe <ecyrbe@gmail.com> 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_...
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