David Heffernan

Title bar panel is effectively VCL styles because theres no api for that, I think. So you probably just have to suck it up.

Late information boo

You should report these as bugs to Embarcadero, but unfortunately they've been unable to provide a mechanism for reporting bugs for last past few months.

I guess ARC per-se wasn't the big problem, it was more the attempt to support ARC compilers and non-ARC compilers with the same codebases??

Yes.

Wrong. Setting a dynamic array to nil is identical to setting length to 0 and identical to passing it to Finalize.

That doesn't help if you have multiple variables that refer to the same instance which I guess is a more likely scenario for double free.

This sounds completely broken. What if the file starts with the sentinel value that indicates that you have a utf8 payload. Why aren't you passing a separate header, and then the payload? And why are you passing utf16 at all. Isn't that just expensive. And if you must pass around utf16 please tell me that you are handling byte order correctly.

What's pretty astonishing is that the NSA thinks that Delphi is memory safe! See White House urges developers to avoid C and C++, use 'memory-safe' programming languages | Tom's Hardware (tomshardware.com) I guess the NSA don't know anything about Delphi. obj := TObject.Create; obj.Free; obj.Free; Take that, NSA!

Just let me know what you can do with C++ that you can't do with Delphi, in terms of safety

No it's not. Not really the point if a government agency will only accept work using tools that meet certain criterion. You can either follow the specification and have a chance of getting the work. Or argue about the specification and be completely ignored. That's just reality.

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code. We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. Yes, my original post was sarcasm.

Delphi produces native code, and therefore is fast

That's not my example. Nobody wants to do this with a value type because it's a non terminating recursion. Have a look at my example code to see what I'm actually talking about.

None of that applies to my example above.

I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

This isn't really a great example. The sort of thing that I want to do with records, but cannot, is this: type A = record; B = record; A = record function foo: B; end; B = record function bar: A; end; I can get round this using helpers right now, but I don't understand why I can't do this directly as above.

If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

Hardly, because you've now ruined your production program.

Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other.

hahahaha

Step 1 to solving the problem is to understabd why you are compiling delphi rtl libraries

I would read the documentation the same way you did

Then you'll have two different instances of the VCL which is why packages exist.

I don't think this is a good idea. Just share the source code between your 5 different programs. Trying to setup inter process communication will complicate things massively, and probably needlessly. It will also be difficult to maintain the feel of this being one integrated app if you have multiple processes.