Boost logo

Boost Users :

Subject: Re: [Boost-users] [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Mika Heiskanen (mika.heiskanen_at_[hidden])
Date: 2008-12-21 13:05:56


Robert Kawulak wrote:
>> From: Mika Heiskanen
>
>> For example, I cannot let my server crash
>> if it cannot fulfill a particular type of request due to a
>> programming error.
>> Instead it should log the error and fail that particular
>> request.
>
> If one invariant fails, this means your program is not reliable anymore (also
> when processing subsequent requests). Other invariants may become invalid too
> and any assumptions made during writing of your program may not hold anymore.
> This means that the program will most probably start behaving in an unexpected
> way. I think in most cases it is preferred to crash the program than allow it to
> produce invalid output and, for example, store it in a database.

Wikipedia definition for an invariant:

  "In computer science, a predicate that, if true, will remain true throughout
   a specific sequence of operations, is called (an) invariant to that
   sequence."

So it seems all the confusion is due to my misunderstanding of what an
invariant is. The simple definition I knew until now was that an invariant is
something that does not change value. What I was missing was that it also has
to satisfy the constraints before you can actually call it an invariant, and
hence it makes no sense to test the constraints again once you can call
something an invariant.

Note for example that the page

   http://en.wikipedia.org/wiki/Invariant

says

   "Invariant (computer science), an expression whose value doesn't change
    during program execution."

IMO that definition means something completely different from the definition
with the predicate included.

I believe the confusion is thus resolved, sorry for the noise.

Kind regards,

--> Mika Heiskanen


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net