I'm pretty frustrated. I'm using Delphi 2009 and was very happy about the inclusion of generics in this version of Delphi. Everything worked great at the beginning, but now that I use generics all over the place I run into problem after problem - most of the time some internal errors, where I don't even see where exactly they are caused. I tried restructuring the code multiple times to avoid the problems with generics but always run into new problems further down the line.
Now I decided to remove generics alltogether and use some dynamic casts to specialize my classes. Not very thrilled about it but i just don't see another option. I can't spend my day tracking down Delphi's internal compiler errors...
Is anybody using generics in a large project without running into such problems? Is it my fault perhaps? Or is it just not possible to use them in complex projects?
I hope D2010 fixes all this stuff.
I'm using generics extensively in Delphi 2009, and I can say it's not easy as you are often required to work around an ICE. Even worse, generics even mess up with the linker, i.e. you can't really use them in packages (except for C++Builder packages).
All this trouble seems to be gone in Delphi 2010; I hardly ever saw an ICE due to generics. I need my code to work with both 2009 and 2010 though :(
Generics support in D2009 was really bad at first. Update 3 fixes a lot of things, but not everything, and leaves at least one serious bug in Generics.Collections.pas. In some ways, it actually got worse, since now instead of giving you a syntax error when the compiler chokes on some generic construct, you'll often get an internal compiler error and you don't know what's causing it.
It's been improved quite a bit for 2010. There are still a few generics-related problems in rather obscure cases, but they're generally safe to use as long as you're not using packages or putting generics inside of class helpers or strange things like that.
Bottom line: if you want to use them, upgrade to 2010.
Related
We currently use D2007 but are considering an upgrade to XE2. I can think of two "bigger" issues here - the Unicode step from 2007 to 2009 and the whole platform stuff from XE to XE2 (32/64 bit, VCL/Firemonkey with pointer sizes, unit namespacing and whatnot).
AFAIK we also get D2009, D2010 and XE if we buy XE2, so my idea was to tackle the upgrade in two steps:
First deal with Unicode. I guess the best way to do this is to upgrade to XE: We would have working generics etc. but no additional issues compared to an upgrade 2007->2009.
If step 1 is done and has shown that it works for our customers do XE->XE2.
What do you think? Should we do the whole upgrade in one step instead ? Or two steps but with a different intermediate version?
Edit: I'm aware that XE2 doesn't force us to go cross-platform (FireMonkey probably never will be an option for us). I just want to avoid related issues like "XE2 values of mrAll, mrNoToAll, mrYesToAll and mrClose" while fighting any Unicode related problems. And unit namespacing sounds like quite a hindrance if we were to make our units compatible with both D2007 and XE2 during the transition (or is that a bad idea anyway?).
I would just jump straight to XE2. Just because it supports 64-bit and FireMonkey does not mean you have to use them right away. Just write 32-bit code first and do your Unicode updates as needed, but be mindful of 64-bit when dealing with pointers, memory usage, etc to minimize the need for future migrations when you are ready to tackle 64-bit. Don't even worry about FireMonkey, as that is a completely new framework, so you would be starting from scratch anyway when you make that jump.
I'm pretty new to Delphi and I'm trying to use the DEHL Collections library. (see http://code.google.com/p/delphi-coll/ ) I'm have a little trouble with it from the IDE perspective. It compiles and runs correctly, but Delphi XE shows errors anywhere I use the HashSet library. The biggest grievance is that is prevents me from using code completion.
The first location I get the error is in an object declaration:
uses
SysUtils, Windows, Collections.Base, Collections.Sets, Collections.Lists,
adscnnct, adstable,
uOtherClass;
type
OneClass = class(OtherClass)
private
_bad: THashSet<string>; // THashSet underlined
_good: TList<string>; // No problems
end;
The error states: "Type arguments do not match constraints"
I don't think it's configuration as I can use TList just fine, but here is how I set it up: I've copied the library to Projects/Libs/DeHLCollections/Library and compiled the library to Projects/Libs/bin. I've included the bin directory in my global library path, which got it to compile and run. I have tried adding everything (/libs, /DeHLCollections, /Library) to it as well in hopes of getting the IDE to help me out, but it doesn't seem to be helping.
Anyway to fix this, or do I just have to deal with it?
Using DeHL Collections version 1.1.1.119
Welcome to the troubles with using Generics laden code. DeHL and generics work a lot better in Delphi XE than in any previous Delphi version, but that's not the same as it "not having any problems". The problems I experience are exactly like yours.
My opinion is that DeHL shows every sign of having been written by a master delphi programmer, and that it's a thing of beauty, in some ways. It's also a source of great pain, through no fault of its own.
Delphi contains not one or two, but at least three (maybe four?) separate parsers, including the full compiler parser, and a few IDE-parsers used for things like Error Insight (the errors you see even before you build) and the code completion data parser. Each has different language support limitations with regards to generics. It is possible perhaps that DeHL could be written to avoid parser problems with all the various Delphi parsers. I have not seen a guide ever written that shows the limitations, but I wouldn't be surprised if complex type declarations in the form TSomething<TSomething<ISomethingElse>,TBar<IFoo>> breaks more than a few of those parsers.
If you intend to use Generics very heavily, you may as well turn off Code Completion and Error Insight. You might also want to save often, and be prepared to experience a lot of compiler problems. And don't try to compile generics-heavy code and put it in packages either. I have experienced a lot of URW and AV (internal compiler faults) when I write generics based code. I find that the Delphi compiler team is great at fixing whatever gets reported, but that the Generics are really most stable for me when I restrict myself to using the Generics.Collections that come with Delphi, and not using other generics based code. It seems it is possible to write stuff using the generics features, that the IDE and two-way tools, and code-completion is not yet fully ready to handle. That means, phenomenal cosmic Generic powers come at a cost to the classic RAD IDE productivity features.
That being said, the latest DeHL sources from Subversion work fine for me and build and run with no errors, but the most recent source ZIP of the entire DeHL collection had problems for me.
I expect that over the next few releases of Delphi, whatever issues have been found (and DeHL seems to be a great place to push the boundaries, and that's one of the reasons i'm a big fan of it) will be fixed, and you won't be wondering why heavy-generics break your IDE features, because they'll all be working again.
Should I upgrade from Delphi 2009 to delphi XE?
As I don't use all the technologies, such as mobile, cloud computing, profiling, 64 bit, new database drivers, I don't need to change to the new XE?
What would change my mind?
Does the new Delphi IDE help me to write less code? Is the package management better?
Do you feel that the IDE gives more automation? And is it worth the upgrade?
I use Delphi XE all day every day, and I wouldn't use anything else.
It is the most stable version of the IDE that I have ever used. The compiler has had a huge amount of attention paid to it, and it works, and doesn't have the many internal failures, internal access violations, or other ways that compilers fall down, that every Delphi release since Delphi 2005 has. So the main feature that makes Delphi XE the best version ever is stability. It is even more stable than my old standby - Delphi 7. And delphi 7 is pretty stable, but working all day in Delphi 7, I did experience regular crashes, something that is finally a thing of the past, with Delphi XE. Okay, I've crashed XE's IDE a couple times, but it's rare.
The second reason is that it comes with great tools; A version of final builder, a version of CodeSite, and a version of AQTime are included. CodeSite was new to me with XE, but I love it, and now that I have used it I couldn't live without it. AQTime is an old friend of mine, and the version included with XE does most of the things that the full standalone AQTime will do, that I need it to do. The final builder version included, is also a huge time saver, especially if you have complex builds to do, including several Delphi application compiles, and an installer script to run, and perhaps other steps.
I like the code-formatter. I am not a big fan of Generics, but you can use them now, and they don't kill the compiler. I still prefer simple readable code, to a morass of generics, and I don't like the way that you do constraints with generics using IUnknown-style reference counted interfaces. Not nice, and not fun.
I don't use much of the database, cloud, or multi-tier application development features. I can't report on that aspect, but I do know that there's a lot more in the RAD XE product than any single developer, however intrepid, can probably even discover.
(Ethical Disclosure Footnote; I work for embarcadero. But even if I didn't, I'd still say everything above. Perhaps, I'd state it even more strongly.)
Does the new Delphi IDE help me to
write less code? Is the package
management better? Do you feel that
the IDE gives more automation?
No real changes there I think.
The area with possibly the most noticeable differences is generics. If you use generics at all then you should upgrade. The versions that followed 2009 have far fewer bugs and wrinkles in the implementation of generics.
In addition to what David said, there also is the new RTTI in Delphi XE which might make the upgrade worthwhile.
Besides the generics improvements, there are new features in the IDE. The addition of a code formatter, IDE Insight improvements to help you find things, integration of SVN, the reworking of the configuration manager, custom build tools, form designer changes, and more. There's also a bunch of new stuff in RTTI.
See this page for a list of what's new in XE, and go up a level from there to see a listing of what's changed specifically from 2009 to XE.
I think it's worth it...
Many bug fixes - they have focused alot on closing out issues. You cannot discount this...you'll never get any more fixes in your current version and the time saved by not having to work around just a single bug or two certainly pays for the upgrade cost if your time is valuable.
SVN integration is handy.
"Show In Explorer" from the project manager. (I don't know if it's just me, but I use this alot and it saves me time.)
If you like code formatters, there's a new option to format all sources in the project.
Debugger visualizers are kinda cool
Third Party Tools included: somewhat crippled, but very usable versions of: AQTime, Beyond Compare, CodeSite, IPWorks, Finalbuilder (depending on Pro/Enterprise)
Online help updated quite a bit
Can it help you write less code? Yes, as you can now rely on generics more due to many fixes from 2009, 2010 and XE. There's also some additional live templates added if that's what you are after.
What would change your mind? I'd say the bug fixes, additional Third party tools, and Online Help improvements make it a no-contest upgrade for the Pro edition. If you are going for Enterprise upgrade, and not using dbExpress, or other enterprise features, then it might be a little less convincing of an update depending on your budget.
The Help has been improved a great deal in XE - in 2010 it was a (bad) joke. 'Show in Explorer' is also great, although not enough reason to lay out that much money. Also much better support for REST, JSON etc. And XE just feels very mature and stable - I don't work for Embarcadero, but I use XE every day, as much as possible - unfortunately I am currently working on a project that uses components compiled for Delphi 5 without source code so I can't use XE for everything. There are some VS guys in my shop who think 'Delphi is Dead' and give me some grief - I am proving them wrong with XE...
I am doing some refactoring of my Delphi project. I want to be able to make a change, then see all the places in the project that break due to that change. Similar to how Eclipse lists all the compile errors for a project (in Java).
In Delphi, I can make a change, then recompile my project, but the compiler stops when it finds the first Unit that does not compile. I have to fix that Unit, compile again, which will then show me the next error, etc etc.
I want to be able to see all the compile errors in the project at once. Then I can decide if the change is worth doing or not. For example, if the change will require hand fixing of 50 separate source files, it's not worth doing. But if it only breaks 2 files then that's an easy change to make.
Is there any way to do this in Delphi? Can I tell the compiler to keep going even after finding a Unit that does not compile?
I am using Delphi 2010
Delphi units, as a modularity feature, are conceptually at a similar level to Java jars or .NET assemblies; they compile to individual files. In neither Java nor .NET can you compile dependent modules when you have compile errors in a referenced module.
The reason they are more granular than .NET assemblies etc. owes to their history. They were designed in part around the segmented x86 architecture; the data associated with any one unit could not be any larger than 64KB. Similarly, units served as a natural division between near code and far code. If you're familiar with 16-bit x86, you'll know that pointers to far data required a value for the segment as well as the offset, while near data only needed an offset. Calling near code was also faster than calling far code. Programs were also smaller and less complex back then; the unit was a reasonable granularity of module for an entire subsystem's worth of behaviour. This is much less the case today.
There's no way to do that with the Delphi compiler, but if you're considering making a breaking change to some part of a unit's public interface, you can use the refactoring tools that come with the IDE to find all references to whatever it is you're about to change before you change it, which will give you the information you're looking for.
The Delphi compiler already tries to compile as much as it can.
Unfortunately, very often, an error is critical enough to prevent the compiler to move past the error as it cannot make an assumption as to what the code should be it if were compilable.
Moreover, very often, the errors a compiler can give after the 1st error has been encountered are not reliable and may even disappear after the 1st error has been fixed. (witnessed by all the red squiggly lines appearing and disappearing when you type)
What the compiler does however is to provide all the hints and warnings (which are called errors for some other compilers).
You can use Ctrl-Shift-Enter to see all occurances of the variable, property, method or wahtever is currently under the cursor. With that information you can decide to do your changes or not.
Alas, with the current version this feature doesn't work as reliable as it should.
Has anybody used/converted "Delphi Fundamentals" in Delphi 2009? - http://fundementals.sourceforge.net/
I'm using Dictionaries (cArrays.pas,cDictionaries.pas,cStrings.pas,cTypes.pas) in my project and now i have some troubles on upgrading code.
I'll be highly obliged if anybody can convert the above mentioned units in Delphi 2009. I'm quite new to Delphi, started working with 2007 and 2009 has been released, I just cannot help myself...
Thank you
I use cUtils, cDateTime and cStrings in a project.
After a 30 minute session of searching and replacing like a madman I got them to compile in Delphi 2009, with just a couple of warnings left to fix.
Char>>>>AnsiChar
String>>>>AnsiString
PChar>>>>PAnsiChar
PString>>>>PAnsiString
It passes all of its selftests, and so far things seem to work fine. I've shared it here: http://www.xs4all.nl/~niff/Fundamentals_UtilsD2009.zip
Update
I've added a ported cDataStructs.pas to the zipfile, which contains the dictionary classes. This one still has a lot of compiler warnings that you might want to fix, but the self-tests pass, so you could try and see if it works for you..
There is no official version of Delphi Fundamentals for D2009 (and I think there never will be any).
I think it would be the best option to rewrite the dictionary code using the Delphi-native TDictionary<TKey,TValue> class inside Generics.Collections.pas, or using the delphilhlplib (Collections/DeHL.Collections.Dictionary.pas).