This week’s just getting started, and it’s already had more than enough awesomeness to pack into a typical month. The new version of Delphi came out yesterday. Metroid: Other M and The Way of Kings, a new Brandon Sanderson book, were both released today. (I have a feeling I’m going to be more distracted than usual for a while…) But as awesome as Metroid games and anything by Sanderson tend to be, (if you’re into fantasy at all, check out Elantris and Mistborn and prepare to be blown away,) this is a programming blog, and I’m supposed to be talking about Delphi. So here’s the good, the bad, and the annoying about my first impressions with Delphi XE.
The first thing I knew about the release was when I received my SA email yesterday afternoon, as opposed to having to wait a few days or even weeks to get my upgrade as has happened in previous years. Big improvement there, and I hope Embarcadero keeps it up for subsequent releases. Good.
No OSX support, which we all thought was going to be in this release up until a few weeks ago. Bad. But it’s not there because the people at Embarcadero preferred to focus on quality and not release something that wasn’t ready. Good. No one wants to see (or pay for) another D8.
So I open it up and start browsing through some code. My settings from D2010 didn’t get migrated forward. Annoying. There really should be some way to import them as part of the installation process.
ErrorInsight is the same old same old, with false positives all over the place because it can’t find basic standard library units. Annoying. But at least it doesn’t choke on methods of objects from a generic list anymore. Good.
Speaking of Generics, huge improvement here. I was able to go through my codebase and remove all the annoying workarounds for generics-related glitches, and it compiles and runs properly now! Good.
When it’s time to debug, I immediately noticed a few improvements. We finally, finally, after all these years, have debug DCPs available for the standard libraries. (For those not familiar with them, DCPs are to Delphi packages as DCUs are to units.) That means that people like me who build stuff with packages are able to trace into the RTL when debugging. Good.
Also, something that always drove me up the wall about the debugger has been fixed. When you put the cursor in an expression and hit CTRL-F7, it pops up the Evaluate/Modify window and evaluates whatever you had the cursor on. But if you moved the cursor and hit CTRL-F7 again without closing the Evaluate/Modify window, it would focus the Evaluate/Modify window, but it wouldn’t evaluate the new expression you had selected. You’d have to close the window and hit CTRL-F7 again to get a new evaluation. (Or copy/paste or type it in, of course.) That always bugged me, but it’s been fixed in XE. Good.
And while we’re on the subject of Evaluate/Modify, you can now select more than whatever the limit used to be (80 characters?) and have your entire selection copied when you hit CTRL-F7. Good.
But while poking around in there, I found a new way to crash the IDE. Try to evaluate a call that will open a form, and it locks up Evaluate/Modify. Then hit CTRL-F2 to kill the debugger, and it brings the whole program down. Bad. (Not sure if this was in earlier versions, though. I’ve never run across it before.)
Oh, there’s a new regular expression library in the RTL. Some people will probably find this a good thing. I personally see it as Annoying. Delphi code is supposed to be easy to read. That’s an explicit design goal going all the way back to Wirth. But PCREs are anything but, and having it right there in the standard library will just encourage people to use them in code that I might end up having to debug some day.
In addition to Generics bugs getting cleaned up, the Generics.Defaults and Generics.Collections units got a bit of polish. There were some minor tweaks to speed up various low-level comparison functions in Generics.Defaults. Over in Generics.Collections, all the collections have gained a ToArray method, TStack<T> and TQueue<T> gained a Capacity, and there’s a new TThreadedQueue<T> class that looks a lot like the Blocking Collection that Primoz Gabrijelcic set up for OmniThreadLibrary, only without all the Omni stuff. These new features look Good.
The Math unit has been given overloads for Single, Double and Extended precision versions of just about all its calculation routines, which is Good because there’s no more implicit conversions to introduce rounding errors. However, I had this bite me when compiling some code at work. Someone was passing an array of integers to Math.Sum, which worked before, but now the compiler gave an ambiguous overload error for that. Annoying, but not too hard to fix, since there’s a SumInt function right after Sum. Not sure why the original author of this code didn’t use it in the first place. Oh well…
In RTTI.pas, there’s a new class called TMethodImplementation. You create it and give it data that describes the signature of a method, then pass it an anonymous method that takes an array of TValues and returns a TValue, and it creates a little thunk of machine code that builds a function with the correct signature that invokes your anonymous method. Very cool, lots of potential… except that you can’t use it. The constructor’s private, and there’s a public constructor that raises an exception, so you can’t get at it via TObject.Create. It’s apparently for internal use only. Annoying. I asked Allen Bauer about this, and he said that it’s because they weren’t sure they had the final form of the class worked out yet, and they didn’t want to make it publicly available yet in a form that they’d end up having to preserve and support forever afterwards.
There’s also a new class called TVirtualMethodInterceptor that is publicly available, and uses TMethodImplementation internally to allow you to replace virtual methods on a class. I’m a bit curious as to what this is useful for, but apparently the team thought it was good for something, because a lot of work went into setting it up. Good?
Oh, and apparently certain aspects of the compiler have slowed down. Most things will compile about the same speed or even a little faster, but for really large projects (millions of lines) with complex interdependencies between units, you’ll notice some slowdown, and it’ll apparently get worse the larger your project is. I timed it at work, on a project of about 3.5 million lines of code. It builds in about 2 minutes on D2010, closer to 3 minutes on XE. Bad, but still a heck of a lot better than the C family could do. And apparently it has something to do with making Generics work right, so I can tolerate that. Hopefully they’ll find some way to regain some of that lost speed in updates, though.
Oh, and there are little {$IFDEF POSIX} and {$IFDEF MACOS} tags scattered throughout the RTL and VCL, even more than there were in Delphi 2010. This is Good if you’re looking forward to OSX or Linux cross-platform development in the next release(s). I haven’t seen any 64-bit ifdefs, but that could be because it doesn’t require much change at the Pascal level, the way a completely different OS platform does. (UPDATE: According to PhiS, there’s a lot of {$IFDEF CPUX64} tags in System.pas. I was poking around the libraries with BeyondCompare last night but I didn’t bother to look in there because I knew that, with all the cross-platform stuff and all the ASM they’ve got in System.pas, the diff view would be a big, confusing mess no matter what.)
Well, it’s getting late and I haven’t had time to dig through too much of the new stuff yet, (and with a new 1000-page novel and a new video game, it might be a while,) but overall this is looking like a pretty good release. Not a huge leap forward like the last two were, but a lot of polish and incremental improvements. I think this is going to be a pretty good release overall.