Dalija Prasnikar

I am not following. What function declarations have with records and record pointers we are talking about here? You cannot separate ownership from access. The pointer no longer has the responsibility to release it, but instead of having one problem - one reference that needs to be tracked, managed and released. You now have two you need to pay attention to. Just because you only need to release one, does not mean that you can do just about anything with the other. And if you pass such pointer to the record out of scope, you have just created access violation. Once you free the wrapper object, your record pointer becomes dangling reference. I am not even going to comment about whole wrapping record into object and then working with pointer to that record instead of just using pointer and be done with it... Whether or not you would do all that depends on the context of the code you are dealing with. Wrapping object in a object or an automatically managed object could make sense, but it could also be the opposite. first you need to write such wrapper code and then you need to maintain it. Again, it could make sense in some scenarios where you want to add some additional functionality to a record you cannot otherwise change, but just for allocation it on the heap it doesn't.

Well, in Delphi we commonly use phrases untyped and typed pointers. so when you say raw pointer in Delphi context my immediate association is untyped pointer, especially since your next comparison with C++ unique pointer and shared pointer which are automatically managed was completely unrelated feature to Delphi objects which are not automatically managed. So I assumed that you wanted to say untyped, as I haven't made the connection with the rest and what you are trying to say. I am still not certain what was your original point... as it seems that you were arguing for both style and memory management, otherwise why mentioning unique and shared pointer. I have chosen to disregard the automatic memory management part as this would be adding additional level of complexity and focus on the class part alone. Again, that depends on the rest of the code. In general, if you are dealing with records, then using typed pointer to that record is more consistent and idiomatic than wrapping that record into a class, just to have it allocated on the heap. Especially, since Delphi no longer requires dereferencing typed pointers when working with their content. TRec = record x: Integer; end; PRec = ^TRec; TRecObject = class public r: TRec; end; var p: PRec; begin New(p); try p.x := 5; finally Dispose(p); end; end; var o: TRecObject; begin o := TRecObject.Create; try o.r.x := 5; finally o.Free; end; end If you look at the above code, the using pointer makes code more readable than having wrapped record as you can directly access its content through pointer reference instead of having another level of indirection between.

Typed pointers are quite different from raw pointers. Both class and pointer in make sense, but which one you will chose, pretty much depends on the other code in the context. Declaring a class merely for a single procedure might be an overkill. From the safety perspective typed pointers in Delphi are equally safe or unsafe as classes. You still have to manage their memory and pay attention to what you are doing with them.

VCL implements "garbage collection" for unused device contexts and it periodically releases them. To prevent that you need to call Lock on Canvas, and call Unlock when you no longer need the same device context. But, without seeing your code it is hard to say whether there is more going on.

Another solution that also reduces the binary size is disabling unnecessary Java libraries. By default projects include all kinds of things, like Billing, FireBase, various Google Play services... and if they are not used in the application, they will just be a dead weight.

This is very strange. But the whole issue has been strange from the beginning. AddLog should work both inside or outside task. The only possible explanation would be that AddLog was never called from within the task because some code before it is called triggered exception.

Yes, your code works for me. so the problem must be in some other code you have. Is the AddLog procedure called at all, or just the writing to file does not work? The best thing you can do is to create empty project and test writing to log there.

Saving to log file works fine to me (from the task). The only thing I noticed is that you don't have ErrorData defined within the AddLog procedure. Move it inside, as there is no reason to have broader scope.

Have you tried debugging? Besides the fact that your AddLog code is not exactly thread-safe (if you call it from multiple threads, you can get corrupted log), there is nothing there preventing it to work. And the thread-safety issue would be solved with TThread.Sysnchronize call. So if there is nothing written, your code probably never reaches AddLog call. Make sure that there is no exception raised before that call.

My projects are all rather small, regardless of the platform and the tools I am using. I am personally using Android Studio with Java. Comparing to Delphi, Android Studio is way more resource hungry and slow. Opening a project takes more than a minute, building about 3 (also highly depends on how AS mood at the moment as rebuilding the same project can last up to 10 minutes). Similar Delphi sized project (actually a tad larger) opens up immediately, and builds in under a minute. AS gobbles up over 4 GB of memory while doing that and burns my CPU at 98%. While Delphi uses a little over 600 MB and 8% CPU. Also I had a AS bug report open for years before it was finally fixed, where it would eat up memory on opening second project, and crawl down to a halt and had to be killed through Task Manager. So if I had to switch projects I had to restart the IDE. I am sayin all this so that people wouldn't think that the grass is much greener on the other side and that there are no problems. But the IDE has more features than Delphi and it definitely has some I would want to have. My son is using IntelliJ for Java, and Rider for C# and he is very satisfied with both.

I think it got a bit further... we are somewhere in the Dark Ages...

Only if you have saved the previous steps, too. It is not useful for situations where you have already changed multiple things and then accidentally make a wrong move which you cannot revert.

There is one other feature I like, is ability to change editor font size in pixels. I would like to use Consolas, but size 10 is too small (13 pix) and size 11 is too large (15 pix). I am using 14 pix in other editors. I would post the QP number for that feature request, but it is currently down. But it seems that this would have to wait for new editor because AFAIK the current one can only deal with size in points. One thing they implemented in Delphi 12 is increasing the line height, which is another important feature, when my eyes switch to overly sensitive mode.

I am used to named parameters in Swift (which you have to explicitly write), so once you get used to the fact there there is more information in code, you learn to easily ignore it when you don't need it, but when you do need it is extremely helpful when you are going through code you are not familiar with or your own old code. Yes, you could also hover over the method to see the names and types, but that significantly slows down reading the code. I even find it helpful for the code I know well. I guess my brain likes the extra information being served on a plate.

Inlay parameter hints. It is extremely useful for reading and understanding the code https://www.jetbrains.com/help/idea/inlay-hints.html#change-inlay-hints-appearance Excluding things that Delphi offers but don't work is tough restriction 😉 Well working code completion and refactoring are next.

Anything from JetBrains... I am not saying that Delphi is stuck in the Stone Age... but it is lagging behind in some areas.

DO NOT DELETE THIS FOLDER It contains license information. If there is a reason for removing or editing some license, it should be done through license manager. If it really needs to be deleted, then copy it to some place first, so you can put it back just in case.

It would help if you would provide more information about the exception. The demo works fine for me.

Because conditional jump requires more logic in compiler than simple single jump. Yes, there are other more complicated things in the compiler, that is besides the point. We are talking about goto command which is rarely used and often even considered obsolete. While it has its use cases, extending the goto functionality is really the last thing we need. In that context how complicated feature might be matters. That is why I (erroneously) opened discussion with how many jumps it needs and this could have been a reason why using goto to jump outside try...finally was not implemented.

The jump to finally happens behind that call. If you use Continue, the jump will become more obvious. File a QP report if you think it is important to have it. You can use any code you wish. Like I have already said, I was wrong that there is only single jump involved for the Break and Continue.

You are right, I forgot that there could be code in the loop after the finally, which requires additional jump.

No, it is not the same functionality. Break and Continue will just make single unconditional jump to the finally, while goto would require two jumps, one of them conditional. It is far from being the same.

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.