Leaderboard

Why don't we have a bunch of cool visualizers in the IDE when it's pretty easy to make? (let's see how video embedding works, youtube had a very bad video quality) In the video there is a TStringList Visualizer I put together. Visualizer.mp4

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe. It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state. I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. Doc is here https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

You must love the Windows Update policy in Windows 10.

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current. Of course, that does not necessarily apply for everyone, and I can understand the cost perspective for a one-man shop - but for a corporate developer that is continuously developing internal systems, it is a no-brainer to stay current. You get the fixes, you get the support, and since we do relatively frequent releases, we do the testing anyway. Rio -> 10.4 will mean a lot of work on the FMX side - but on the bright side - you can finally stop having to think about two memory models when you write code for cross-platform. That dual model has actually been a roadblock for cross-platform for us. We did not want to spend time on that duality.

It costs me time and money to upgrade and for now I'm missing nothing by sticking to XE7. But that's just me. Different users will have different drivers. Nobody can made a blanket statement like

Why it took him so long? These versions are very similar. I could understand complexity of D7=>D2009 migration due to Unicode; x32=>x64 is even easier in most cases. But 10.2=>10.3?

It's a hack (there is no OTA access to the debugger in Delphi 2005 to 2007): The plugin reads the output memo from the dialog and then tries to convert it. It then directly writes the result to the memo. That has some drawbacks of course: long text is truncated so the conversion won't be complete. Float strings do not have the full precision, so converting them to TDateTime is also restricted in the precision, mostly on the time part. Yes, I decided that apparently nobody is interested, so I simply kept it to myself. If anybody wants it, I'll make the source code available (if I can still find it).

Actually it's much easier to get money from management for an update whenever it is being released than skipping a few versions and then argue that a particular release is so important that you must buy it. It's even easier with a subscription because then you don't have to argue at all, once you got the subscription. This gets worse with company size. Of course that particular reason might not be valid for you or your company.

By keeping current, you will deal with changes, one version at a time. After the D5->XE2 experience, I very much prefer that option. @Fr0sT.Brutal mentioned 64-bit. We didn't even go there yet, as the 64-bit debugger is utter and completely crap.

The worst breaking changes were Ansi -> Unicode. Migrating a million line D5 project to XE2 was something that I would prefer not to attempt again. Since then, there are been mostly type or constant renames, which are trivial in comparison. Other challenges have been the deprecation of BDE and dbExpress. Fortunately, FireDAC turned out quite well. I agree that the transition between the "named" version has been pretty much trivial, but then again - we usually don't migrate until the first Update pack shows up Last night, four of our SQL Servers that still linger on 2008R2 refused to accept schema updates for two specific stored procedures that were using functions only found in 2012 and upwards. The rest of our servers are 2012 and 2016/17. That is a similar risk to your components no longer getting updates for your Delphi version since the component author drew a line in the sand and started using language features or classes that only exist in the newer Delphi versions.

What breaking changes are those? At one of my clients we upgraded all projects (many millions LOC) directly from Delphi XE & XE2 (for 64-bit) to Delphi 10.2 with no significant effort. The worst part was the tasks you'll have to do anyway every time you migrate a project from one version of Delphi to another. If they had kept up to date all the way through, they would have had to pay maintenance on 20+ licenses to get the occasional new feature they didn't really need and they would have had to fix and work around all the new bugs they got as well.

That may depend on the actual case. The Windows scaling is fine as long as you have images that look ok when enlarged significantly. Usually you have not. Also CAD like applications are not so good candidates.

I have installs with Delphi 10.3.3 on Windows XP, some problems with vcl themes (datatime picker don't work), so I don't use it with that SO, but it works.

When given the option to upgrade: Upgrade. Every single version. The individual steps between versions are not that big. We will most likely not be facing a brute like the Unicode disaster (in my eyes) like back in the day. @David Schwartz: I seriously have to wonder, what needs to be done between Tokyo and Rio. In my (albeit not very broad) experience there should be nothing to do at all, except when using FMX, but then FMX forces to update anyway. Sherlock

Done

You might be forced to reconsider this statement when your customers are more and more using high dpi configurations and criticize the visual quality of your application. While the IDE ist still not ready for prime time in 10.3.3, most of the applications can be tweaked to behave well in these situations. The upcoming 10.4 may be right better with that. Laying out this transition now may give you some advantage when demands are rising and management expects a quick fix (No, problem. You can have your Delphi update, but we have to deliver next week!).

Imagine if the Delphi debugger was able to evaluate expressions without generating memory leaks in the debugger?

my predecessor spent a while preparing to migrate from Tokyo to Rio, but left before it was finished. I've been asked how long it will take to finish. My reply was, "I don't see why it's necessary." The only reason they can come up with is, "Because [predecessor] believed it was important and he spent a lot of time preparing for it." I'm not able to find any particular benefit of upgrading since nothing new in Rio gives us anything we need. We're not about to refactor gobs of code just to take advantage of some new syntactical geegaws.

I got similar results for loading (6.25ms) and finding (9.06ms) in a ternary search tree. And the StringHash(65536) load time for my list on my machine was 9.4ms. Looking at the StringHash source, the memory usage of both that and TST is the same order of magnitude, but the StringHash makes much more use of strings, of course. The TST meets my needs, and I have no plans to switch, mainly because my function builds in more load helpers and matching features, which fit with how I use it.

Have you received UPS/DHL packages recently ? Make a test, how important the signature nowadays is ... I could even make 3 crosses, and nobody complains.

Data please or I call that fake news