Don't be fooled! Delphi has several compilers, so the cross-compilation "magic" may not be so "magic" after all...
Don't be fooled! Delphi has several compilers, so the cross-compilation "magic" may not be so "magic" after all...
http://blog.synopse.info/post/2015/04/20/Delphi-is-not-a-cross-compiler%2C-but-a-set-of-cross-compilers
http://blog.synopse.info/post/2015/04/20/Delphi-is-not-a-cross-compiler%2C-but-a-set-of-cross-compilers
I cannot see a need for IFDEFs between DisposeOf and Free. DisposeOf is calling Free inside when compiled for a non-autorefcount target. So replacing calls to Free with DisposeOf should be sufficient.
ReplyDeleteUwe Raabe and starting with a wrong paradigm on nextgen right from the start? Yeah sure. Regular Nextgen code should not contain DisposeOf like non ARC code contains Free. The entire way of coding is fundamentally different between ARC and non ARC. Having the same code for both worlds is an illusion and leads to "wrong" code for either side.
ReplyDeleteSimon Stuart Agreed, but using IFDEF to target different Delphi versions has been the case since Delphi 2. The article is about cross-compiling and I was referring to the one sentence: "So your code starts to be polluted with $ifdef NEXTGEN blocks, just to call DisposeOf on one target, and Free on another", which definitely is not necessary for at least XE8. Even supporting older Delphi versions can simply be done by introducing an IFDEFed DisposeOf as a wrapper around Free in your own classes. I for myself prefer to target the newest Delphi version whenever possible and write wrapper code for older versions. This makes it much easier to get rid of the support for those older versions when it seems appropriate. Anyway, support for older Delphi versions is almost only needed for component developers. Most of the user code written in Delphi is done for a dedicated version.
ReplyDeleteStefan Glienke I didn't start with that paradigm. It was mentioned in the article itself. I am only saying that those IFDEFs aren't necessary - no more and no less.
ReplyDeleteFree is called by the programmer when (s)he thinks that the object is no longer reachable. It is a source of many errors when the object is destroyed while still having references to it.
ReplyDeleteRemember that in NEXTGEN the destructor is also called when the references to the object reach zero. Use the [Weak] modifier to be sure that you don't create circular references to the object. In well designed applications you rarely have to call DisposeOf.
Christen Blom-Dahl It can be hard to write well designed applications if you have to interact with the UI or anything that uses TComponent descendants. DisposeOf is mandatory for any TComponent descendant http://stackoverflow.com/q/27818697/4267244
ReplyDeleteDalija Prasnikar You've just mentioned one of the rare situations where you can use DisposeOf. By the way, you can also release the components removing references to them: AComponent.Owner.RemoveComponent(AComponent)...
ReplyDeleteYou know that the Front- (MID-) Back-End splitting is perfectly normal for compilers? And that it doesn't have to be all in one Binary?
ReplyDeleteAnd the exact same goes for FreePascal. If you say Delphi is a set of compilers, so is FreePascal.
(Ofcourse Delphi is a set of compilers(levels) but if you try to tell me FPC is a single one, i don't believe so!)
Christen Blom-Dahl I hope you don't use RemoveComponent on non-ARC compilers because it creates nice memory leaks.
ReplyDeleteHow rarely you would have to use DisposeOf depends on the code you write (not necessarily bad designed) and the code you have to interact with.
Point is that different memory management systems in Delphi compilers make things more difficult than they would have to be, code is incompatible with versions before DisposeOf is introduced and it is very hard to say that Delphi compilers are truly cross-platform.
You have to take extra steps to have properly working code on all platforms (even without tackling issues with platform specific APIs)
Dalija Prasnikar I agree with you. From my point of view ARC should be an option and available in all the compiler chains of Delphi. I also think that EMB shouldn't have deprecated non unicode string types in NEXTGEN compilers.
ReplyDeleteA warning would have been a better solution...
Christen Blom-Dahl It would be nice if ARC could be turned on or off with switch, but that is impossible goal.
ReplyDeleteNot because it would be hard to implement such switch in compiler, but because it would be impossible to mix code compiled with ARC compiler with code compiled with non-ARC compiler. You would have same issues like you have today in desktop compilers when you mix object and interface references.
That means that all code would have to come in two flavors one for ARC and one for non-ARC compilers. While end users could decide to have only one, imagine what would that mean for RTL/VCL/FMX as well as 3rd party libraries and frameworks.
Dalija Prasnikar Not true, in xcode you can mix non ARC code with ARC code. In non ARC code the reference counting is updated manually by the programmer (old versions of Objective C worked this way).
ReplyDeleteChristen Blom-Dahl Delphi is not Xcode.
ReplyDeleteThat works in Xcode because in Objective-C all objects are reference counted by design.
When Apple introduced ARC all they had to do is build on top of existing reference counting infrastructure. The only difference between ARC and non-ARC Objective-C is how you "do" reference counting.
In ARC it is done automatically, and in non-ARC you have to call release/retain code yourself.
Dalija Prasnikar In non ARC version of Delphi objects should also be ref counted. Constructor should instantiate them with ref count 1 and Free should decrement ref count by 1 thus destroying the object. Then you can mix your code with ARC version of Delphi.
ReplyDeleteChristen Blom-Dahl I'm having a hard time following your logic here.
ReplyDeleteI spent 1 hour to find a cross-reference in ARC today (the code was OK in non-ARC). I used the fastest NextGEN compiler available (iOS simulator) and it was a hard time. Getting debugger exceptions when trying to step the code with F8/F9, IDE hanging... :) Then I just searched manually in the interface section :)
ReplyDeleteI am not that sure I want to debug a bigger mobile application in Delphi...
We've migrated RemObjects and DataAbstract to the NextGen compilers and I know what I'm talking about. It is a question of practice with the new compilers. See http://talk.remobjects.com/t/delphi-ro-da-for-ios-and-android/5930
ReplyDeleteOndrej Pokorny some time ago I advertised my cross-platform leakcheck (https://bitbucket.org/shadow_cs/delphi-leakcheck/overview) library. Since then I improved it a little bit so it can not only give the list of leaks but can also output graph of the object structure that will give you an idea how the leak occurs. It can detect hidden leaks like ones created by anonymous functions...
ReplyDeleteChristen Blom-Dahl For the moment I don't see any obvious cases where your reference counting proposal for all objects (Create/Free), and I don't have time to dig deeper. But there is one problem this approach would still have issues with TComponent model and code using TComponent descendants would have to have ARC turned off.
ReplyDeleteI think that such thing would only make thing even more confusing and error prone.
Christen Blom-Dahl How much TComponent descendants are there in DataAbstract code?
ReplyDeleteSome code can be moved easier than other. I have code that just works on ARC, without any intervention and I have code that does not.
Dalija Prasnikar Lots of TComponent descendants in DataAbstract and RemObjects. When you adapt a desktop app to a mobile platform code migration is just one task. From my experience the biggest challenge is usually on the user interface.
ReplyDeleteDelphi helps you a lot allowing you to reuse a great deal of code and helping to design the interface in a consistent way for the different platforms.
Christen Blom-Dahl I have migrated only some parts, just for fun and to get experience with possible ARC issues.
ReplyDeleteBut in my case lack of 8-bit strings was first showstopper (there were some more) for any more serious considerations of using Delphi for mobile development.
Dalija Prasnikar With unicode versions of Delphi you should use TEncoding instead of AnsiStrings. When you have to link external code that uses AnsiStrings you should use MarshaledAString. Take a look to this article: http://ridingdelphi.blogspot.com/ (section 2.10).
ReplyDeleteChristen Blom-Dahl I have whole library built on top of UTF8String type and that is basic requirement I have - to store and manipulate with data in UTF8 format - changing that to UTF16 would be impossible because of memory usage and, of course time needed to make such useless change.
ReplyDeleteMobile applications that would need to reuse that library are internal ones, so instead of using Android tablets cheaper and faster solution was to use Windows tablets.
For other apps, we had to go with native solutions anyway (Delphi has other issues besides lack of 8-bit strings). So all in all it was no go.
Currently, I am working on cross-platform project where Delphi could fit (even with issues). But frankly, I am not sure that I would be willing to put my head on the line and choose it even if we would get free licenses. Right now I simply cannot predict time necessary to finish the job with Delphi (due to possible issues) as good as I can with other tools.
The only reason I would choose Delphi is because I am quite fond of it, and that argument is not the right one for my boss.
Dalija Prasnikar Take a look to this app our company developed years ago: https://itunes.apple.com/es/app/my-center./id641972971?mt=8. It was built with Delphi XE2 and since then evolved to XE7.
ReplyDeleteThis app reuses a lot of code we've developed for our optical ERP.
It also uses OpenCV for computer vision algorithms.
We developed custom styles to get the look and feel we wanted.
What more can I say....
Christen Blom-Dahl Looks nice :)
ReplyDeleteBTW, just because Delphi does not fit in my case (and I am very sorry because of that) I don't assume that it doesn't fit for others.