Re: [boost] [contract] the volatile issue

Subject: Re: [boost] [contract] the volatile issue
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-10-01 19:20:33

On Sat, Oct 1, 2011 at 3:43 PM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 1 October 2011 13:47, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>> N1962 does not indicate that contracts for volatile members should be
>> handled in any special way (in fact, volatile is not discussed at all
>> in N1962).
>
> In practical terms, I'm not sure I want checkable contracts for
> volatile members.
>
> volatile roughly means that if I need it for my program to work,
> something outside of the normal flow of execution will happen to the
> object.
>
> Either it will have side effects when I access it, or its value can be
> changed out from under me.  Given those two situations, how do you
> envision checkable contracts to work?

Yep, I agree. I have two alternative: (1) I generate a compile-time
error if you contract a volatile member or (2) I support volatile
contracts as best as I can given that volatile is part of C++ and
leave it to programmers to contract or not their volatile code.

Now, assume I want to take option (2), I'm hinting that it makes sense
to allow programmers to specify different class invariants for
volatile members given that programmers can already specify different
pre/postconditions for volatile members (in case they overload a
non-volatile member). What do you think?

> There is also the idea that Andrei Alexandrescu put forth in
> <http://drdobbs.com/cpp/184403766> to use volatile member functions
> for other purposes.  Is that the kind of thing you envision applying
> contracts to?

[side note
Cool trick! BTW, on the concurrency + Contract Programming (CP) topic,
Meyer goes a long way discussing concurrency and the challenges it
poses to Contract Programming (especially postconditions) in his book
Object-Oriented Software Construction-- finally he ends up with SCOOP:

http://se.inf.ethz.ch/old/people/nienaltowski/papers/scoop_easy_draft.pdf

AFAIK, SCOOP was never actually fully implemented and much less used
in real code. Plus it's just one way to sync stuff (and as long as you
sync before checking contracts when necessary, you can use any
synchronization method you want). I myself once implemented a
primitive C++ version of SCOOP that used a smart pointer
separate_ptr<C> where C is an object that is accessed by multiple
threads (maybe I can go back and apply Andrei's LockingPtr volatile
trick to my separate_ptr...).
]

> The uses I've seen of volatile on non-primitive types is almost always
> a programming error.  Do you have practical examples where this is not
> the case?

Nope, I have _no_ practical example :( I've never ever used volatile
in my real projects. In all the CP references I have studied I've
never seen volatile used:
http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/contract__/bibliography.html

Nevertheless, given that I'm trying to implement CP for C++, I need to
address how CP will/should work with volatile just because volatile is
part of C++.

If anyone from Boost has a real-life example of a volatile type that
could benefit from contracts, it'd be great to see it!

Thanks,
--Lorenzo