BorlandTalk.com

Kristofer Skaug · Guest

Hi Pierre and FastMM fans,

would it be possible (without major public outcry) to change the following
default setting in FastMM4options.inc:

{$define RequireDebuggerPresenceForLeakReporting}

? To me, this default is most inconvenient, and I don't see how it helps
anyone to have leak reporting enabled only when running in the debugger. If
you're worried that end-users might observe leak notifications on shutdown,
you must control your build process more closely (turning FullDebugMode off
first, for starters).

Due to the way we store FastMM centrally in our network repository, we
cannot just go and change this .inc file as we like every day for individual
testing/debug purposes (actually we've made it read-only). So I need
FastMM4options.inc to be frozen in a usable form. The alternative is, if I
_really_ need to change something for a single test, I save a local copy of
both FastMM4 and its '.inc' file to my local hard disk.

Before you bark, of course I'm now changing the .inc file in this exact way
before 'freezing' it in our repository. But it would be even more reassuring
if the file came with the most useful settings out-of-the-box.

--
Kristofer

Kristofer Skaug · Guest

Nicholas Sherlock wrote:
:: Eh? It seems to me that this is the best option to be left on by
:: default! Who wants, by default, their customers to panic when they
:: see memory leaks (Especially when the leaks are tiny and constant)?

Many of my apps are complex systems with processes spawning each other -
difficult to run from within the debugger (only when I _have_ to). And
furthermore, they often interact (and can thus only be tested seriously)
with custom hardware, that is not available on my development machine.
So, as a rule, I prefer to have leak reporting functioning independently of
the IDE and debugger.

Anyway, I wouldn't dream of leaving FastMM "FullDebugMode" enabled in a
shipping build! Apart from the potential embarrassment vs the customer, it's
a resource and performance overhead. It's really all about appreciating the
difference between development/test builds and shipping builds. But I do
recall things having been different (once upon a time), so I'm not surprised
if some of you out there still prefer to ignore this difference.

--
Kristofer

Kristofer Skaug · Guest

Pierre le Riche wrote:
:: The biggest counter argument I can think of is that sometimes you
:: don't want to bother with separate development/distribution builds,
:: but you don't want your users to see your memory leaks either. I
:: know I am lazy that way Smile

.

See my reply to Nicholas Sherlock below, for further reasons.

--
Kristofer

Nicholas Sherlock · Guest

Kristofer Skaug wrote:

Pierre le Riche · Guest

Hi Kristofer,

Nicholas Sherlock · Guest

Kristofer Skaug wrote:

Kristofer Skaug · Guest

Nicholas Sherlock wrote:

Pierre le Riche · Guest

Kristofer Skaug · Guest

Pierre le Riche wrote:
:: That's a very good point. Would it help if I change the names of the
:: options so that they are all off by default? In cases where they are
:: now on by default I can just change the option name by prepending a
:: "Not..." (or something) and have it off by default.

I'm all for a minimalistic change. As far as I'm concerned, most of the
default options are very sensible. Inverting them by prefixing a "Not..." is
likely to produce some very odd option names - and makes the "project
defines" edit box even more crowded.
Last but not least, a major turnabout in defaults is likely to frustrate a
lot of people who may have written their own complex defines constructs on
top of FastMM's symbol set.
Disabling the default "RequireDebuggerPresence..." option would be enough
for now, IMO.

FastMM has become a virtually indispensable part of Delphi (just like
GExperts), so you're tugging on a very big and change-resistant ship by
now..

--
Kristofer