David Heffernan

@emailx45 Perhaps there's a language barrier, but in this topic we are talking about the efficiency of the code generated by the compiler. Because for me there has been nothing added since XE7 that would bring enough benefit to justify the time cost of migrating.

No. Whilst for some applications, performance is not important, there are many many fields where we desperately want computers to do their work faster. And better compilers would make a huge difference. As Delphi users were are handicapped by our compiler being much worse than compilers for almost all other languages.

Imagine if somebody could invent such a compiler. Er, no, wait, ...

You OK hun?

delphi - ibtogo64.dll not found in the path - Stack Overflow

What do you think the article linked in the original post says?

Probably another bad idea in this topic which seems to be collecting a huge number of bad ideas. Do this for do different unrelated functions, and now you can pass the consts intended for function1 to function2, and vice versa.

This is of course the holy grail, available in many other languages.

Why aren't you debugging? That's what I would do if faced with this problem.

You've had my suggestion. Use a boolean and give your function a good name. Where you can't do that, use an enumerated type. You seem to be looking for problems where none exist. These kind of problems don't need to be fixed!

A truly shockingly bad one at that!

Should have been titled "In Which I Argue that Embarcadero Should Write Their Unit Tests".

Then you'll need to do some debugging. Only you can do that.

Use the debugger to trace through. Also look in the revision control system to see what has changed.

You really think that an enumerated by, with a meaningful name, carries more information than: FindFiles('c:\', True); I think you are in a large minority if that is your view.

That's not what I am saying. I'm saying that if an attacker gets as far as running code on your machine, then things like reading another process's memory are moot. Once the attacker is executing their code on your system, it's over.

If you've managed to be able to execute code on the target's machine, it's already game over. Bulleting passwords is only ever intended to stop over the shoulder password theft. See point 1. No matter since points 1 and 2 are invalid.

In this case the lock is needless (with interlocked reference counting). The interesting case has to be where G is modified. But the reference counting is interlocked, and I'm sure it's there for a reason, and I'm sure that I've forgotten what that reason is.

In this case, you don't need interlocked operations on the ref count.

Stepping back here, are piecemeal comments from numerous different authors in a forum the best way to design the security for your software? I'd want to be reading a book written with a train of thought. Covering a variety of issues, with explanation of why they matter. And a book that has been well reviewed. It seems to me that standalone tips are the kind of thing that lead to insecure software. Security is an end to end, entire process thing, where the interactions matter. Using a couple parts of best practise doesn't make your software secure. It only needs one part to be missing.

If I were you, I think I'd probably want to know what type of phones these actually were.

Why do you need a phone? Wouldn't it be easier to do it without the phone?

Question is actually about identifying which piece of code is responsible for the lock. Asker already knows which process has it.

Well then they aren't what you say they are.

@avk I am sceptical of your numbers. How can the other algorithms match TimSort for sorted and reverse data?