Re: Bounds Check Overhead

[nospam@see.signature (Richard Maine)]

Dan Nagle <dannagle@verizon.net> wrote:

> Hello,
> 
> gary.l.scott@lmco.com wrote:
> > I was just thinking that if the loop counter was in fact declared to be
> > volatile, that the declaration of such should cause the compiler to
> > diagnose it as an incompatible loop index variable (i.e. F2k8+).
> 
> In 04-007, at 167[22:23], the <do-index> may not be redefined.
> 
> The volatile attribute, at 85[5:6], specifies that the variable may
> become undefined or redefined by a means outside the program.
> 
> I suppose it's a theorem left for the reader to prove that
> a do-index should not be volatile, or at worst, if it is,
> the volatile part is ineffective.
> 
> I'll ask on the J3 list to see whether there's sentiment
> for addressing this directly, or if I missed something
> in my quick perusal of the standard.

I think you are missing half of the purpose of volatile. You've got the
half about a volatile variable possibly getting modified elsewhere, but
you forgot the part about the volatile variable possibly being
referenced elsewhere. They are the opposite sides of the same coin,
depending on whether you are sedning data to or getting data from the
external source. The volatile attribute doesn't distinguish.

I see nothing inherently wrong in making a loop variable volatile so
that some external source can reference it. It is likely to kill the
performance of the loop, but presumably the user would realize that.
Volatile is a performance killer in general, but this is "known". An
alternate, verbose spelling of volatile might be "do everything exactly
as I said, one step at a time, no matter how stupid it might look; trust
me."

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain