On Sep 24, 1:25 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:
> > On Sep 23, 11:56 pm, "Alf P. Steinbach" <al...@start.no> wrote:

> > [...]
> >> No. Actually, apart from implementing your own per-class allocation
> >> scheme, the main use of implementing your own allocator function that
> >> I'm aware of is to obfuscate the new'ing of an instance of the class in
> >> question, so that you're in practice ensured that only your own special
> >> macro for that is used, which then guarantees that the pointer produced
> >> is wrapped in a suitable smart pointer.

> > That doesn't work.

> It works.

Maybe we're talking about different things. I thought I
understood that you defined a macro with the name "new", e.g.:

#define new new( __FILE__, __LINE__ )

That doesn't work; formally, it's undefined behavior, and
practically, it's going to cause no end of havoc as soon as you
include something like <vector> (unless, of course, you're
compiler supports "export", and the library was written with
this in mind).

> For details you can check out my old pointers introduction.

> >> In principle I guess it could
> >> also be used to disallow dynamic allocation, although I fail to imagine
> >> any practical use for that.

> > The most frequent use is debugging. There's a debugging
> > new/delete at my site, for example, which saves the stack
> > walkback at the allocation site, sets guard zones at either end
> > (to detect overwrites), checks for double deletes and memory
> > leaks, etc. It's doubtlessly significantly slower than the
> > standard version, but I use it in my unit tests, and have found
> > a few bugs thanks to it.

> That's what debuggers are used for. :-) On Windows platforms.

How does a debugger tell you what happened in the past? Where a
block was allocated, if it turns out to have leaked, for
example. For that matter, how does it tell you you've
overwritten beyond the end of an allocated block?

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34