You are not logged in.
- Topics: Active | Unanswered
#1 2021-09-21 09:46:20
Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
This is the comments forum stream for
https://blog.synopse.info/?post/2021/09 … ng-Changes
The main breaking change of Delphi 10.4 and later, as reported by mORMot users, is the new lifetime of local variables.
TL&LR: a local variable which is not explicitly declared, but returned by a function may be released as soon as it is not used any more, whereas in the original implementation, it was allocated as a regular local variable, and we could expect its lifetime to remain active up to the end of the function. With Delphi 10.4, it is not the case any more: the compiler could release/clear the local variable sooner, to reduce the allocation pressure.
See also
https://synopse.info/forum/viewtopic.php?id=5709
and
https://synopse.info/forum/viewtopic.php?id=5993
Offline
#2 2021-09-21 13:29:29
- uligerhardt
- Member
- Registered: 2011-03-08
- Posts: 52
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
Read the comments on http://blog.barrkel.com/2010/01/one-lin … elphi.html. So much for that. :-)
Offline
#3 2021-09-21 14:12:33
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
Yes, it seems that Barry Kelly was against such changes to please existing customers.
Marco, on the contrary, pushed for the breaking behavior.
I don't know if it is a personal idea, or coming from some other managers.
At least, it is consistent with other decisions: they are not afraid of breaking existing code.
Stefan just answered in the RSP that instead of using Items[0] the code should use the internal List/PList.
It is a workaround, but not very efficient nor easy to use for sure.
If the previous code worked "by chance", then at least it could have continued to work.
Offline
#4 2021-09-21 16:21:52
- Stefan
- Member
- Registered: 2012-11-23
- Posts: 26
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
You are confusing something - the comment you have in mind was to another JIRA report that claimed a codegen error while in fact the code returned a pointer to a temporary Variant variable.
Also List and PList are not internal but part of the TList<T> public API since a few versions.
What is really terrible about this change is that it created a lot of unnecessary codegen regressions left and right rather than making anything better.
Like this: https://quality.embarcadero.com/browse/RSP-34930 and this: https://quality.embarcadero.com/browse/RSP-31615
Last edited by Stefan (2021-09-21 16:25:09)
Offline
#5 2021-09-21 17:07:06
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
@Stefan
The comment was about the _Safe() function, which is broken because it returns a PDocVariantData pointer to a temporary variant variable, which has always been available until the end of the function body.
So it is not a confusion: the _Safe() bug is clearly involded in the article, because it comes from the change of temp variable lifetime scope, in a very specific usecase.
I didn't know about those RSP.
This is the same origin indeed: the new local scope involve a new temp variable lifetime, therefore a nested try..finally block... which has a cost - as I wrote in my article.
So here performance is not better for sure. Even if it is "version 1", there were other ways of improving performance.
Offline
#6 2021-09-24 06:36:54
- edwinsn
- Member
- Registered: 2010-07-02
- Posts: 1,218
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
Yes, it seems that Barry Kelly was against such changes to please existing customers.
Marco, on the contrary, pushed for the breaking behavior.
I don't know if it is a personal idea, or coming from some other managers.
At least, it is consistent with other decisions: they are not afraid of breaking existing code.
I hate breaking changes! They just want to break the old code and push the users to upgrade to their new IDE.
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
#7 2021-09-24 07:15:15
Re: Delphi 10.4 / Delphi 11 Alexandria Breaking Changes
You are right. They want people to upgrade and give cash. Sometimes, it goes to the opposite direction: why pay to break things?
Most companies would just not pay and switch to another development model, and consider the Delphi apps as legacy.
In practice, everything depend on the developers involved in the project.
If the company has still some skilled Delphi developers, they may be able to make the changes and debugging required, then switch to the new version. Because they already have the skills internally, so it won't cost much. But the managers may see Delphi as a non-viable platform, if they need to pay both developers and Embarcadero just to get compliant with the new IDE version. They are fooled by alternative "free environment" as .Net, Java or JS.
If the company does have less confident developers, they may not be able to easily make the breaking changes, and would stay to an older - and still working - version of Delphi.
This is what we have seen in our mORMot 2 survey: either the users still use very old versions (down to Delphi 7!), sometimes they are stuck to pre-Unicode (Delphi 2007) because the breaking change was too big, or they are using the latest Delphi revision. But in-between versions (like XE#) are likely to be used only for very small one-man companies, where the license cost matters.
Offline