[std-interval] More on interval computations as proofs
Sylvain.Pion at sophia.inria.fr
Sun Oct 8 15:12:30 PDT 2006
Gabriel Dos Reis wrote:
> Sylvain.Pion at sophia.inria.fr writes:
> | > Dr John Pryce <j.d.pryce at ntlworld.com> writes:
> | >
> | > | All
> | > |
> | > | There seems a consensus, and so far no sharp opposition, that we
> | > | should implement the DISCONT flag as a global, thread-local flag and
> | > | accept the limitations on optimization that this entails, as per
> | > | Sylvain's posting:
> | >
> | > I disagree with the global flag suggestion and will seriously raise
> | > that issue within the C++ LWG. I would really like the proposal to
> | > take the objection seriously.
> | >
> | > I had a chance, yesterday, to talk bit about this issue with my
> | > colleagues here -- also involved in the C++ standardization -- and the
> | > reaction was unanimous.
> | Do you have anything concrete to propose as a better
> | alternative ?
> yes, but you "shot it down". :-)
> [ I just wanted to "correct" the observation that there seems a
> consensus, when in fact the discussion fade out because no new information
> was brought forward that could change people's mind either way :-) ]
You are right. There is no consensus.
> | Throwing exceptions was shot down for speed and
> | stack-destroying reasons, and addition of a bool&
> | argument is not liked because it is a poorly
> | readable notation.
> the "global flag" is likely to be "shot down" for lack of
I need to get back to Steve's explanation and see how it is a
problem in practice for our case. IIRC, John wrote in an email
something I think is reasonnable, which basically says that
it's not a problem here.
But maybe the issue has not been enough understood (at least by me).
A concrete example might help.
> | I thought about it a bit more than what I wrote so far.
> | You mentionned exceptions. What I recognize is good with
> | exceptions here is the "scope" that they encapsulate,
> | which corresponds to what we are looking for. However,
> | they are too costly when they throw (and there is no sign
> | that this will improve in the future as this is not their
> | goal).
> it is a _quality of implementation issue_.
> What would be needed is a study of say Sun's framework for nearly
> zero-overhead exception implementation, versus other "reasonable"
> alternative. Notice that the exception overhead need not to be zero,
> just acceptable enough to compete with the inefficiency and inelegance
> of a global flag. (I do know that some of my colleagues are seriously
> concerned about exception implementations in some compilers -- and
> this concern is independent of the interval discussion).
Good to read something like that. Indeed if a compiler can manage to
deal with exceptions with reasonnable performance, this can improve
the range of applicability of exceptions.
> | I then wondered if we could invent, possibly with
> | a language extension, a non-stack-destroying way to report
> | errors corresponding to a "scope" similar to what exceptions
> | cover. I think that this is possible through a list of
> | flags put on the stack and linked together, with the top
> | of the stack pointed to by a global pointer.
> | I do not believe that this can help much performance-wise
> | anyway compared to the gloabl flag solution, as there is
> | still a global thing somewhere.
> I don't fully understand your suggestion, but as a general
> observation, compilers seem to do better job with objects local to
> frame activation (i.e. stack-allocation) than with global objects.
> Now, that migh or might not help at all, depending on the exact
> details of what you're thinking about.
> | I don't know precisely how exceptions work, but they
> | probably use some global information somewhere as well.
> yes, but as I understand it not all operations will use/raise
> exceptions; is that correct?
Correct. operator+,-,* are defined and continuous everywhere,
for example, so will never throw (or raise the flag).
> The language provides a way to tell the
> compiler that an operation is not going to throw an exceptions.
> Similar information concerning use (or lack thereof) of other entities
> is much more involved or impossible.
More information about the Std-interval