This a follow up of my previous post Conditional Uses Clause Considered Harmful, showing another real world use case of the technique described there.
Let’s assume we want to use FastMM with Full Debug Mode in a project to track down some errors in DEBUG mode. This requires us to include the FastMM4 unit as the first entry in the uses clause of the project DPR.
Now let’s also assume, we don’t want to use that FastMM unit in the RELEASE configuration – and – NO! – we don’t want to use an IFDEF inside the DPR, as the IDE tends to mess up with such things pretty often.
Using a unit alias like
- FastMM4=System
solves this in a simple and elegant way.
Alternative solution:
In .dpr:
uses
MemoryManager,
…
///
unit MemoryManager;
interface
{$IFDEF UseFastMM}
uses FastMM4;
{$ENDIF}
implementation
end.
And – why oh why would you NOT want to use FastMM in production?
Customer wants it so…
But anyway it is used internally since Delphi 2006, right?
Hint: you can’t just turn FastMM off 🙂
As bad as supporting multiple version of Delphi is – conditionals become even more unavoidable as you go cross platform [and worse if you then have to custom patch FMX].
Let’s be honest tho, the only reason the conditional define is a problem is because the IDE goes insane if you use conditionals in the .dpr and try to add anything to the project. I find if you have a single unit per conditional, it can cope. It’s pain, but livable.
That I find interesting, something which I have just learnt recently.
From my understanding, what the compiler will do, if it sees “FastMM4”, it will replace it “System”. But that would mean “System” is declared twice but the compiler doesn’t care about that…
But if you add “System” in (say, instead of “FastMM4”), the compiler will barf at it.
Yes, that works only with unit aliases. It has ever been so since Winprocs and Wintypes were replaced by Windows.
It doesn’t make sense to test with a memory manager and release with another, even different version of the same like FastMM in any recent Delphi release.
Nor I like “hacks” based on undocumented behaviours, which could make other scratch their heads later when things doesn’t work as expected any longer.
Gabr solutions is much more elegant.
Well, tastes differ. Of course there are other approaches. The whole point was to avoid IFDEFs inside uses clauses.
It is documented behavior, btw. I am just extrapolating the use of this feature.
create an empty unit and put it on top in dpr and you can ifdef any subsequence units as you like
Pham
Looks more or less like the approach Primož suggested. As I already mentioned, the whole point was to avoid IFDEFs inside uses clauses.
To be pedantic – there is no IFDEF _inside_ the uses clause in my approach.
Hehe – OK, but that doesn’t help IDE experts that fiddle around with uses clauses.
C’mon, this is just an example for the technique described. No one claims that this example cannot be solved in other ways.
ISTM the entire thing is to avoid IFDEFs inside the DPR file. They can easily be in units or anywhere else. The IDE simply doesn’t like them in the DPR file.
There is also no IFDEF in inside the DPR in my approach.