Dalija Prasnikar

You cannot use TMonitor in such scenario as you don't always have live instance to call upon. Also there is a simpler code than your example commonly used for double checked locking. However, that pattern assumes that calling the constructor is all that is needed to fully initialize the object. Only if there is additional initialization needed after construction, there is a need for temporary object. So this code would look like: function GetMyObject: TMyObject; begin if FMyObject = nil then begin FLock.Enter; try if FMyObject = nil then FMyObject := TMyObject.Create; finally FLock.Leave; end; end; Result := FMyObject; end; or with additional initialization function GetMyObject: TMyObject; var TempMyObject: TMyObject; begin if FMyObject = nil then begin FLock.Enter; try if FMyObject = nil then begin TempMyObject := TMyObject.Create; // additional initialization for TempMyObject FMyObject := TempMyObject; end; finally FLock.Leave; end; end; Result := FMyObject; end;

No, it is not only you. I cannot log in either. AFAIK, the IT has been notified.

Can you please show the minimal working example of your code that you have problem with. It is very hard to follow explanations of the code. We need to see exact code, to be able to help and propose solution.

If Foo is reference counted type, then GetFoo will require hidden reference created to properly initialize reference counting, regardless of how DoSomethingWithFoo is declared. If it is declared as const that only means there will be no additional reference counting involved (_IntfCopy and _IntfClear) calls. Hidden reference is equivalent of the explicitly declared local variable. It is created when there is a need for holding a reference to something for calling _IntfCopy and _IntfClear methods. If there is already a reference (when passing parameter to some procedure where parameter is not declared as const) then there will be no hidden reference because _IntfCopy and _IntfClear can be called on that reference directly. Same principle applies not only for interface , but also for other reference counted types like strings and dynamic arrays, the only difference is in particular reference counting methods that will be called.

If it requires reference counting, then there will be hidden reference created behind the scenes and the actual generated code will be the same in both cases.

Ahh... that is a slightly different case... but, yes, it can be a nightmarish scenario. I had some of my own libraries with messed extensions and it took me a while to realize what is wrong.

Well, 280 is a version 11, and Delphi 12 is 290 so Delphi 12 will definitely not like such bpl.

This work on modernization is the foundation as potential future support for Android and iOS requires more modern toolchain.

There are no implications for Delphi. this is solely C++ Builder issue. AFAIK, C++ Builder side is going through a major upgrade https://docwiki.embarcadero.com/RADStudio/Athens/e/index.php/BCC64X and this work had a priority over supporting iOS and Android (which never had 64-bit compiler required for distribution through Google Play Store)

Delphi 12 supports those platforms. It is probably left over text from version 11, where You needed at least 11.3 to run applications on Android 13. I haven't tested it on iOS, but Delphi 12 definitely supports Android 13, including uploading on Google Play.

CPU is a finite resource. You will not get more of it, by throwing in more threads. If there are more threads than CPU cores, those threads will compete with each other for CPU time, and switching between threads also costs some CPU time. So after you overload the CPU, more threads you add the slower it will work. Only if threads are doing some I/O bound work, then you can have more such threads than CPU cores and possibly whatever you are doing can finish in less time. In other words if the thread spends most of the time waiting for some slow I/O operation, then such thread will not fully utilize CPU core and other threads can do useful work in the meantime on that core. However, even in I/O bound operations, there are limitations and if those threads are competing for the same resources, then again, the whole process will run slower. Imagine that CPU core is a shovel and threads are workers. In CPU bound work workers need to dig some ground. If you have same amount of shovels as workers than each worker will use the shovel all the time without having to give it up and it will be able to do the digging at full speed. If you have more workers than shovels, then workers will compete for that shovel. And it will not be in a way that some workers will use the shovel all the time and others will do nothing, but each worker will get very short time to use the shovel, maybe only taking one or two loads, and then it will have to give the shovel to the other worker that is waiting. But transferring shovel from one worker to another takes time, and at the end everything will run slower than if you have only one worker per shovel. On the other hand, if the worker also needs to use a pickaxe, then while worker is using the pickaxe, he does not need the shovel, and someone else can use it until the worker is done with the pickaxe. This is example of I/O bound work, where pickaxe is some I/O resource (network, disk...). Again, if you have more workers that compete for the pickaxes, the whole thing will work slower than single worker using that pickaxe. Now, this is simplified example. When it comes to your application running, it is not just your application that uses the CPU cores, but OS and other processes and applications are also using them, so you also need to take those into account. Now finding the right balance for the actual work can be hard and will depend on other parameters, and usually you don't have to optimize that much. But in simple terms, you definitely don't want to have more threads working at the same time than CPU cores, if those threads are doing CPU bound work. Commonly using as much threads as CPU cores or one less, will do - you can experiment with that, but again this is something worth pursuing for most applications. If you are writing something that will run on specific hardware then you can more easily optimize, but if you need to make it work across different ones, then good optimization for one may be a bad optimization for another.

The first example is the correct one. The second one is not, as TThread.Queue will run after lStrings instance is being destroyed. Also it is extremely important that you pass nil to the TThread.Queue like you did because passing the current thread instance TThread.Queue(TThread.CurrentThread, would remove queued procedure when the thread has finished running and if that happens before queued code had the chance to run there would be a memory leak. This is less of a problem with tasks, as their threads are reused, although theoretically, such situation can still happen. But if you replace TTask with anonymous or custom thread then such situation is more likely to happen, especially if there are no more code in a thread after calling Queue that could delay its destruction. However, the second example would also work if you would use TThread.Synchronize instead of Queue ad Synchronize is blocking call and Free will be executed only after code inside Synchronize is executed.

Well, that could be a problem if those components are not supported on newer Delphi versions. I don't know because I am not familiar with them. If you do need to replace those components you can make substitute components that will allow loading of the project and will give you if not the same then similar functionality. List all the components you need and find appropriate functional replacement from the Delphi version you plan to upgrade. Then create package your own set of components that will have the same names as TNT components and inherit from appropriate components in new Delphi. Then add all the properties they have that might be different. You will also need to hook up and implement appropriate functionality behind those properties, unless they are functionally unnecessary and you just need to have dummy property to allow loading of a project in new Delphi. This set of components and controls will allow you to open the project in new Delphi version and use those as replacement for TNT components without the need to change form dfm files. It is important to make all those preparations on small test project so that you have everything working properly before you move your actual project. Unicode Delphi also has a WideString, so in theory you could keep using it, but if you are using WideString to interact with TNT components you may need to replace those to generic string type in new Delphi instead of introducing WideString properties to your TNT replacement components.

Like @Remy Lebeau said, start by using UTF8String for strings that hold UTF-8 data. It exists in Delphi 7, too. And doing that will make your transition to Unicode Delphi smoother. You will also be able to more easily verify that you haven't broken anything while doing changes in Delphi 7. This should be your starting point. Another thing you can do is make a short demo application where you will use the most common string handling patterns from your code and then you can transform and move that code to Unicode Delphi. If something goes wrong in that small demo you will be able to more easily understand what you need to do and how.

Don't do that. This is the wrong approach. Just follow the hints from compiler. It will tell you where you need to do something about string conversion. For most of the code you will not need to change anything regarding strings. And if you do blind search and replace you will create more issues in your code than you will solve potential problems.

This kind of behavior would be the best.

This is expected behavior. There is only single address behind inline variable declaration, not multiple ones. Also captured variables are not stored in the stack, but on a heap. Anonymous methods are basically defined as interfaces with a single method - Invoke - implemented by a hidden reference counted class, and captured variables are stored as fields of that class. When an anonymous method is accessed, an instance of that class is constructed behind the scenes, and it is kept alive through reference counting for as long as is required by the anonymous method it wraps. Because you have a loop you will only see the last value in that captured LKey variable because there is only one anonymous method instance created which you are adding to the list again and again with only one captured LKey field.

This is a known issue. Reported as https://quality.embarcadero.com/browse/RSP-40939 The issue is caused by some change on OS level which trashes the FPU. Above report contains a patch containing fpu_init2 procedure which needs to be called after loading from stream. The patch seems to solve the issue in particular scenario for the reporter.

The whole world does it is not much of an argument. Anyway, Android Studio is a Java application and it is rather memory hungry. Just starting it will gobble up 500MB of memory. Opening very small project will raise that to 1.5 GB. Comparing to Delphi which uses 116 when started and about 400MB when you open small project (similar to one in AS). So Delphi with opened project consumes less memory than AS without any. When you build that small project in AS it will go over 3 GB like it is nothing. Of course it only comes in 64-bit variant. macOS OS has been only 64-bit for over a decade. They have been pushing all applications to 64-bit from the very start and since 2019 macOS no longer supports running 32-bit applications. It is wonder they lasted that long as Apple is not much concerned with backward compatibility and the ability that their customers can run something or not. Or whether they will be forced to buy new hardware. Actually everything Apple does is to force people to buy new hardware. Visual Studio got 64-bit version less than 2 years ago. If the MS with all their resources haven't done that before nor though it was absolutely necessary, then certainly there is no reason why Embarcadero would have to jump into 64-bit immediately. I am not going to comment Lazarus, as I don't know to much about it. I seriously doubt MS would do that. Maybe when they switch to 128bit Windows.

Even if this particular piece of code is the same, some other part critical for reproducing the issue might be different. So knowing the Delphi version is always important.

Instantiating TRttiContext at the beginning would not help in this case as the problem is in additional lazy loading. Also not creating global TRttiContext is also affected. Whatever you do it will be broken. However, depending on the Delphi version you are using, creation of global TRttiContext solves some other threading issues. And it is also faster than doing create... try..finally.. free approach. You can patch System.Rtti to fix the issue.

I reported the issue as https://quality.embarcadero.com/browse/RSP-42359

First of all, when asking about particular issue specifying Delphi version is mandatory. System.Rtti is being updated for literally every release (including updates). If you want us to comment on source code we need to make sure that we are looking at the same code. The code in question is perfectly fine. But the whole thing is broken in another place. Namely procedure TRttiInstanceType.ReadPropData; and other similar methods which use boolean for checking, but without double checked locking. This can causes calling LazyLoadAttributes twice which then can corupt the whole thing in that code. For instance I would get a crash on nil Finalizer instance. if FReadPropData then Exit; p := PByte(TypeData.PropData); TMonitor.Enter(Package.FLock); try // Here we would need to check FReadPropData again end exit if it is true classic := ReadClassicProps; ext := ReadExtendedProps; FProps := SubtractClassic(classic, ext); FAttributeGetter := LazyLoadAttributes(p); FIndexedProps := ReadIndexedProps; FReadPropData := True; finally TMonitor.Exit(Package.FLock); end; end;

This is not encoding, this is visual representation. Underlying encoding (numbers) is the same.

There is still a lot of code running in that thread that we haven't seen and don't know how it interacts with other code and might cause memory corruption for various reasons. But the string encoding/decoding code we have seen is not it, no matter how outdated or not.