David Heffernan

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.

Please don't spam the site with duplicate posts. When you do post, please don't use ultra large text.

It's impossible to draw any conclusions from this declaration. This isn't code that executes. It's just the signature of a procedure. Its kinda tedious that you have said over and over that your data is aligned but people keep coming back to say "your data has to be aligned."

The alignment requirement has been stated many times in this topic. It's doesn't need to be repeated.

What is the question here? Is it, "is this operation atomic for aligned data?" Or is it, "what are the rules for determining whether or not data is aligned?"

The documentation explains what a unit is in Delphi

This is something that crops up over and again. Always get third party libraries from their main repos, and make sure you are up to date.