Or is Barry Kelly (Compiler Guy at Embarcadero) just doing some bedtime reading? If he’s not working on this, I hope he’s working on the 64-bit compiler! Actually, I think he’s refactoring c to c++ code!
Jokes aside, I don’t care how many road-maps we get from Embarcadero, or reassurances of the health of Delphi from the powers that be. The one thing that gives me hope for Delphi’s future is having really talented and genuinely clever people working on Delphi. And I don’t really care much for IDE enhancements, but the compiler stuff, that’s where Delphi can make a difference. So it’s good to see Barry’s posts on his blog and on stackoverflow. For the time being, the compiler seems to be in good hands!
Posts
6 comments:
Before you jump to any conclusions.
The reason that Barry posted that article was because I (stupidly) posted a link to an blog post about the .NET GC that was full of rubbish (http://ff.im/-cTcmW). You can read the ensuing twitter updates here:
Mr Kelly berating me for posting poor quality links.
Me apologising for linking to crap.
Me then asking for examples of better articles.
Mr Kelly saying that he might write one himself.
Mr Kelly pointing me to the post a mere 40 minutes later..
Conspiracy solved. Verdict: There is none.
I suspect he is just spitballing over a topic he feels strongly about rather than something he actively working on.
Garbage collection in Delphi is simply never going to happen. It would break FAR too much code.
Every time you see someone stuff an object into an integer (ie: tag) or a typeless pointer (such as TListBox.Objects collection) - there is room for the system to loose track of your pointers.
The fool hardy attempts to use interfaces to simulate garbage collection are about the best we are likely to ever see. I doubt we'll ever see a language feature that formalizes this particular abuse as it would still risk randomly breaking code all over the place.
In order for garbage collection to work, it has to be baked into the very lowest possible levels of the language to prevent the types of pointer abuse that would cause problems in the first place. In fact, pointers perse would have to be removed to accomplish that. Could you imagine how much code would break?
If it were ever implemented, it would have to be optional. You switch it on, or you switch it off. I'm still undecided if it's something I'd want. I guess if it was there, I'd happily use it.
you know that you can use pointers (unsafe code) in C#, don't you?
I'm sure that there are ways to implement garbage collecting without breaking old code.
Garbage collector will solve a zillion bugs in Delphi applications for everyone not using something like EurekaLog.
I would like to see an option to use Garbage Collector (GC) or not in new projects. For example, application wizard could ask me if I want classic application or GC application. That could render into some compiler switch in project file. When compiler finds it, it just errors or make warnings on all things that are not GC compatible. That would probably mean heavy changes inside VCL and other things, but no one said it will be easy...
Here's a good article that should scare Delphi people who wish that Delphi had a garbage collector:
http://blogs.msdn.com/ricom/archive/2003/12/04/41281.aspx
W
Post a Comment