On Sat, Oct 1, 2011 at 3:43 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 1 October 2011 13:47, Lorenzo Caminiti <lorcaminiti@gmail.com> 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/cont... 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