Conditionally using FastMM avoiding IFDEFs in the DPR

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.


About Uwe Raabe

Addicted to Pascal/Delphi since the late 70's
This entry was posted in Delphi, Programming. Bookmark the permalink.

14 Responses to Conditionally using FastMM avoiding IFDEFs in the DPR

  1. gabr42 says:

    Alternative solution:

    In .dpr:



    unit MemoryManager;


    {$IFDEF UseFastMM}
    uses FastMM4;



    And – why oh why would you NOT want to use FastMM in production?

  2. xepol says:

    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.

  3. Nicholas Ring says:

    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.

    • Uwe Raabe says:

      Yes, that works only with unit aliases. It has ever been so since Winprocs and Wintypes were replaced by Windows.

  4. KM says:

    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.

    • Uwe Raabe says:

      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.

  5. Pham says:

    create an empty unit and put it on top in dpr and you can ifdef any subsequence units as you like

    • Uwe Raabe says:

      Looks more or less like the approach Primož suggested. As I already mentioned, the whole point was to avoid IFDEFs inside uses clauses.

      • gabr42 says:

        To be pedantic – there is no IFDEF _inside_ the uses clause in my approach.

        • Uwe Raabe says:

          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.

Comments are closed.