Jump to content

Dalija Prasnikar

Members
  • Content Count

    288
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by Dalija Prasnikar

  1. https://dalijap.blogspot.com/2020/03/unified-memory-management-coming-with.html Yes, 10.4 will have unified memory management on all platforms.
  2. I have created GitHub repository with code examples from my book Delphi Memory Management for Classic and ARC Compilers. It is still work in progress (there is plenty of code) and currently, it contains examples from Part 1 and Part 5. The rest is coming... https://github.com/dalijap/code-delphi-mm
  3. Dalija Prasnikar

    Rx10.4 new feature blogs

    This is not official advice... I would try contacting sales, or support https://www.embarcadero.com/support or some of Embarcadero Product Managers like @Marco Cantu
  4. Dalija Prasnikar

    Rx10.4 new feature blogs

    It is important to note that anyone with active update subscription can participate in Beta https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription
  5. Dalija Prasnikar

    Rx10.4 new feature blogs

    You are right about permission part. "Sorry, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul" is still valid for everything else.
  6. Dalija Prasnikar

    language updates in 10.4?

    I cannot say I had such encounters. In every place I tried to use them, main problem was killing code completion and navigation (or maintaining backward compatibility) I also used them (actually, type inference that comes along) in some places where my old library code was no longer compilable in Rio - mostly around changes in generic lists and Items.
  7. Dalija Prasnikar

    language updates in 10.4?

    There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation. They would also break Error Insight, but that thing is all kinds of broken, so having one more way to break it is not critical. Besides, Error Insight itself is not critical feature. On the other hand, one permanent pitfall lies in inline variables combined with type inference and reference counted classes as explained in my blog post https://dalijap.blogspot.com/2019/03/inline-variables-type-inference-and.html
  8. Dalija Prasnikar

    How much market share do the iOS32 platforms still have ?

    There is complete list of iOS devices at https://en.wikipedia.org/wiki/List_of_iOS_devices iPhone 5 and iPhone 5C are 32bit, while iPhone 5S is 64bit. Anything having 6 in name is 64bit, Just check whish OS version is the latest version particular device supports. iOS11 and newer only support 64bit devices. Official numbers can be found on https://developer.apple.com/support/app-store/ but they only show stats for devices released in last four years. As far as whether you need to support 32bit applications or not, that is hard to say... depends on your audience (kids can still play games on ancient iPads and don't care about how old that thing is). But most likely 32bit can be safely ignored.
  9. Dalija Prasnikar

    The interfaces in Delphi are bad?

    There is nothing compiler can do here. Compiler does not have intrinsic knowledge how particular class implements reference counting and therefore cannot emit warnings in proper places because it does not know whether particular piece of code is correct or not.
  10. Dalija Prasnikar

    The interfaces in Delphi are bad?

    Full ARC compiler on all platforms and getting rid of TComponent ownership model would be the only proper solution. But that would definitely not make everyone happy. Maybe additional "interfaces" as abstraction that is not tied with memory management could solve most of the issues, but I never given that too much thought in terms of finding potential gotchas and additional levels of complexity such feature might add.
  11. Dalija Prasnikar

    The interfaces in Delphi are bad?

    No,, but learning takes time. I am not talking here about lazy people that don't want to learn, I am talking about efficiency of learning a language that has additional levels of complexity comparing to learning language that doesn't and where both languages are generally suitable for solving some problem. I know that knowledge accumulates over time, so you will not have to relearn things you know the next time around, but such things do have overall impact on productivity.
  12. Dalija Prasnikar

    The interfaces in Delphi are bad?

    Yes, it is an issue. Even if you ignore "just don't do it" part which you first have to know exists and then have to learn how to do properly in Delphi (not so easy as in Java, C# or other languages where you can use interfaces easily), main problem is that you cannot just have some IFoo interface and implement it on every class you like and use it equally. As long as all implementing classes handle ARC the same way, it is fine, but try having IFoo on TInterfacedObject descendant and TComponent descendant and you are basically screwed (or at least seriously limited in what you can do with such classes).
  13. Dalija Prasnikar

    The interfaces in Delphi are bad?

    Which is exactly one of the issues mentioned in article. Interface should be an abstraction that is always handled the same way, but implementation details of the particular class will leak and in some cases you will need to know how implementing class handles memory management. And then whole abstraction castle will just collapse.
  14. Dalija Prasnikar

    The interfaces in Delphi are bad?

    Yes, interfaces in Delphi are troublesome. From perspective of being tool for achieving abstractions they are commonly more trouble then they are worth. Chad explains some issues well. If they are used as COM interoperability, then there is nothing wrong with the because that was exactly their original purpose. If you are looking on them as tool that can give you automatic memory management they are great, because you can more easily solve some otherwise complex problems that would require complex solutions. However, their use in such cases is limited and you cannot use them for such purpose everywhere. For instance you cannot add ARC to visual frameworks that are build on top of TComponent ownership model and automatically handle lifetime of your visual controls. Main problem with interfaces is not that they are badly done per-se, but that they add duality to Delphi memory management and as such additional complexity and care is needed when you are using them. That is one of the reasons why I liked mobile ARC compiler. It showed that without that duality interfaces and objects can live happily ever after and that you don't have to look around your shoulder every time you use interfaces, expecting that they will kick you in behind. Of course, full ARC brought other issues, but those were related to using existing frameworks that were not written with ARC in mind, so we got that dreadful DisposeOf... No matter how you look at it, Delphi memory management is complex, sometimes too much... it is not question of being able to learn about things, but about how easy and how fast can you write your code, focusing on task at hand without needing to fiddle with all nuisances of handling your objects lifetime.
  15. Dalija Prasnikar

    freeing an object in different process

    No caveats for above code. You can freely Free object instance from different thread than one where it is created. Problem would arise if you would have object instance that is being simultaneously accessed by multiple threads.
  16. I assume you meant "FMX will improve faster without ARC. " But, no, FMX improvements (as in framework improvements) are in no way related to memory management model. The only difference between FMX and VCL code related to memory management is that FMX calls DisposeOf to release FMX components and VCL calls Free. Bottom line, FMX will just run faster on mobile platforms without ARC, but that is it. Other improvements will come (or not) unrelated to the memory management mode change.
  17. While anything is possible, I don't think there is too much ARC only code around. For anything TComponent based ARC was never working in the first place (you had to use DisposeOf) so most of UI code should work as-is. Since manual memory management is what people are used to, migration path should be relatively easy, although it may be harder to find exact places where object needs releasing. I would follow constructors .Create - usually destruction is somewhere nearby - either in Destroy, or in the same method. Also, on mobile small leaks are not that critical, usually applications are killed anyway before such leaks cause substantial problems, and larger leaks are easily found just by looking at code. With Instruments and Android Studio you can easily spot problematic parts of application with large leaks. Not ideal situation... but what is done is done.
  18. Dalija Prasnikar

    Delphi 10.3.3 has been released

    https://www.embarcadero.com/products/rad-studio/whats-new-in-10-3-rio https://dalijap.blogspot.com/2019/11/rio-1033-update.html
  19. Dalija Prasnikar

    Community Edition License keeps failing

    Have you reported the issue to Quality Portal? https://quality.embarcadero.com/ I am not sure if community edition is eligible for free installation support https://www.embarcadero.com/support If IDE plugins are problematic, maybe it would be best that you avoid installing non essential plugins.
  20. var Strings: TStringList; begin Strings := TStringList.Create; try Strings.LoadFromFile('C:\SomehugeFile.txt'); finally Strings.Free; end; end; Above is trivial example that can easily cause OOM error and it is also simple to handle and fully recoverable. You can easily wrap the whole thing with try...except block, show message to the user and application can merrily go on like nothing happened. We disagree then. Maybe my imagination is at fault, but I have really hard time imagining how would solution with non-throwing constructors be simpler to handle and make code less complex and convoluted.
  21. Every instance construction can fail because of out of memory error. But there is nothing special in surviving such exception. It only depends what you are doing at that time. Whether it will be recoverable error or not depends on the developer. Also throwing exceptions during construction is not a trap... Delphi has mechanisms in place that allow full cleanup and recovery. That is all that matters. If we didn't have exception throwing construction, we would still have to deal with all kind of "exceptional" situations where you would have to be prepared for handling them. And it would not be any simpler than what we have now. Basic problem in this particular case is non trivial ownership transfer, not the exception throwing constructors per-se. Solving ownership transfer solves the problem. Moving construction of dependent class to within owning class eliminates ownership transfer and solves core issue. (Another approach would be using reference counted classes and automatic memory management)
  22. Construction the instance in outer scope is indeed the problem here, but your code still constructs the instance in outer scope. In order to prevent all leaks, instance must be constructed from within the constructor because exception could be raised before constructor chain is called. In such case you still leak TSomeOtherClass instance.
  23. Same way like other approaches (besides interface) by moving construction of TSomeOtherClass instance to TMyClass constructor. Example would depend on DI framework used... I would look at Spring4D... If code is used in places where out of memory is not recoverable error, then ignoring this potential leak is also viable approach in combination with assigning instance at beginning of constructor like @Uwe Raabe suggested
  24. If allocating memory for the object instance fails then destructor is not called. I would probably use try..except block for releasing the object in case of out of memory error. Of course, that works only if constructing TMyClass instance itself is the only thing that can cause out of memory in that process. But I don't really like that whole try...finally block with nil assignment. Cleaner approaches would include DI, interfaces, passing meta class to TMyClass constructor and constructing TSomeOtherClass instance within the constructor, if the construction is too complex then I would use anonymous method instead and use it as factory.
  25. Code is never perfect. You just revisit code months later and some things will inevitably draw attention. Sometimes, improvements are just minor tweaks, sometimes you are like "what was I thinking, this whole thing has to go". Sometimes, you just leave all the horror untouched because you don't have time. It is a never ending story.
×