|
Bob Kohlndorfer wrote: > ... > *BASIC > Some optimization is performed on the generated code. > This allows user variables to be displayed but not > modified while in debug mode. > > *FULL > Optimization which generates the most efficient code. > Translation time is the longest. User variables may > not be modified but may be displayed, although the > presented values may not be the current values. > > Perhaps if this functionality could be put into production environments it > could prevent anyone from changing variable during debug. It may be > impractical to get your whole production environment done at once but perhaps > if you do have to debug a program it should be recompiled with an > optimization level first. > Bob, this doesn't seem to be something that's enforced by the debugger. I think "may be x" means "may be successfully x". You can change variables in the debugger even with *FULL, but the change may or may not have an effect depending on how the code has been optimized. I think it would make more sense to be optimized normally, and recompile unoptimized for debugging, if there was a risk someone might change variables. But debugging an optimized program is extremely frustrating. "The presented values of variables may not be the current values" - this seems to be the norm. I wouldn't try to debug optimized unless the program only misbehaved when it was optimized.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.