Boost logo

Boost :

Subject: Re: [boost] [contract] Released Contract Programming Library on SourceForge
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2010-03-01 09:05:40


> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk