[Review] Boost.Contract Review Period Extended
We've had lots of good discussion, and gotten three votes so far, but for a library of this scope I would like to see more. Therefore, we're extending the review period through Sept 7th. Please take the time to look at it, and *please vote for or against acceptance*. As noted below, everyone who looks at the library is qualified to vote, and every vote is valuable. Thanks, Dave ,----[ Important Notes ] | - Please post your review to the Boost Developers' list | (http://lists.boost.org/mailman/listinfo.cgi/boost) | - Please begin your review's subject line with "[Review:Contract]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
I vote NO for the inclusion of the contract library in Boost. 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. 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. The first is used at execution time, the other at compile time. - langage extensions, c+11 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. * 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.
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
2012/9/6 Lorenzo Caminiti <lorcaminiti@gmail.com>
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 think my tone could seem a litle rude. I forgot to congratulate you for the long a hard work you have done on this library.
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.
I would like to comment on this. I know that making a Eiffel like integrated contract programming in c++ in not feasible. But i think that an original one, maybe based on functors could be possible (may be i'm totally wrong). something declared like a boost::function<Signature>, but using something like : boost::contract<Signature> push_back; and has to be initialized like this : push_back(precondition_functor, real_push_back_functor,postcondition_functor); and if any invariant is declared : push_back(precondition_functor, real_push_back_method,postcondition_functor, invariant_functor); I know that it's not easy to implement functors in c++03 , but in c++11 with lambdas, you could initialize this really easily, and still have a nice library. For c++03, you still could provide a macro frontend to allow users to implement this easily, but having a more native way to do it in c++11 would be awesome. What i want to say, is that, i would have said YES to this macro frontend if a nice c++11 compliant backend was exposed to those that don't want to use macros. These are only thoughts. Thanks for reading.
On Thu, Sep 6, 2012 at 9:57 AM, ecyrbe <ecyrbe@gmail.com> wrote:
2012/9/6 Lorenzo Caminiti <lorcaminiti@gmail.com>
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 think my tone could seem a litle rude. I forgot to congratulate you for the long a hard work you have done on this library.
Your tone is good, don't worry and thanks :)
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.
I would like to comment on this. I know that making a Eiffel like integrated contract programming in c++ in not feasible. But i think that an original one, maybe based on functors could be possible (may be i'm totally wrong).
something declared like a boost::function<Signature>, but using something like :
boost::contract<Signature> push_back;
and has to be initialized like this :
push_back(precondition_functor, real_push_back_functor,postcondition_functor);
and if any invariant is declared :
push_back(precondition_functor, real_push_back_method,postcondition_functor, invariant_functor);
I know that it's not easy to implement functors in c++03 , but in c++11 with lambdas, you could initialize this really easily, and still have a nice library. For c++03, you still could provide a macro frontend to allow users to implement this easily, but having a more native way to do it in c++11 would be awesome.
Also let's keep in mind that contracts should be specified at the declaration site. In any case, this is the best I was able to do without using macros (rev 0.3.490 of the lib that still supported the non-macro API): http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_... Essentially this used function pointers (I guess you could similarly use functors) to pass to the lib the functions that checked pre/post/etc so the lib could check. This was abandoned because of the large amount of boiler-plate code that users have to program, including repeating the function signature a few times to program the pre/post/body/etc functions to pass to the lib. Also subcontracting relied on the user repeating bases classes everywhere making the code very hard to maintain. Finally, disabling the contract code on compilation (i.e. removing the pre/post/body/etc functions/functors) required the user to manually program #ifdef and the all thing got pretty ugly.
What i want to say, is that, i would have said YES to this macro frontend if a nice c++11 compliant backend was exposed to those that don't want to use macros.
These are only thoughts.
Thanks for reading.
HTH, --Lorenzo
participants (3)
-
Dave Abrahams -
ecyrbe -
Lorenzo Caminiti