Re: [boost] [contract] Contract Programming Library

Subject: Re: [boost] [contract] Contract Programming Library
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-01-07 08:30:53

Lorenzo Caminiti wrote:
> 
> Vicente:
> 
>> Have you considered to add block invariants? Maybe you can complete the
>> table Contract Programming Feature Comparison.
> 
> I think block invariants could be added if there was interest. Indeed,
> I have already implemented a class for Eiffel-like loop-contract with
> both invariants and variants (but I never use it in real code).
> 
> In the Contract Programming proposal for the C++ standard, block
> invariants are interesting also because they allow for additional
> compiler optimization but this benefit does not apply to a library.
> 
> 
I understand that this will not help the compiler to optimize, but why use a
different technique to test the invariants of block? Why don't follow the
C++ proposal in this case?

Lorenzo Caminiti wrote:
> 
>> If I have understood your library require the type is CopyConstructible
>> to manage with postconditions. Have you considered to relax this
>> constraint?
> 
> Yes, the library requires that a type T is ConstantCopyConstructible
> in order for a variable of such a type to have old value in
> postconditions. However, this constraint only applies for a type T
> tagged copyable by programmers by copyable<T>. Therefore, if T is not
> ConstantCopyConstructible, or simply if its old value is not needed in
> postconditions, programmers do not tag T copyable and the library does
> not add any constraint on T (plus there is no extra copy overhead for
> old).
> 
> ConstantCopyConstructible is same as the CopyConstructible concept but
> the copy constructor must operate on a *const* source object "T::T(T
> const& source)".
> 
> 

Imagine a class that is able to implement the ConstCopyConstructor but that
don't wants to provide it to its users. This class can implement let me say
a ContractCopyConstructor like

  C(C const& rhs, backup_t);

When this constructor is defined your library could use it instead of the
missing ConstCopyConstructor.

We can go one step ahead an require from a class C that can be used on the
post-condition of a function that there is another class with the same
interface than C that can be copied from  a const reference to C.

Given the following trait

template <typename T>
struct backup {
  typedef T type;
};

You can request instead of C(C const&)

backup<C>::type(C const&);

If a class C has a backup D, we will add the following specialization

template <>
struct backup<C> {
  typedef D type;
};

This has some advantages:
* separates the creation of real instances from the needed by your library.
Thus avoiding the call to the CopyCOnstructor and destructor of the class
which can have non desirable side effects.
* allow to work with non-copyable classes
* the user of your library could reduce the scope of operations used on this
backup class making it more efficient, for example reducing the backed up
fields or the implemented functions
* the user can promote private or protected members to public.
 
Of course this has also some liabilities:
* the user needs to implement an additional class (optionally)

At the end the default behavior of my design corresponds to your current
behavior, letting the user the possibility to use more classes on the
post-condition part. Can this design be adapted to your library?

Just a last question, does your library avoid the evaluation of other
contracts during execution of the post-condition?

Best,
Vicente

-- 
View this message in context: http://old.nabble.com/-contract--Contract-Programming-Library-tp27024075p27059966.html
Sent from the Boost - Dev mailing list archive at Nabble.com.