Path: utzoo!censor!dybbuk!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!spool2.mu.edu!uunet!microsoft!martino From: martino@microsoft.UUCP (Martin O'RIORDAN) Newsgroups: comp.lang.c++ Subject: Re: Curious about operator delete setting ptrs to zero... Message-ID: <60361@microsoft.UUCP> Date: 8 Jan 91 22:37:19 GMT Article-I.D.: microsof.60361 References: Reply-To: martino@microsoft.UUCP (Martin O'RIORDAN) Organization: Microsoft Corp., Redmond WA Lines: 47 The primary reason for not setting the pointer to NULL has to do with the age old problem of aliases in C. This has of course been inheritted by C++. Consider the following code fragment :- void foo () { char * p, * q; p = new char[ 25 ]; q = p; // The alias delete p; // sets 'p' to NULL !! delete q; // But what about the alias ? } Okay, so you can say that a clever compiler could do enough analyses to determine that 'q' is a statically determinable alias for 'p'. However, typical alias problems are not so simple. Pointers and heap are primarily used to control object lifetimes in ways separate to the static/lexical control flow of a program. Pointers are often passed beyond the function that allocated the object. Consider :- extern void bar ( char * ); void foo () { char * p; p = new char[ 25 ]; bar ( p ); // The compiler doesn't know what 'bar' does with the value delete p; // What if 'bar' already deleted the space ? } This case, despite being simple in form is impossible for a compiler based on separate compilation technology to analyse for aliasing. To achieve this kind of thing, pointers would need to be handles which referred to the object only through an indirect table, as in PASCAL. The improved security for deletion would be offset by the considerable increase in access cost for the object. To add the facility for 'delete' to set the pointer provided to NULL, would in effect impose a mechanism such as this on the language. It is not a small scale change. Martin O'Riordan