tag:blogger.com,1999:blog-6444609270251748954.post2161298423711560298..comments2024-03-11T23:12:21.225-07:00Comments on Delphi Code Monkey: ARC is awesome: My comments on Allen Bauer 's blogWarrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-6444609270251748954.post-10497281542396853792013-07-03T09:57:23.060-07:002013-07-03T09:57:23.060-07:00"First, there is an assumption that the delph..."First, there is an assumption that the delphi String operation S := S + 'X' is low cost and that a StringBuilder class of the .Net or Java variety is not required. Because the string content S references can be grown easily and with low cost from a dedicated string heap or pool."<br /><br />It's as I expected. That won't change with immutable strings. If the memory manager (it's not he string management that does this) decides to re-size a memory block "in place" then that is an implementation detail. Either way, the LValue S and the RValue S are *different* strings even today. That expression merely takes the existing value of S and the literal 'X', creates a new string which can hold both, then moves the data from S and the literal 'X' into it. The fact that the memory manager *may* re-size S because it knows it's going away is an implementation detail and not because "S" is mutable... that expression isn't actually mutating anything... it's creating a whole *new* string. Only the string data would be immutable... S is a variable and as such can be mutated as expected and be reassigned to another string.<br /><br />"Thirdly, there is a tonne of code already out there that is written with a var S:String declaration that modifies characters inside the string at will. ( S[x] := aChar )."<br /><br />With immutable strings, this is the *only* case that won't be allowed. I understand there is a decent amount of code out there does this, we have code in the RTL that does that too.<br /><br />As for adding an "ImmutableString" type... that kind of goes against the whole goal of reducing the number of disparate string types.<br /><br />Right now, moving to immutable strings isn't set in stone... even now, the compiler will optionally emit a warning (by default on mobile platforms) in the "S[x] := aChar;", but it will continue to operate as before. You an also disable the warning for now as well.<br /><br />90%, eh? Hyperbole much ;-). I can only answer that by saying that if we were to introduce a new internal data structure for strings that made things like concatenation and formatting significantly faster, would that be worth it? What if those data structures helped reduce fragmentation and increase string fragment sharing? So rather than "optimizing" your code by directly assigning each character, you could merely build up the string with simple concatenation and actually minimize the amount memory movement and allocations. It may even be possible to continue to allow mutability and still introduce this change. So, as I've said, immutable strings aren't set in stone.Anonymoushttps://www.blogger.com/profile/10119008505905401707noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-67584769747432481392013-07-03T08:40:00.727-07:002013-07-03T08:40:00.727-07:00I think that deserves a long post.
First, there ...I think that deserves a long post. <br /><br />First, there is an assumption that the delphi String operation S := S + 'X' is low cost and that a StringBuilder class of the .Net or Java variety is not required. Because the string content S references can be grown easily and with low cost from a dedicated string heap or pool.<br /><br />Secondly, if an immutable string option is to be added, it should not be as String, it should be as ImmutableString, and users should opt into it. Like "const" declarations in C and C++, they should be explicit and not implicity.<br /><br />Thirdly, there is a tonne of code already out there that is written with a var S:String declaration that modifies characters inside the string at will. ( S[x] := aChar ). <br /><br />In short, Delphi XE4 with the classic Win32 and the Win64 compiler has more compatibility so far, with Delphi 1.0 from 1995 and even with TurboPascal compiler practices from the DOS era, that it can be a major marketing strength of Delphi; Look we don't break your code, ever. Or rather, when we do, it's because we have to. So the question is, do the supposed benefits of immutable strings provide such a HUGE overwhelming advance for Delphi that they are worth breaking backwards compatibility? No, they do not. I guess I'm flipping the question back to you to say "Can you point me to an advantage that we would get by doing this that would outweigh the fact that you will kill adoption of your product by 90% of existing customers, if you do this?"<br /><br />Warrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-10405100089016361162013-07-02T16:09:28.120-07:002013-07-02T16:09:28.120-07:00What do you think you'd lose by going to immut...What do you think you'd lose by going to immutable strings? I'd like to understand what, precisely, is the fear here. When you hear immutable strings, what does that mean to you?<br /><br />I ask this because I suspect there may be some misconceptions regarding what the world would be like with immutable strings.Anonymoushttps://www.blogger.com/profile/10119008505905401707noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-15858680416319700232013-07-02T13:38:03.665-07:002013-07-02T13:38:03.665-07:00Let me clear a few things up here... First of all,...Let me clear a few things up here... First of all, our use of LLVM is not a case of not having people to write our own compiler. I assure you that we still have some very talented and experienced *compiler* people. Secondly, LLVM from our perspective is merely the *backend* to the compiler. The existing front-end which is what really defines the language is identical except for the places that ARC was added for object instances. In fact all the compiler front-end code that handled managed types for strings, interfaces, variants, etc... only required relatively few changes to also support instances.<br /><br />Moving to LLVM allows us to better focus on the language itself. LLVM as a project is moving forward at a blistering pace and being able to leverage that is going to be a huge positive gain for our market and customer base. Not only did that allow us to get to the ARM CPU quickly and with relative ease, it will also allow us to continue to gain in terms of optimizations and other tooling around the LLVM projects.<br /><br />Finally, LLVM does not dictate anything regarding ARC or it's implementation. In fact, Delphi has done ARC in some form or another since Delphi 2... long before LLVM, iOS, or the addition of ARC to ObjectiveC. In that sense, I think we probably have a lot more experience on the ARC front than some other languages and products.Anonymoushttps://www.blogger.com/profile/10119008505905401707noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-73104935146098507942013-07-02T13:06:23.743-07:002013-07-02T13:06:23.743-07:00Variant records are not slated for destruction any...Variant records are not slated for destruction anytime soon... Although you are correct in your assertion about whether or not you can have an instance reference in the variant portion... you cannot, for the same reasons as you cannot have strings, variants, or interfaces.<br /><br />For those that are concerned about interoperability with C/C++ code, that shouldn't really be a problem because it is likely that the C/C++ code in question would not really understand those types anyway, let alone be able to manage those types properly. For C++Builder which does have some understanding and knowledge of those types, the same restrictions are already in place for that side.Anonymoushttps://www.blogger.com/profile/10119008505905401707noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-31455292219538080692013-07-02T12:57:48.779-07:002013-07-02T12:57:48.779-07:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/10119008505905401707noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-75498741113473745602013-07-02T03:50:01.783-07:002013-07-02T03:50:01.783-07:00I've changed my mind on the VariantRecord thin...I've changed my mind on the VariantRecord thing. They are already limited to non-refcounted types in the current compiler, so probably they will stay the way they are. The point that they are needed for C++ interoperability plus the backwards compatibility reason, is probably enough to keep them around. Delphi has huge backward compatibility and that's always been a huge driver in engineering. You can still take most Delphi 1.0 code and compile it with very few changes.Warrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-10257349696200098362013-07-01T14:32:56.517-07:002013-07-01T14:32:56.517-07:00It's difficult to understand why losing featur...It's difficult to understand why losing features (easy management of string of different types, variant records, pointers becoming "deprecated", ecc. ecc.) is seen as an improvement. It looks to me that because Emb has no longer the people to write its own compiler it has to rely on an open source project and thereby is forced to remove some great Delphi features simply because they don't fit the new compiler. Getting ARC at that price is not that great. Sure, you avoid some try...finally Free end; but the price is that Delphi can't be used any longer in many application it worked great till now. I'm not sure it's a gain, it looks a big loss to me.kmorwathhttps://www.blogger.com/profile/09172645304608198662noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-2606514172720265172013-07-01T09:44:41.021-07:002013-07-01T09:44:41.021-07:00Let's! ;)Let's! ;)William Meyerhttps://www.blogger.com/profile/07461907300761131481noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-24570001422427905032013-07-01T08:13:21.414-07:002013-07-01T08:13:21.414-07:00Okay, let's hope I'm wrong about variant r...Okay, let's hope I'm wrong about variant records. :-)<br /><br />WWarrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-55636857330222876502013-07-01T06:19:45.260-07:002013-07-01T06:19:45.260-07:00I won't reopen the can of worms the string arg...I won't reopen the can of worms the string arguments become, but variant records are essential to interfacing to C/C++ which uses and exposes unions. Their removal would remove Delphi as a possible solution to another class of problem.<br /><br />This is something I have dealt with for many years, in 3rd party APIs to adapter cards. NOTE to EMBT: We do not all spend our lives in desktop and DB work. I could address the interface issue with a wrapper DLL, but there are two good objections to that: First, that it introduces another layer of indirection into an already complex project, and second, that it adds a maintenance issue with long term costs, and which will not always be handled by the project developer.<br /><br />I can understand the concerns about maintenance of two compilers, especially in a market which is dwindling. (OK, that's conjectural, but public evidence supports the conjecture, and no counter proof is made public.)<br /><br />In the end, EMBT may simply elect to ship a less general language product. Ironically, I know that Delphi remains a popular choice in broadcast automation, where the hardware interface issue will always need a solution. Toes, meet shotgun.William Meyerhttps://www.blogger.com/profile/07461907300761131481noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-25103857230287842212013-07-01T03:48:02.364-07:002013-07-01T03:48:02.364-07:00I think, first of all Embarcadero should not chang...I think, first of all Embarcadero should not change the way String type is working if they are wanting to keep some customers still and second, they must drop the old compiler for the new one the NEXT release. Not in 8 years. And the passage must be completely easy for the customer. If they won't achieve this, they loose. <br /><br />Just plain clear.<br /><br />Programmers are just waiting to switch. They are not waiting to stay, major breaks on new compiler will make them switch that's all. Embarcadero is not trustable, nor committed to keep customers happy or whatever. They don't give support, they don't fix the past. Microsoft is far better, and all the other development tools are far better than Microsoft in some parts and worse in others, but all of them are far better than Embarcadero's. <br /><br />I did magic things with Delphi, I work with it since 2.0. But the companies that worked on it just damaged everything.Anonymoushttps://www.blogger.com/profile/03253955034597007972noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-60213839436676521242013-06-30T14:43:06.436-07:002013-06-30T14:43:06.436-07:00That would mean a permanent commitment to maintain...That would mean a permanent commitment to maintain TWO compilers. I doubt that is in the cards. Porting VCL to the new ARC compiler would NOT be a big undertaking.<br /><br />VCL small. Compiler big.<br />Warrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-72644851807601878662013-06-30T13:04:33.333-07:002013-06-30T13:04:33.333-07:00I'm not sure that the VCL is going to be porte...I'm not sure that the VCL is going to be ported to ARC. The VCL is quickly becoming a second class citizen in the Delphi world with most of Embarcadero's attention being paid to FireMonkey.Anonymoushttps://www.blogger.com/profile/00656295753993025694noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-85784449417446042392013-06-30T02:24:27.480-07:002013-06-30T02:24:27.480-07:00Great article again! Thanks a lot!
Just as a note:...Great article again! Thanks a lot!<br />Just as a note: My eyes hurt wehn reading this white-on-black text. Am I the only one to feel so?<br />Regards, Klaus<br />Edelklaushttps://www.blogger.com/profile/16094586596449992157noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-13273788142748615482013-06-29T14:34:11.944-07:002013-06-29T14:34:11.944-07:00I think that some developers would be upset if var...I think that some developers would be upset if variant records went away, and I hope that they will keep them, but as they are a bit of a crazy feature, I wouldn't be surprised if they got axed.<br /><br />Warrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-6444609270251748954.post-38654920538469104902013-06-29T14:11:10.113-07:002013-06-29T14:11:10.113-07:00Do you understand how much perfectly working code,...Do you understand how much perfectly working code, especially those dealing with C/C++ data structuire, will break if variant records are removed? Code won't be ported to ARC. Will be ported to C/C++ instead. And not with C++ Builder, believe me.kmorwathhttps://www.blogger.com/profile/09172645304608198662noreply@blogger.com