Микола Петрівський

Second link counts COW as immutable. While in Delphi community we usually treat it as attribute of mutable strings.

Lots of problems can be caused by custom components and experts if they are installed in IDE. They all run in the same address space, so a small bug in third party component can break almost anything. So if you have problems, try to disable third party packages in IDE. Another problem is when people try to edit > 10 Mb pas-files or forms with huge amount of components. In such situations IDE is almost screaming: "Do not violate coding best practices, split it in to multiple pieces".

Different HiDPI compatibility options have been in Windows since Vista. So you definitely should check them. Also Vista and 7 had so called "XP scaling" that have been enabled by default for 125% System scaling: https://www.techrepublic.com/blog/windows-and-office/get-a-better-view-in-windows-7-by-adjusting-dpi-scaling/ When "XP scaling" is active, all apps scale themselves regardless of their manifest, like in Windows 10 with compatibility options enabled.

Yep, current HiDPI handling in VCL is far from perfect, but it has been substantially improved in Rio. I hope, they will continue moving in that direction. As for TFont.PixelsPerInch, I belive, this bug exists for more than 10 years. Fixing it will require massive changes in VCL, that is why it still exist.

This only happens if compatibility options are enabled for bds.exe: https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update But latest Windows 10 releases are able to switch these settings automatically.

This is probably caused by smart linking. In smaller projects you do not use classes, that can call GetProductInfo, that is why they have been eliminated entirely. And once no one references GetProductInfo, it can be eliminated too.

@Rudy Velthuis Nice idea, but does not work well with automatic type inference: var Bob := SmartPtr<TTalking>(TTalking.Create('Bob'));

This looks like a bug report. So it will be better to post it to https://quality.embarcadero.com

Nowadays you can use code like this: procedure TForm1.Button1Click(Sender: TObject); begin ScaleBy(14, 10); end; But make sure, that you do not call this too often, because all sizes of VCL controls are integers. That is why, when you call ScaleBy, some rounding happens, and over time you will get loss of precision.

What type of network do you use in your VM? I have successfully used "NAT Network".

Sorry, I have confused them with strings. But still, record creation will need some time, so SmartPointers will not be free. I hope, we will be able to see some benchmarks on new Linux compiler soon after Rio release.

Personally I am OK with ARC removal, if the main reason is, that it has failed to simplify memory management. If main reason is performance problems, than it is not OK. Instead of making step back, we should make one step forward, and fix another common programming problem: errors related to multithreading. Something like this: every memory buffer (object, record, string, etc.) should have hidden field, that contains information about which thread owns this buffer. By default the thread, that created the buffer, is its owner. Threads are not allowed to read or write buffers owned by another threads, otherwise RTL will raise "Thread synchronization error". There are special synchronization sections, where threads are allowed to access buffers owned by another threads, for example TThread.Synchronize or code between TCriticalSection.Enter/Leave. Possible optimizations: there can be special procedure, that can recursively change owner of the object and all its fields. Optimization number two: on 64-bit platforms, different threads can use different memory regions, so information about owner thread will be encrypted in the pointer to buffer. Optimization number three: inside synchronization section RTL automatically makes local copy of the string, if it is owned by another thread. If something like that will be implemented, than there will be no need to protect reference counters with things like InterlockedIncrement, that impact performance so badly.

It would be nice to have ARC-ON for FMX, and ARC-OFF for VCL. But that means two different runtimes with all the costs. Records still have reference counting like objects with ARC. So broad use of such SmartPointers will impact performance even more than ARC, because you will need additional memory allocations and so on.