The ARC vs non-ARC situation adds yet another layer of complexity to creating cross platform code. The Linux compiler uses ARC - while Windows and OSX do not.
The ARC vs non-ARC situation adds yet another layer of complexity to creating cross platform code. The Linux compiler uses ARC - while Windows and OSX do not.
Guess what that does to the Linux support: It falls way down on the viability list for cross platform code for servers and services. Note that I don't mind ARC - I just don't get why they did not move to ARC for all platforms.
They could duplicate the libs, put the old ones into care & maintenance, and introduce
arc.system. *
arc.vcl. *
arc.data. *
and so forth...
The current situation is pretty much ridiculous.
/rant
Edit: Added what I wrote in the EMBT forums.
I do not expect my non-ARC code to behave on ARC. It is after all a very different life cycle management model.
If you expect to be able to take your non-ARC code and move to Linux without changes - you are delusional.
My gripe is that I can't really go cross platform now with the non-ARC Win32/Win64/OSX compilers. There is no way I want to maintain code that have to deal with both ARC and non-ARC life cycle management. I want to be able to have cross platform code - across ALL platfoms - without having to think ARC/Non-ARC.
I believe an ARC compliant FMX/VCL/RTL and ARC compiler on Windows and OSX (in addition to the current non-ARC) would offer the most sensible migration path for those that want cross platform, since there is no chance that the iOS and Android compilers will go non-ARC.
For those that don't want ARC, they have to sacrifice cross platform compatibility, and probably risk a deprecated platform in a few years.
For those that want cross platform compatibility, they may have to sacrifice a bit of performance with the added complexity of ARC.
Note that the current performance problem on Android looks a completely different issue - i.e. not ARC related, since the previous versions also used ARC on that platform.
I've been asking for a win32 ARC compiler with and without zerobased strings for quite a while. As that's the only way to efficiently test and debug that kind of code.
ReplyDeletea non ARC Linux compiler could be less work than your proposal, and will make a lot of people with thousands of non-ARC line of code happy.
ReplyDeletePaul TOTH - Initially, I felt the same. But, ARC modernizes our coding away from micro management and is forward looking. Also - being able to share code from back end to front end (iOS, Android) - is a major plus too.
ReplyDeleteJeroen Wiert Pluimers Zero based strings... Whoever introduced those, should be taken out and introduced to the full Trump Apprentice treatment.
ReplyDeleteThey didn't move to ARC because they are afraid majority of Windows users that don't care about other platforms would vigorously complain...
ReplyDeleteIt is damn if you do damn if you don't situation.
In the long run unifying memory management is the only viable option and since ARC compiler is newer that inevitably means ARC on all platforms.
As long as there are two compilers ARC development experience will be suboptimal. And even when non-ARC compiler gets retired, there will be another breaking change required - refactoring of TComponent notification system.
Lars Fosdal that do not solve the problem of existing code that will never be ported to ARC and will be stuck to Windows plateform.
ReplyDeleteLars Fosdal they already got taken out (;
ReplyDeletePaul TOTH They could still use the non-ARC version of the libs. Migrating non-ARC code to ARC is trivial compared to trying to make the same code reliable under both ARC and non-ARC.
ReplyDeleteDalija Prasnikar For us, it means that Linux is still-born. After having tested for parts of our shared code - battling with the ARC/non-ARC issues just is not time well used. A double coding standard is no standard at all.
ReplyDeleteThis damn argument being held over and over and over has to stop. I wonder for how long Delphi developers want to manually manage their object instances. Are we still in the 90s?
ReplyDeleteIs the current implementation of ARC ideal? Hell no. Why would we ever want to override __ObjAddRef or __ObjRelease? Make them non virtual inline and save a couple percent of performance in some systems (or even cooler let the compiler optimize away useless virtual method calls when it sees that it was not overridden anywhere that would not only benefit this part!). Give us control over capturing things in anonymous methods so we don't end up creating memory leaks without knowing.
Inspired by your well picked pic and based on the situation this came to my mind ;)
ReplyDeleteic.pics.livejournal.com
Stefan Glienke Without ARC, in Delphi, you are not required to manually manage object livetime: you can use TComponent ownership, smart pointers, or auto-release value objects using RTTI - see TSynAutoCreateFields in https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITLE_610
ReplyDeleteEven with ARC, you have to manage object instances, just by taking care of weak references. Even if you don't need to write try...finally aObject.free; end; blocks of code any more doesn't mean that you still don't need to manage object instances.
You are right about anonymous methods weird capture, but with ARC or GC styles, you still can easily create memory or resource leaks - very difficult to catch. I tracked such leaks in C# server code for weeks... :(
A. Bouchez And if you have to maintain for both life time models, you have to do that debugging at least twice.
ReplyDeleteA. Bouchez TComponent ownership is way to heavy for many things. As for TSynAutoCreateFields we have something similar in Spring4D called TManagedObject that can create aggregated objects and initialize fields that are annotated with certain attributes.
ReplyDeleteAnyway even with all those tools it can become quite cumbersome working with manual memory management especially when working with lists and moving and taking objects from one list into another while one of them has set ownsobjects. With ARC just simply the last list containing them causes destruction if the object is not referenced anywhere else. Sure you can implement this reference counting mechanism onto your own lists but then if you pass around the objects you still have to call the refcount code manually.
Juggling with lists and enumerables is so damn easy in C# (sure it does not use ARC but a GC but nevertheless) while in Delphi you often have to waste time with banalities.
Attila Kovacs Ref your image. That is Kjæragbolten. en.wikipedia.org - Kjeragbolten - Wikipedia
ReplyDeleteAs a developer, when caught upon a rock and two hard places, I'd prefer that there wasn't a 984-metre (3,228 ft) drop to debug.
/sub
ReplyDeleteI really hate the one who introduced the zero based strings... It is really counter productive and bug prone !
ReplyDeleteI'm not against ARC and I really agree with Stefan Glienke...
Stefan Glienke We do agree on this, of course. This is why I like arrays of records for storing value objects. They have the reference counting mechanism built-in, and efficient storage.
ReplyDeleteI would love to see interfaces added to standard RTL classes like IDataset, IStrings, IComponent etc. This will help write code that is compatible on ARC/non ARC platforms
ReplyDeleteNobody will "invest" to move huge Delphi code bases to ARC. Is it simple? NO it is NOT. If it was simple, then what's the problem having 2 different code bases, one ARC and the other manual managed? The fact that you are discussing this here, proves what lots of users have been saying for a long time: It is not simple to keep a single complex codebase compiling with and without ARC. The day that Delphi imposes ARC on Win32/Win64 compilers, that day will see lots of companies leaving Delphi for good. Instead of rewriting it for ARC they will rewrite it in C#. That's a fact.
ReplyDeleteYesterday, Jon L. Aasenden (the guy behind SMS), posted on Facebook that the company he works for is dropping 30+ Delphi licenses. Is it because of ARC? Is this because of manual memory management? NO! That's because Delphi built-in XML mapper cannot handle most XML schemas used by governments all around the world. EMBT should focus on the COMPILER (generate better binary code that won't embarrass us in front of JavaScript programmers) and do the basic stuff work as it should!
ReplyDeleteThis is the post: https://www.facebook.com/groups/137012246341854/permalink/1397049440338122/
I wouldn't buy a Win32 ARC compiler, because it might have 10 times lower compile speed compared with current compiler.
ReplyDeleteRalf Stocker No it wouldn't, or rather, not by virtue of ARC in itself - the existing compiler for the iOS simulator isn't 10 times slower than the existing compiler for macOS, which is a like-for-like comparison.
ReplyDeleteAlexandre Machado 'It is not simple to keep a single complex codebase compiling with and without ARC. ' - Exactly, that's why people are asking for an 'all or nothing' ARC option on Windows as well, so they can choose to enjoy one cross platform language mode if they so wish.
'Delphi built-in XML mapper cannot handle most XML schemas used by governments all around the world.' You're contradicting yourself. What's the XML mapper got to do with the compiler? It's not even a library feature - it's exactly the sort of thing a third party could do well with zero Embarcadero support.
Chris Rolliston read again: "they should focus on compiler AND do the basic stuff work as it should". Basic stuff like XML mapper.
ReplyDeleteChris Rolliston "It's not even a library feature - it's exactly the sort of thing a third party could do well with zero Embarcadero support."
ReplyDeleteYou should write to Jon Aasenden employer and explain to them why they shouldn't expect to pay 4K for a tool that can't handle XML (which VS does in a blink of an eye), and they should pay a third party company to do that. Maybe they buy this bla-bla-bla... who knows?
Sub
ReplyDeleteIs there a third party XML mapper is available for Delphi? The built in one chokes on the particular industry standard ones I try to use.
ReplyDelete/sub
ReplyDeleteAlexandre Machado you were trying to argue against the claim that Embarcadero should support ARC on Windows. Doing that is 'basic' in the sense that core ARC functionality is only something they can do however; in contrast, writing a tool to generate XML mappings is 'basic' only in another sense, given the task is something that anyone, in principle, could do.
ReplyDeleteDarian Miller Not that I know of. Writing one is not trivial.
ReplyDeleteAlexandre Machado Main issue with ARC is keeping compatibility with non-ARC compiler. Another issue is lack of Windows ARC compiler that would help in finding bugs customers code as well as potential bugs and issues in ARC compiler and core frameworks.
ReplyDeleteWith single compiler transition to ARC would be much smoother. And I am not saying that it would not require some work.
In the long run having ARC compiler would make basic development easier and faster because no matter what people say or think, managing memory under ARC is way easier than managing it manually.
It is transition that is painful, for one reason or another, not the end goal itself.
Should i post a new topic or can i ask here how should ARC help finding bugs in the code?
ReplyDeleteAttila Kovacs ARC doesn't help you find bugs. It helps you avoid creating bugs. It reduces the need for manual allocation/deallocation and manual referencing/dereferencing.
ReplyDeleteFewer try/finally blocks. It's no silver bullet, but it is another step away from assembler.
Lars Fosdal Thought so. And a very cool description from you thx. Just a last stupid question, is there also a ReportMemoryDidntGoOutOfScopeOnShutdown(), or WhyIsMyAppEatingUpTheWholeMemory()?
ReplyDeleteA copy of what I wrote in a thread on the EMBT forums:
ReplyDeleteI do not expect my non-ARC code to behave on ARC. It is after all a very different life cycle management model.
If you expect to be able to take your non-ARC code and move to Linux without changes - you are delusional.
My gripe is that I can't really go cross platform now with the non-ARC Win32/Win64/OSX compilers. There is no way I want to maintain code that have to deal with both ARC and non-ARC life cycle management. I want to be able to have cross platform code - across ALL platfoms - without having to think ARC/Non-ARC.
I believe an ARC compliant FMX/VCL/RTL and ARC compiler on Windows and OSX (in addition to the current non-ARC) would offer the most sensible migration path for those that want cross platform, since there is no chance that the iOS and Android compilers will go non-ARC.
For those that don't want ARC, they have to sacrifice cross platform compatibility, and probably risk a deprecated platform in a few years.
For those that want cross platform compatibility, they may have to sacrifice a bit of performance with the added complexity of ARC.
Note that the current performance problem on Android looks a completely different issue - i.e. not ARC related, since the previous versions also used ARC on that platform.
I can't continue this conversation without any alcohol ;) I understand, but there is always a but ;)
ReplyDeleteLars Fosdal Fair enough. However, what about 3rd party component vendors. Think about DevExpress or TMS with giant code bases. Let's say you use a DevExpress grid in a Win32 application which you intend to port to ARC. But your neighbor, which also uses DevExpress, thinks that moving to ARC is a waste of time (Personally I think your neighbor is smart! :-) ). What now?
ReplyDeleteAlexandre Machado I see three outcomes.
ReplyDelete1. They keep doing non-ARC, and risk losing customers that want ARC
2. They make two versions - sold separately, perhaps
3. They switch to ARC and put non-ARC into care & maintenance
In many ways similar to any other tech paradigm shift.
Does any compiler engineer capable of bringing arc compiler to windows still work at Idera?
ReplyDeleteWarren Postma It all started with Windows ARC compiler. It already exists. And AFAIK adding full ARC to compiler was rather easy.
ReplyDeleteI am more worried for other compiler features and who will design and implement them.
Warren Postma Enabling ARC in the compiler is just a switch when building the compiler.
ReplyDeleteThat's technically true and it's not what I meant. You would then have to fix the myriad of edge cases, RTL and VCL bugs, and incompatibilities, and be able to support the results in production.
ReplyDeleteWarren Postma not being capable to bring Windows specific RTL parts and VCL to ARC would imply they would not capable of doing that for Linux too.
ReplyDeleteWarren Postma many of the RTL bugs should already be gone because of the other ARC platforms.
ReplyDeleteWhen you add more platforms, the "cubic feet" of volume that you have to cover to keep the product functional grows. There is already delphi 32 bit classic, delphi 64 bit classic (non LLVM) and the various LLVM based compilers, plus the various C++ compilers (LLVM and classic). Adding one more compiler/platform combination, testing and releasing a working product with all that, is probably something that strains the remaining team. I am surprised (happily) that the Tokyo linux platform shipped. And even if I see people using it happily in production, I'll remain skeptical about its long term future as Linux evolves. Right now it supports two linux distros out of about 200 in common use. Great. That's two more than we had last year at this time. I hope this works. I won't be surprised if it fails.
ReplyDeleteWarren Postma - Many of the different Linux versions are derivatives from RH and Ubuntu. I've tested Delphi on CentOS, and others have tested it on Debian. The number of supported versions depends basically on establishing which prerequisites that are needed.
ReplyDeleteI think it is a major mistake to not ship Linux support for Professional.
I think Linux SDKs needs to be user configurable to allow people to try to incorporate currently unsupported platforms.
I think we will need more ARM versions of the compilers, to support more devices (Pi, Arduino, etc)
But - Most of all - I think it is a major mistake to not select one single life cycle management model across platforms and permeate that model throughout the ecosystem.
Yes, transition will be a pain - but we are in pain already.
Lars Fosdal It's not gonna happen. Take painkillers.
ReplyDeleteAttila Kovacs - Painful cure or palliative care until death?
ReplyDelete