Re: compiler bugs

Chris F Clark wrote:


> > Not if the unoptimizing compiler initializes all variables to some
> > known value.
>
> So, if you have an algorithm that needs a trick like the above to meet
> its performance promises, then the unoptimizing compiler breaks your
> algorithm (and we don't have a well-known optimization technique that
> fixes that breakage).


I'm partial to the C# approach myself. The safe subset of the language
is capable, and for the particular case in question, all locals are
zeroed out by the compiler by default, even though the language requires
definite assignment before use. (So the optimizing JIT won't pay
performance-wise here, as it can eliminate the redundant
initialization.)


However, if tricks are required to meet performance goals, there is the
escape valve of unsafe code, wherein one can fall back to C-level
semantics.


> Yes, one can design a language that is safe, but every attempt to do
> so, has restricted the language such that certain short-cuts that may
> be generally unsafe, but can be safe in certain instances, are
> prohibited. The question then is whether those short-cuts are
> required in ones application.


I think the dichotomy apparently in question, to be safe or not to be
safe, is false. If the safe subset is strongly encouraged (and in the
case of C# and .NET etc., often mandated for business reasons when using
e.g. third-party application servers), yet an "out" is possible, is this
not all that is needed?


-- Barry


--
http://barrkel.blogspot.com/

Return to the comp.compilers page.
Search the comp.compilers archives again.