Re: [boost] [contract] Released Contract Programming Library on SourceForge
I have released on SourceForge a library that implements Contract Programming (a.k.a. Design by Contract(TM) ) for C++. I am considering to submit this library to Boost (as Boost.Contract).
Comments?
Hi, As I already said, I am very glad that we can see a good Contract library for C++. I have not used it yet, but I base my first opinion on the documentation; the topics it mentions (sub-contracting, disabling contract checking within contract checks, the "oldof"), and references, proves that you have thoroughly investigated the subject. This is first such library for C++ that I am aware of. I am almost sure I will not use it in my work, in production code. I have trouble convincing my colleagues to use templates, as they are not used to "non-Java" syntax, and they find it suspicious. I am not sure how I would be able to convince anyone to writing: (class)(copyable)(myvector)(inherit)(pushable<T>)(public)(void)(push_back)( (const T&)(element) ) I am not even convinced myself. The IntelliSense will go mad. I understand the constraints you are under, but still... Perhaps if you do require this syntax, you should offer something more in exchange than only contract checking: hooks for IntelliSense, meta-data of contract-checked functions that the user can use like other type traits, etc... On the other hand, I believe the library is a very important step to introducing contract checking into C++ standard. Contracts were labeled as "No active interest today, but open to resubmit in future". Having gained a practical experience with C++ contracts, both implementability and usage, may be a good argument for reconsidering the proposal. C++ is so particular a language that the experience from Eiffel, which is mainly an OO language, usually would not apply; for instance, I could define equality as: bool operator==( MyType const& lhs, MyType const& rhs postcondition( result ) { result == !( lhs != rhs ); }; bool operator!= MyType const& lhs, MyType const& rhs ) postcondition( result ) { result == !( lhs == rhs ); }; or: bool operator==( MyType const& lhs, MyType const& rhs ); template< typename T > bool operator!=( T const& a, T const& b ) { return !(a == b); } // no post-condition required Which solution should I prefer? For an another example, if I am a defensive programmer, should I write: int compute_area() const postcondition( ans ) { ans > 0; }; or: unsigned int compute_area() const postcondition( ans ) { ans != 0; }; or: PositiveInteger compute_area() const; // compile-time checking - even better Similarly, for loop variants, I would be interested to know how it can or cannot or need not be used in more c++ specific loops: for( auto v : setOfValues ) { process(v); } How do I define a variant? Or is a variant needed? Perhaps the sole usage of "for each" guarantees termination? Or this one: std::ofsteam file("input.txt"); std::string text; while( file >> text ) { process(text); } Regards, &rzej
Hello Andrzej, On Mon, Mar 1, 2010 at 9:05 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
This is first such library for C++ that I am aware of.
Also, I have not seen any other Contract Programming (CP) library that supports old and subcontracting without using code preprocessing tools external to the language.
I am almost sure I will not use it in my work, in production code. I Of course, my goal has been to develop a CP library that can be used in production code. not used to "non-Java" syntax, and they find it suspicious. I am not sure how I would be able to convince anyone to writing:
(class)(copyable)(myvector)(inherit)(pushable<T>)(public)(void)(push_back)( (const T&)(element) )
I am not even convinced myself.
I agree: The signature sequence syntax is the key limitation of the library. Other people have made this exact same comment. I wish I could address this limitation... but I can only repeat that: 1) I have used the library in a couple of real projects (one of which an embedded safety critical system with ~60,000 lines of C++) and the library syntax was usable. However, I am not the best person to assess if the syntax is tolerable given how closely I have been dealing with this syntax in developing the library. 2) Other Boost libraries (Boost.Parameter, Boost.ConceptCheck, etc) also use a strange macro syntax. However, the signature sequence syntax of this library will affect *all* declarations with a contract (and that's a lot of code in a real project). I personally would feel OK in proposing the adoption of this syntax but only if I was sure there was *no other way* to bring CP into C++. I was not able to find any other way so far... but how can I be sure that there is no other way??
Perhaps if you do require this syntax, you should offer something more in exchange than only contract checking: hooks for IntelliSense,
I think the library objective will remain CP. Of course, if CP is not enough benefit to justify the adoption of the syntax, it is OK for people not to use the library.
introducing contract checking into C++ standard. Contracts were labeled as "No active interest today, but open to resubmit in future".
Actually, based on the reactions I had for my library, I have to say that (sadly) "No active interest today, but open to resubmit in future" sounds like a fare assessment of the current C++ community interest in CP. I would be happy to see CP added to the C++ language (so I won't have to program function signatures using Boost.Preprocessor sequences anymore :)) ) but I am not convinced C++ programmers will extensively use CP even in that case. This is just my opinion of course.
the proposal. C++ is so particular a language that the experience from Eiffel, which is mainly an OO language, usually would not apply; for
True. Because of this my library tries to systematically support contracts for all C/C++ constructs and not just for the OO ones (non-member functions, external linkage, etc). However, in my experience CP becomes truly powerful only when class invariants are used so I think of CP mainly as an OO technique.
Similarly, for loop variants, I would be interested to know how it can or cannot or need not be used in more c++ specific loops:
I have never found loop variants useful in my practical experience... they are a theoretically solid tool and they might be good to program code that has to be "proven" correct on the board... at the end the loop variants implementation essentially came for free after implementing all other library features.
participants (2)
-
Andrzej Krzemienski -
Lorenzo Caminiti