Well, that has to do with carpets, floors and blankets.
Say you are fully aware that the OS will return all memory after a program is closed anyway, why would you hunt down that leak that obviously is there but you can not find?
Or you found, but YOU, a mere programmer, decided is too expensive to solve? Of course you don't consult any colleagues because you don't want to look silly and you are god and god knows best.
You are the
god programmer, so you just put a blanket over your head and send it to testing... Testers ignore run-time behavior, they just look at the stability. Sort of...
So you can lift up the carpet and put your leak there. Maybe it goes away...
You do this, of course, just before Christmas so you know you will keep your bonus...
Timing is essential here.
So basically the option is there to remember you that you were a very naughty boy or girl.
That... or you invested money in leaky third-party components that are "brilliant" and your house would collapse if you.... (but that is recursive...)
It is almost never an
intended memory leak. It is a
known memory leak that you want to ignore. Because everything else seems ok. And hey! it works!
On a serious note:
If you have multiple leaks it is a real help to hide some of them while you are hunting the others. They may have to do with each other.
[/]
Of course
Delphi professional programmers feel obliged to keep it in the production code...
At least until February.
Yes, the issue is cyclic.