David Heffernan

This looks like it should be in the python4delphi area of the site. If you don't want exit to terminate the process then don't call exit(). It's really that simple. For sure you could catch that exception which IIRC is SystemExit. But that doesn't make sense to me. If you don't want to exit, don't exit.

It could but I don't have one and I'd have to add one, which i guess is why I put it there.

FWIW this is my spin lock TSpinLock = class private FLock: Integer; public procedure Acquire; procedure Release; end; procedure TSpinLock.Acquire; begin Assert(AlignedOn32bitBoundary(@FLock)); while AtomicCmpExchange(FLock, 1, 0)<>0 do begin //signal to CPU that we are spinning; see, for example, http://msdn.microsoft.com/en-us/magazine/cc163726.aspx YieldProcessor; end; end; procedure TSpinLock.Release; begin AtomicExchange(FLock, 0); end; It's only useful on x86/x64 because Emba haven't provided an implementation of YieldProcessor for other processors! I suspect that professional spin locks use different yield methods depending on how long they have been spinning.

In reality you want to split them over multiple lines once they are that long so it's rare that it affects you.

Aren't you meant to use the YIELD instruction (if I've remembered it's name right)

What happens in a do nothing Delphi service? Do they stop too? If not then the problem is likely in your service code.

It's explained in the documentation. Which should always be the first port of call when contemplating such an issue. Its here: http://docwiki.embarcadero.com/RADStudio/en/Operator_Overloading_(Delphi) I could highlight the key text for you, but I'm sure you are more than capable of finding it.

Your conclusion in that topic is wrong. You can make huge algorithmic gains but you choose not to. I've no idea why not.

It's passed by value in your procedure. The caller can't see the change. Also, the original concept would be something that would zeroise local vars without them needing to be listed. Your code fails in every possible way to meet the requirements. And indeed any user defined function would fail, because the asker wants to have the compiler do it.

Why would anybody use code that does nothing? You call a procedure passing parameters by value. Then that procedure modifies those parameters. You've basically done this: procedure Foo(Value: Integer); begin Value := 0; end; I don't think it takes a genius to see that this is pointless. Furthermore, were your function able to do what you think it can, it's still useless. Who the heck is going to call a procedure passing a list of variables, to have that procedure set them to zero? You'll just set them to zero at the call site using the assignment operator. You really think people are going to write: prcInitItPlease([lMyVarLocalThiProc, lMyOtherVarLocal]); (which does not and cannot work as noted above) rather than lMyVarLocalThiProc := 0; lMyOtherVarLocal := 0; Honestly, this thread is mind boggling!

This just modifies local copies of the args, not before burning a ton of cycles boxing them in variants.

This is for sure worth doing. But is that what you mean when you talk about a 10% improvement above? Or are you measuring 10% in just a single function? And sorry to hark back to it, but in your StringReplace topic recently you were concentrating on utterly the wrong thing. There was a massive opportunity to optimise that code, and you have chosen not to take it. For reasons that escape me.

@Mike Torrettinni when you talk about a 10% improvement, do you mean in the execution time for one function, or do you mean the overall execution time for the program, or perhaps the user visible task within the program?

It doesn't exist. You'd have to ask Embarcadero. Only they can make it happen.

Because doing so does take time. For sure it won't be noticeable for most functions, but for tiny leaf functions in hotspots, it can be. You realistically are not going to add code manually to every single function you write to do this. The compiler can't do it. Everything else is just noise in this thread.

I can't believe that anybody would use such code in real programs. Wouldn't it just be better to initialise your local variables?

Not going to be an easy way to do what you ask and I doubt it would address the real problem.

It's still not clear. Are you wanting to use the CreateRemoteThread technique, where you allocate memory in the victim process which contains the name of your DLL and then your thread procedure calls LoadLibrary?

Can you describe what injection technique you plan to use, and what you have achieved so far. Also, don't try to work on this with the production DLL. Work with a simple do nothing DLL so that you can test one thing at a time.

Obviously I know this and have read it plenty of times. But it's way short of a formal specification. Just read the topic for properties. What does fieldOrMethod mean? It's not precisely defined anywhere. The entire language documentation is like that. Just a little imprecise.

The entire language is essentially undocumented. There is no formal specification, no documented grammar etc.

It's called the interface contract. It relies on an agreement between callee and caller, rather than hope.

I think @Lars Fosdal had in mind a post or article with a definitive statement that exhaustively covers every form of variable.

Perhaps you'd like to explain how you go about implementing an atomic increment function without using a var parameter. Which seems to be what you are advocating.

Gonna be hard to implement an atomic increment without using a var parameter. Perhaps if people want to talk about the issue of whether certain variables are aligned, then perhaps a new topic would be better.