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.

 

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

14 thoughts on “Conditionally using FastMM avoiding IFDEFs in the DPR”

  1. 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?

      1. But anyway it is used internally since Delphi 2006, right?
        Hint: you can’t just turn FastMM off 🙂

  2. 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. 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.

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

  4. 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.

    1. 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. create an empty unit and put it on top in dpr and you can ifdef any subsequence units as you like
    Pham

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

        1. 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.

        2. 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.