Leaderboard

There is annual developer survey going on on Stack Overflow. Delphi is in the language list, now we need Delphi developers answering the survey and ticking Delphi to show it is relevant. https://meta.stackoverflow.com/questions/407914/take-the-2021-developer-survey

Orly...

We can certainly argue over the term "big" - but performance is either CPU or memory bound - and with hash table items be scattered all over the heap it most certainly will be memory bound. Hash tables are complex beasts and there are many considerations when designing one but usually, you want to avoid blasting your items all over the heap. Interesting read: https://leventov.medium.com/hash-table-tradeoffs-cpu-memory-and-variability-22dc944e6b9a

You are completely right, I should have answered 哦□� That should have helped the devs to find out that there is nothing wrong with their input encoding 🙂

Googled and found this: https://github.com/project-jedi

Another advantage of VMs is that you're able to do remote debugging and test your software on a different version of Windows than the one you're developing under. I can easily compile a Delphi application on my Windows 10 development VM, deploy it to a network share on my Windows 7 VM and debug it on that operating system. Piece of cake. The same goes for Linux. It's even possible to run MacOS under VMWare, though Apple doesn't allow it unless the underlying host is an Apple machine. The latest VMWare version can co-exist with Hyper-V on the same host machine by the way.

I'm really not a fan of installers like this either.. and especially not a fan of code that a bunch of different modes/ifdefs that change it's behaviour. I would imagine that would be a nightmare for support - having to first work out how it was installed (with the correct options) before trying to reproduce issues. Jcl/Jvcl has always been too complicated - there are some real gems in there but I tend to avoid them because if you use one unit it pulls in 50 more - delphi being delphi, not everything is optimised away. Granted it's been many years since I last looked at it.. but just looking at that installer is enough make me avoid it.

Yes, each IDE would use its own default output folders within the VM. Source code is relatively small, so size was not an issue. Besides, I typically used fixed-sized VMs anyway. But no, storing the sources on the host did not affect the VM size. No. For me, being able to compile the same sources in multiple IDEs was important. If I changed something, I didn't want to have to copy the changes to multiple VMs to test it, just change it in one place only and then recompile as needed.

In case anyone else wonder what to specify for the Development Environment, we have to type in "Delphi", "C++ Builder" or "RAD Studio" (RStudio is something else).

I don't want the DCU directory of any 3rd party component/library in my IDE's library path. In my opinion it belongs into the individual project's search path, if that project uses the library. Actually, I prefer to have the source code in the projects path rather than the DCUs.

Drilling into SysUtils shows SAccessDenied which is 'File access denied' so lost of elevation?

There is one unmentioned drawback to VMs. The more you have, the more you need to keep updated and patched. That is the price you pay for flexibility.