Jump to content

Dalija Prasnikar

Members
  • Content Count

    288
  • Joined

  • Last visited

  • Days Won

    27

Dalija Prasnikar last won the day on May 20

Dalija Prasnikar had the most liked content!

Community Reputation

341 Excellent

2 Followers

Technical Information

  • Delphi-Version
    Delphi 10.3 Rio

Recent Profile Visitors

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

  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.
×