Big small update Rio 10.3.2

-
RAD Studio update 10.3.2 has just been released, packed with new features and improvements; some big, some small.


Big features

  • Delphi macOS 64-bit
  • C++17 for Windows 64-bit
  • C++ LSP Code Insight Improvements
  • Delphi Linux Client Application Support (recently released for 10.3.1, too)

Smaller features

  • RAD Server Wizards and Deployment Improvements
  • Enhanced Firebase Android Support

Enhancements and Improvements

  • IDE
  • Runtime Library Performance
  • VCL Quality
  • iOS
  • C++17 Quality
  • FireMonkey
  • FireDAC & Database
  • Web Clients
You can find the full list with additional details at http://docwiki.embarcadero.com/RADStudio/Rio/en/10.3_Rio_-_Release_2

For Delphi developers targeting Windows, there are no big features to be thrilled about. But, 10.3.2 brings many smaller fixes and improvements making this update quite worthwhile. If nothing else, a faster IDE alone justifies updating sooner, rather than later.

But don't take my word for it... just go and see for yourself...

Coming up next

For me, personally, the most important 10.3.2 feature is that it is finally released and I can look forward to the next big release, 10.4, coming up really, really soon.

Besides another new compiler - 64bit Android - 10.4's most notable new features, and the ones I am really excited about, are:

Managed Records

A language enhancement for records that will allow us to add custom record initialization and finalization code that will be automatically called. Along with that comes support for custom Assign operator and copy constructors.

This feature opens up a whole new world of possibilities for writing safer, memory efficient and faster code, including simpler implementation of nullable types.

Delphi LSP Server

Delphi LSP (Language Server Protocol) will solve a whole range of IDE issues in one go, like longstanding issues with Error Insight, Code Completion and Code Navigation. The core problem with those is that IDE has its own language parser(s) for those features. That means that every time a new language feature (no matter how small) is added to the compiler, the IDE is blissfully unaware of it, and the abovementioned IDE features either misbehave or completely stop working when they encounter code using the new language enhancements.

In order for the IDE to recognize new language features, IDE parser(s) need to be updated, too. This requires extra work and, more often than not, the IDE lags behind the compiler.

LSP support will make all those IDE parsers redundant and will enable the IDE to directly use the compiler for all IDE features that require parsing code. That means no more discrepancy between the compiler and IDE.

Unified memory management

While I am really looking forward to both managed records and LSP support, unified memory management makes me happy beyond... there are no words to express it...

For years, I have been saying that dual memory management is a huge issue for developers and that unified memory management is the only way to go in the long run.

However, this unification also makes me quite sad... almost as much as it makes me happy. It means that, for the foreseeable future (or forever), Delphi will be stuck with Stone-Age manual memory management. Not only that, but different memory management for objects and interfaces will continue to be an endless source of problems and bugs.

The ARC compiler, despite all its flaws (most of which were fixable), opened up a whole new world for me and I will sorely miss it.

Still, having different memory management on different platforms was the worst possible scenario and I am happy that all that will soon be behind us, including that darn DisposeOf method.

Comments

Post a Comment

Popular posts from this blog

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more

Delphi 12.1 & New Quality Portal Released

-
Image
The Delphi 12.1 update has been released. Besides a number of bug fixes, this release also has a few new features. The most notable ones are the new Split Editor, which allows having multiple files opened side by side; and support for Android API 34. You can find more information about what is new in this update at https://docwiki.embarcadero.com/RADStudio/Athens/en/12_Athens_-_Release_1 However, the greatest change for all Delphi developers is a new bug tracking portal that replaces the old one, still available in read-only mode at https://quality.embarcadero.com/ . The new portal is hosted in Atlassian Cloud https://embt.atlassian.net/servicedesk/customer/portals  or through a redirect https://qp.embarcadero.com and is based on Jira Service Management (JSM), while the internal bug tracking system, which was also migrated to the cloud, was not changed and is running on Jira. This move to the cloud was inevitable, because Atlassian retired their Server line of products. JSM is a
Read more

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more