> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > Sent: 16 January 2002 15:45 > > Ok... Now that I've followed this conversation a while... > > I'm entirely -1 on any function changing arguments based on dev/release > builds.
Technically we have two functions. A normal version and a debug version. At debug time, both functions will exist. A macro is used to override the callers of the normal function at debug time. > That means we can have the file/line arg of NULL if we simply _don't care_, > so we don't waste const string heap, but there will be a char* argument > always, or never. Why? The extra argument is completely useless in a release build. Why bother a user with an extra argument? > Pushing an extra NULL in a release build to the infrequently called > apr_pool_create is trivial. And painless. It's not only apr_pool_create. It's also clear and destroy. These are the operations you wish to track. And, I know there is some demand for output that can be used to replay what happened. Then, apr_palloc and apr_pcalloc will be added to this list aswell. > Bill Sander > ----- Original Message ----- > From: "Sander Striker" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Sunday, January 13, 2002 12:36 PM > Subject: Passing file/line ALL the time WAS: RE: [PATCH] Default tagging of > pools in debug mode [2] > > > > > From: Ian Holsman [mailto:[EMAIL PROTECTED] > > > Subject: Re: [PATCH] Default tagging of pools in debug mode [2] > > > > > > Stupid Question Time: > > > is there a problem just enabling file/line passing to this ALL the time? > > > I mean.. it's just a extra parameter on the stack. > > > > > > this would make it MUCH easier to enable/disable debugging. > > > > Although it would make things easier to enable debugging, for > > normal operation of an apr using application it is not needed. > > > > I don't feel the current hurdle one has to take to do memory > > debugging is too high. > > > > I'm -1 on doing file/line passing by default. It is a debugging > > tool/feature and it should stay that. > > > > Sander > > > > > > >
