Jump to content

Dalija Prasnikar

  • Content Count

  • Joined

  • Last visited

  • Days Won


Dalija Prasnikar last won the day on October 11

Dalija Prasnikar had the most liked content!

Community Reputation

817 Excellent


About Dalija Prasnikar

Technical Information

  • Delphi-Version
    Delphi 11

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dalija Prasnikar

    debug IOS using instruments Leak detector

    There is no "unified" handling of the TOCLocal instances, because what you need to do depends on how you got the instance. So that part seems fine. destructor TFMXTextRange.Destroy; begin FStart.free; // added by bb FEnd.free; // added by bb inherited; end; As far as TFMXTextRange is concerned there should definitely be calls to Free, niling is redundant. But, those classes are reference counted, so they should have never been stored in object references to begin with FStart: TFMXTextPosition is wrong (and if they would be stored in interface references then Free would not be needed). This is where those changes in TOCInterfacedObject possibly come to play, to prevent issues with reference counting and allowing instances to be stored in object references. But in that case anything stored in interface reference would be broken. So the whole thing is a bit incomprehensible to me right now, because it also depends on how is each instance stored (interface or object reference), whether Free is called or not. The only way to easily see what is going on is through debugging and I cannot do that right now. Bottom line... FStart.Free and FEnd.Free should have some impact on reducing number of leaks, but it is quite possible that there are other leaks due to changes in TOCLocal. If you put breakpoint at FStart := nil you should be able to see whether TFMXTextPosition.Destroy is called. If it is then, niling is fine. If not, try with FStart.Free. If that calls destructor that is first fix you need to do. If you still have leaks, you can try calling FStart.Release before FStart.Free to explicitly release ObjectiveC object behind it. If you get segmentation fault afterwards, then this is wrong. I am sorry that I cannot be of more help.
  2. Dalija Prasnikar

    debug IOS using instruments Leak detector

    Maybe not.... I haven't looked at iOS since Rio was released and I haven't used it with 10.4 when ARC compiler was removed. There are some weird changes in Macapi.ObjectiveC specifically in TOCLocal class declaration which now uses TOCInterfacedObject. But that requires deeper look and I cannot do that right now, plus I don't have my Mac fully setup to work with Delphi. But, maybe it will give you some clues as where to look. It seems like changes are there to prevent reference counting destroying the object, but in that case there is definitely need for calling Free on anything constructed. Unless compiler is doing some magic behind the scenes for those classes.
  3. Dalija Prasnikar

    LSP - Alexandria

    No, there is no flag. Classic code insight has been completely removed in Delphi 11. I don't know the details, but there were some interference issues that could not be resolved otherwise.
  4. Dalija Prasnikar

    Delphi 11 TRestRequest Failure

    Probably related to this issue https://quality.embarcadero.com/browse/RSP-35341
  5. Dalija Prasnikar

    Calling inherited in Destroy

    Not really. It is the most lightweight list class that can be used there as dynamic arrays don't have capacity which prevents excessive memory reallocations when growing array. Question is, whether the whole algorithm could be implemented in a different way, but that is another story (I am not saying that it can be better as I haven't done any analysis)
  6. Dalija Prasnikar

    Calling inherited in Destroy

    Always call inherited in destructor. I would also add always call inherited in constructor, but if you miss to call constructor that does something, you will know soon enough. If you don't call destructor, you may have leaks which can be much harder to detect later on. This is extremely low level optimization and it makes sense only in some code that will be called a lot, but even then think four times before you write it as changes in class declaration - using different ancestor can break such code badly. I have this kind of optimization in 3 places in my code in my smart pointer, weak and lazy reference implementations. Inherited is there, it is just commented out and there is additional comment explaining why it is there. If anything breaks in TObject, I have only one file to change. But even now, while I am writing this I feel extremely uneasy about that code. So don't do write such code, unless you really have good reason, and don't write it even then.
  7. Dalija Prasnikar

    splitting interface + implementation

    The only thing that includes terms "interface" and "implementation" and that CAN be separated in different files are interface declarations and classes that implement those interfaces and implementing classes will again have interface and implementation part in the unit file itself. If it was Nick's book, it could be Coding in Delphi or Dependency Injection in Delphi, but again you will not find anything there about separating interface and implementation parts of the unit because that cannot be done (besides using include files), only how to use interfaces.
  8. Dalija Prasnikar

    Class Instance vs Object Instance

    Don't ever call NewInstance - this s internal method. https://docwiki.embarcadero.com/Libraries/Sydney/en/System.TObject.NewInstance You should call constructor to create (allocate) new object. vRef := TBaseForm(AFormClass.Create(aOwner)); or you can typecast with as operator which will fail at runtime if the AFormClass is not TBaseForm vRef := AFormClass.Create(aOwner) as TBaseForm; When you declare variable var vRef: TBaseForm; This will only automatically allocate pointer (reference) to your future form - if this is local variable it will be allocated on the stack, if it is field it will be allocated as part of object instance. This is automatic and you don't need to manage memory for that pointer, variable itself. Only when you call constructor actual object instance will be created and allocated - if you create form with owner, that owner will be responsible for releasing its memory. If you pass nil for owner, you need to release it yourself. There is no class instance here, only object instances. Class instance is constructed when you declare class variables in class declaration - and they are automatically allocated and deallocated and there is only single one per class. Again you are not using them in your code. Following is example of class variable declaration. Variable Foo is accessible as TBaseForm.Foo or as vRef.Foo but it will be the same shared integer variable. TBaseForm = class(TForm) public class var Foo: Integer; end;
  9. Dalija Prasnikar

    How to manage feature changes during release cycle?

    This can happen even if you don't use any VCS Not the conflict per-se, but changes in common code if projects are not separated can cause problems and other project may no longer work properly or even compile.
  10. Dalija Prasnikar

    How to manage feature changes during release cycle?

    Yes, of course. Point is that merge conflicts are often used as an argument against branches and to a point branches can escalate problem. For instance single developer developing on single branch will not have merge conflicts, but reckless use of branches can cause issues even for single developer, which often leads to the conclusions that branches are inherently bad, not the how they are used.
  11. Dalija Prasnikar

    How to manage feature changes during release cycle?

    Main issue with branches are merge conflicts. They tend to get worse with time because more code is added and there is potentially more conflict. So naturally, if you have short lived branches there is less possibility for conflicts to emerge. Also continuous delivery focuses on making small incremental changes (which is not always possible) so making small features that don't span across too much code (files) tend to be easily mergeable. Having said that, the lifetime alone actually means nothing. Nor the number of branches. First, you can easily shoot yourself in the foot with the branch old just a few hours, if you change some "hard" to merge file - think something like dproj file. On iOS, macOS that would be storyboards - you don't even need multiple developers to make a mess. So for some types of files, you will need to have specific instructions about who and how can change them without causing issues. Next, it is not how long branch lives, but whether you keep it up to date with other development. If you have branch and you merge it after a year, of course there will be trouble, but not because the branch is year old, but because you didn't keep it up. The most important rule is don't merge, rebase and rebase often. Not only that keeps history cleaner, but you will also have less conflicts - most of the time there will be none or they will be simple to resolve. And of course, in larger teams there has to be some coordination between what is done and when. It makes no sense to start some large refactoring in one part of the code few days before another large refactoring in overlapping area of the code is finished. It is better to wait than waste time on merging.
  12. Dalija Prasnikar

    New FMX project dose not launch

    I am not questioning your decision, I am merely explaining why you cannot easily use older Delphi versions for mobile development. No.
  13. Dalija Prasnikar

    New FMX project dose not launch

    I don't know what OS version S21 uses, but 10.2.3 is rather old version. There are API changes in Android every year that can have impact on compatibility. Just changing targetSdkVersion does not generally help, because it is not just about changing the number. When you change that number you are saying that your application supports particular Android OS and its capabilities, while application you are building with old Delphi version will not fully support new OS. This is why for mobile development you need to keep current with latest Delphi as it has added support for newer versions of mobile OS.
  14. Dalija Prasnikar

    Why empty dynamic arrays = NIL?

    I am few dimes short...
  15. Dalija Prasnikar

    Why empty dynamic arrays = NIL?

    True. But that is not the argument for nil string and arrays, on the contrary. I am all for having nullable types built in, together with full language support, but that does not mean I am for changing how strings and arrays work. Nullable types should be wrapper on around those and value types.