一个程序出问题了，我用Delphi附加到远程进程进行调试，下班的时候，我想把本地机器关掉，让远程的程序继续运行。无奈不知怎么脱离开调试的程序。
查看Delphi帮助，明明确确的看到了一条Detach from Program
Choose Run|Detach from Program to tell the debugger that you no longer want to debug a process. It is different from Program Reset in that Reset kills the process you're debugging. Detach from Program effectively ends the debug session on the current process, but it leaves the process running (the debugger no longer controls the process).
但是到菜单里一看，根本就没有Detach from Program这个菜单项嘛，帮助文件睁眼说瞎话？
求助于AQTime看看，结果看到FAQ里这样一条：
Q.: How do I detach from the process that I attached to earlier?
A.: Currently, detaching is not supported. When attaching, AQtime instruments the process's binary code and these changes cannot be undone.
好嘛，What done cannot be undone。
//demo.jsfl
var doc = fl.openDocument("file:///c:/demo.fla");
doc.exportSWF("file:///c:/demo.swf", true);
fl.quit(false);
flash.exe demo.jsfl
procedure NumericExample;
var
Saved8087CW: Word;
begin
Saved8087CW := Default8087CW;
Set8087CW($133f); { Disable all fpu exceptions }
ThirdPartyRoutine;
Set8087CW(Saved8087CW);
end;
It is recommended that you disable all floating-point exceptions when using OpenGL to render 3D graphics. To do this, call Set8087CW(0x133f) in your main form� OnCreate event before calling any OpenGL functions.
This routine allows the programmer to have direct access to the CW. Be aware that using this routine to change the value of the 8087CW will change the behavior of the program� FP calculations. It is the programmer's responsibility to reset it.
The floating-point unit control word controls the precision of floating point calculations, the rounding mode, and whether certain floating-point operations trigger exceptions. See Intel's processor documentation for details.
Tripping floating-point exceptions
Floating-point exceptions are, as you might expect by virtue of the name, rare. The ones that happen most commonly by mistake in my experience are the zero-divide and invalid operation exceptions. Zero divide tends to happen whenever you have an unchecked normalization operation, such as resetting a 2D or 3D vector to unit length — which works fine, until someone hands you a vector of length zero. Another example would be trying to normalize a portion of audio that was totally silent. When the zero-divide exception is masked, the FPU spits out a signed infinity instead, which sometimes works out in the end. For instance, if the expression is of the form |x/y| > n, then the infinity would give you the correct result.
Invalid operation exceptions are more serious and result from operations that don't have a graceful way to degrade, such as 0/0, the square root of -1, etc. These too often result from the lack of bounds checks. For instance, a common way to determine the angle between two vectors is through dot product, since the shortest angle between two vectors is acos(dot(v1 / |v1|, v2 / |v2|)). Unfortunately, the common way of normalizing vectors is to multiply by the reciprocal square root of the squared length (dot(v,v)), which can give you a not-quite-unit-length vector since the squaring operation discards half of the usual precision. This can then lead to taking the arccosine of a number slightly larger than 1. When such an operation occurs and invalid operation exceptions are masked, the FPU spits out a Not a Number (NaN) value and keeps going. You can also trip such an exception by trying to operate on NaNs, especially by loading garbage data that isn't a valid IEEE finite number.
In general, you don't want to be tripping floating-point exceptions, even if they are masked. The reason is that when the FPU hits one, the fast hardware can't handle it and punts to the microcode, which then takes about twenty times longer. This is especially bad with NaNs since any operation with a NaN produces another NaN, causing them to spread throughout your calculations (NaN disease) and slow down everything massively. You can even crash due to NaNs blowing past clamp expressions, since any comparison with a NaN is false and converting one to integer form results in integer indefinite (0x80000000). Despite the erroneous results, though, NaNs can appear sporadically in a large Win32 program without anyone knowing, and may go unnoticed in a code base for years.
Note that although exceptions are really slow and usually indicate mistakes, the results when the exceptions are masked are well-defined. It is possible, and sometimes reasonable, to actually depend on and test for specific results from masked exceptions. So it isn't valid to simply say "don't do that."
#import "c:/windows/system32/wmp.dll" raw_interfaces_only, raw_native_types, no_namespace, named_guids
HINSTANCE hInstRich = ::LoadLibrary(CRichEditCtrl::GetLibraryName());
ATLASSERT(hInstRich != NULL);
::FreeLibrary(hInstRich);
function ReturnLocalStringToPChar: PChar;
TCountState = classprivateXes: TList;FXCount: Integer;publicprocedure AddX(X: XClass);procedure Reset;property XCount: Integer read FXCount;end;TCountState.AddX(X: XClass);beginif not Xes.Has(X) thenbeginXes.Add(X);Inc(XCount);end;end;TCountState.Reset;beginXCount := 0;// However, nothing be done with Xes here.end;
TCountState = classprivateXes: TList;function GetXCount: Integer;publicprocedure AddX(X: XClass);procedure Reset;property XCount: Integer read GetXCount;end;TCountState.AddX(X: XClass);beginif not Xes.Has(X) thenbeginXes.Add(X);end;end;TCountState.GetXCount;beginResult := Xes.Count;end;TCountState.Reset;beginXes.Clear;end;
共 126 个签名，第 22 页/共 21 页
K = 12
AVE = 23.45k=13
average=23.57k=13AVG=23.49出现了互斥问题，修正一下当前k=14,ave=23.60
