David Heffernan

No. Its pointless trying to handle exceptions in destructors. If that happens the process should terminate.

Again, can somebody explain what problem is caused by raising in a constructor. We all seem fine with TFileStream doing this, so all I can see is dogma.

I don't see the point of trying not to raise in a constructor as a design goal. Raise the exception at the point where you know it needs to be raised.

What do you think about TFileStream.Create raising an exception if the file can be opened in the requested mode for whatever reason? I cannot see the problem with this, or indeed any constructor raising. If you are going to admit exceptions in your program at all, you must be resilient to them. Why is it any different to get the exception raised in a constructor than anywhere else.

The advantage of moving that teardown call to the subject's destructor is that you don't need to test Assigned. If it raises an exception then you are still hosed.

In a destructor you do need to test Assigned on members if you call any method other than Free. That said, destructor must not raise exceptions. And its generally better to move the call to those teardown methods into the destructor of the class.

This is pertinent to some of the discussion here: https://stackoverflow.com/a/8550628/505088

I mean if you have a bunch of files that need to transformed once, then writing delphi code isn't the most efficient. You'd just use a scripting language to make the change and throw the code away. But if you have a Delphi product that needs to repeatedly perform this transformation then that's not going to be useful.

If this is a one time transformation then it's easier with a scripting language

This is just going to be the age old issue that most Windows code expects floating point exceptions to be masked, and Delphi's RTL unmasks them. So, mask floating point exceptions when you call into Python, and unmask them when the Python call returns. Or just mask them always if you don't care about floating point exceptions. Of course, the floating point support for changing floating point control state is not thread safe in the Delphi RTL as I have been saying for more than a decade now.

It still doesn't make any sense to me why you wouldn't just use TStopwatch.

No idea why you wouldn't use TStopwatch

I'm sure your function would give the same result. Did you read the earlier posts? They explain what is going on.

Why is that better than StringReplace? How does it relate to the problem in this thread?

Get Martin Fowler's book on refactoring.

Fair enough. Let's just switch to PHP then and be done with it. Bruh.

Nothing there is useful. Hard to get past the basic sin of treating a string as if it were a byte array.

It doesn't much matter what the thing is that you encrypt. What matters is who encrypts it, and who has knowledge of the key or keys used to encrypt and decrypt. That's what I mean by usage. As for how you do it, convert the text to binary using a well defined encoding, e.g. UTF8, and encrypt that. Encryption algorithms work with binary data not text.

It depends on what your usage is

Pro has command line compiler

Answer found in the code which we can't see.

Save the file to a directory where you have write permission

Also, this isn't how to display binary in a hex editor.

Big lesson here is always to show a proper minimal but complete reproduction. It wasn't clear what the problem was from the first post which was descriptive. Code doesn't lie.

Should be #0 rather than '#0'. Your code is replacing the text '#0' which doesn't appear in the string.