1

I use Delphi's LeakCheck library https://bitbucket.org/shadow_cs/delphi-leakcheck.

I know I can disable leak reporting using a construct like this:

{$IFDEF DEBUG}
System.ReportMemoryLeaksOnShutdown := true; // this will enable LeakCheck to display a message on Windows
{$ELSE}
System.ReportMemoryLeaksOnShutdown := false;
{$ENDIF}

But I also need the library to NOT collect any data when compiled in RELEASE mode.

I can easily "hack" the LeakCheck.pas initialization/finalization sections like this:

...
{$IFDEF DEBUG} // <--- Code added by me
initialization
  TLeakCheck.Initialize;
finalization
  TLeakCheck.Finalize;
{$ENDIF} // <--- Code added by me
end.

Is there any better way? A conditional define I miss or a global property?

Gad D Lord
  • 6,620
  • 12
  • 60
  • 106

1 Answers1

7

I don't use the specific library (LeakCheck) you mention, but I typically do this by only including the unit when the right configuration is defined (in this case, DEBUG). This means that in release it's not even included in the executable.

uses
  ...,
  {$IFDEF Debug}
  LeakCheck,
  {$ENDIF}
  ...;

As is pointed out in a comment, LeakCheck has to be the first unit listed in the .dpr's uses clause, which may cause an occasional problem with the IDE; it sometimes ends up breaking due to the {$IFDEF}. I usually don't find this to be a major issue, because once it happens and you've seen what the cause is, it's pretty easy to just go back in and fix it.

If that becomes too much of an issue, there is another workaround - create a new unit that does nothing but use LeakCheck and SysUtils, and add the above {$IFDEF} in that unit. You then include the new unit first in your .dpr. As it's only task is actually to use LeakCheck, it still puts LeakCheck in first-compile order in the .dpr when needed, and does not include it at all when not.

Ken White
  • 123,280
  • 14
  • 225
  • 444
  • LeakCheck is special (the way FastMM and MadExcept are). It has to be the first unit in your .dpr project file. Messing with the uses section in .dpr file had always been troublesome when coming to {$IFDEF}. The IDE tends to overwrite your {$IFDEF} clauses from time to time and break the project. – Gad D Lord Mar 28 '15 at 21:23
  • @GadDLord: Sure, sometimes. It's also probably the only solution, short of manually adding/removing the uses clause or substantially altering the LeakCheck unit itself. When the IDE breaks it, it's always easy to fix. – Ken White Mar 28 '15 at 21:33
  • You can use a unit alias to avoid conditionals and so defeat the ide – David Heffernan Mar 28 '15 at 22:24
  • LeakCheck was designed to be easily pluggable into the project, using `IFDEF` in the DPR is how I usually disable/enable it. But you can use `LEAKCHECK_DISABLE` conditional as well, take a look at `LeakCheck.Configuration.inc` this is where all the user configuration is hidden along with comment about each option (I don't have a fancy configuration tool like FastMM). – Honza R Feb 15 '16 at 16:31