Re: [boost] [contract] Released Contract Programming Library on SourceForge

Subject: Re: [boost] [contract] Released Contract Programming Library on SourceForge
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-03-08 21:22:09

Hello Andrzej,

On Mon, Mar 1, 2010 at 9:05 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> 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.