The delete in both the cases is INVALID !!!!
Now the question is why does the delete not make it NULL  and some previous
mail showed a link to stroustrup's web page ! That was very clear and
obvious !

thanks folks for the discussion.enjoyed very much.

Sriram

"Ron Natalie" <ron@sensor.com> wrote in message
news:3CADDB9E.132344FA@sensor.com...
>
>
> >         How would this work if 'delete' NULLed the pointer?
>
> Both examples are invalid.  It's undefined to use a pointer value that
> has been deleted (even if you DONT dereference it).
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz <davids@webmaster.com> wrote:

>Ken Alverson wrote:
>
>> I still feel my analogy is valid, but this really isn't going anywhere, so
>> I'll drop the issue.
>>
>> Ken
>
> So what do you do if the value of the pointer is still needed?!
>
>Consider the following code:
>
>Mutex mutex_table[256];
>
>void LockMutex(void *p)
>{
> mutex_table[reinterpret_cast<unsigned int>(p)%256].Lock();
>}
>
>void UnlockMutex(void *p)
>{
> mutex_table[reinterpret_cast<unsigned int>(p)%256].Unlock();
>}
>
>void ConditionalLockedDelete(Foo *p)
>{
> LockMutex(p);
> if(p->ShouldDelete()) delete p;
> UnlockMutex(p);
>}

correct would be (need to change def of (Un)LockMutex
{
  int hash = HashPointer(p);
  LockMutex(hash);
  if(p->ShouldDelete()) delete p;
  UnlockMutex(hash);
}

This doesn't reaccess the pointer after deleting, and hopefully will encourage
you to use a better hash function. A large portion of your mutex_table is not
used as the bottom bits of p are often the same to enforce alignment
requirements, and if Foo is large some implementations may page align p and your
table will only have one usable mutex.
>
> How would this work if 'delete' NULLed the pointer? Here's another
>case:
>
>class Foo
>{
> protected:
> Foo *brother;
> bool can_delete;
> public:
> static bool Detach(Foo *a)
> {
>  if(can_delete) { delete a; return true; }
>  return false;
> }
> void BrotherNowGone(void) { brother=NULL; }
> Foo *GetBrother() { return brother; }
>}
>
>void DetachAndDeLink(Foo *a, Foo *b)
>{
  Foo *temp = a;
> bool did_delete=a->Detach();
> if(did_delete && (b->GetBrother()==a)) b->BrotherNowGone();
use temp instead of a now.
>}
>
> How would this work if 'delete' NULLed the pointer?
>
> DS
>
>---
>[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
>[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
>[              --- Please see the FAQ before posting. ---               ]
>[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

--
richard_damon@iname.com (Redirector to my current best Mailbox)
rdamon@beltronicsInspection.com (Work Adddress)
Richad_Damon@msn.com (Just for Fun)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> >void DetachAndDeLink(Foo *a, Foo *b)
> >{
>   Foo *temp = a;
> > bool did_delete=a->Detach();
> > if(did_delete && (b->GetBrother()==a)) b->BrotherNowGone();
> use temp instead of a now.
> >}
>
That doesn't help.  The value is still used after delete regardless
of whether you store it in temp.  Further, if GetBrother() references
the deleted value it also has problems.

The proper way is to redesign this to do "BrotherGoingToDie" to
remove any copies of the pointer before deleting the object.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

p2sam@uwaterloo.ca (Pedro Sam) wrote in message news:<a7j7vg$78s$1@watserv3.uwaterloo.ca>...
> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?

See what Bjarne Stroustrup say about this in one of his FAQ's:
    http://www.research.att.com/~bs/bs_faq2.html#delete-zero


--Robb

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On the rare occasions when you want it set to NULL (0) you can do that
yourself,
can't you?

You could write something like this:

template < typename T >
delete_and_null( T*& ptr )
{
   delete ptr;
   ptr = 0;
}

template < typename T >
delete_and_null_array( T*& ptr )
{
   delete [] ptr;
   ptr= 0;
}

Note that I have actually come across a real example where, even using a
smart-pointer, I wanted to set a pointer to 0 when its last reference was
deleted. That is because I had a singleton model where you could only
have one live object at a time, but that had a limited lifetime, and was
deleted when its last reference disappeared, but which could later be
re-created. To see partly how I did it, look at my own smart-pointer
template at http://www.nmtop40.com/CodeBase/SmartPtrT.h (look
at the second RefCountImpl class). (Sorry if this has gone slightly
off-topic).




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson wrote:

> I still feel my analogy is valid, but this really isn't going anywhere, so
> I'll drop the issue.
>
> Ken

 So what do you do if the value of the pointer is still needed?!

Consider the following code:

Mutex mutex_table[256];

void LockMutex(void *p)
{
 mutex_table[reinterpret_cast<unsigned int>(p)%256].Lock();
}

void UnlockMutex(void *p)
{
 mutex_table[reinterpret_cast<unsigned int>(p)%256].Unlock();
}

void ConditionalLockedDelete(Foo *p)
{
 LockMutex(p);
 if(p->ShouldDelete()) delete p;
 UnlockMutex(p);
}

 How would this work if 'delete' NULLed the pointer? Here's another
case:

class Foo
{
 protected:
 Foo *brother;
 bool can_delete;
 public:
 static bool Detach(Foo *a)
 {
  if(can_delete) { delete a; return true; }
  return false;
 }
 void BrotherNowGone(void) { brother=NULL; }
 Foo *GetBrother() { return brother; }
}

void DetachAndDeLink(Foo *a, Foo *b)
{
 bool did_delete=a->Detach();
 if(did_delete && (b->GetBrother()==a)) b->BrotherNowGone();
}

 How would this work if 'delete' NULLed the pointer?

 DS

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>         How would this work if 'delete' NULLed the pointer?

Both examples are invalid.  It's undefined to use a pointer value that
has been deleted (even if you DONT dereference it).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CA26183.B5822E43@acm.org...
> Ken Alverson wrote:
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3CA0FD94.A13F8343@acm.org...
> > >
> > > Having delete set pointers to null doesn't check anything.
> >
> > No, but most common platforms will flag a null dereference.  Putting a
> > canary in the stack doesn't check anything either, but coupled with a
> > validity check it can catch errors.  Setting the pointer to null doesn't
> > check anything, but coupled with hardware that traps access violations
it
> > can catch errors.
> >
> > If you're trying to argue that it isn't reasonable on all platforms
because
> > we can't assume protected memory and therefore it shouldn't be mandated,
> > that's fine.  If you're trying to argue the effect is negative rather
than
> > positive, I disagree.
> >
>
> I'm just pointing out the flaw in your purported analogy.

I still feel my analogy is valid, but this really isn't going anywhere, so
I'll drop the issue.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Dirk Gerrits wrote:
>>We could do with an FAQ round here.
>
>
> <snip>
>
>>---
>>[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
>>[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
>>[              --- Please see the FAQ before posting. ---               ]
>>[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
>
>
> It seems there used to be a FAQ (link above) but the link is dead now.
> The page is still in Google's cache though:
>
> http://www.google.com/search?q=cache:oVE9HO3dg9QC:www.research.att.com/~aust
> ern/csc/faq.html+comp.std.c%2B%2B+faq&hl=en
>
> Regards,
>
> Dirk Gerrits

As an intermim measure, the FAQ is back online at

http://www.jamesd.demon.co.uk/csc/faq.html

This may or may not be its permanent home.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"John Nagle" <nagle@animats.com> wrote

> Handles and smart pointers don't work very well in C++.
> The language doesn't support them adequately.  Even
> the simplest case, auto_ptr, can't be made safe.
> People have tried hard on that one, and the
> semantics of auto_ptr we have now are, at best,
> mediocre.

Precisely the point I was making the other day to some coworkers who wonder
why I don't use smart pointer types. In my experience, smart pointers in C++
add as many problems as they solve (including the fact that there are many,
many semantic variations on the theme). I'd rather rely on encapsulated
resource management and "smart" programmers. However, I was hoisted by my
own petard when we discovered that one of our developers wasn't all that
"smart."



> The C/C++ attitude that the language and compiler
> have no responsibility for memory integrity is the
> single largest cause of production defects in programs
> today.  Look at Bugtraq.   It's also one of the main
> motivators for transitioning to Java and various
> scripting languages.

Very true; an excellent programmer with professional skills will not make
memory management errors. However, I've just spent two days digging out
memory allocation errors in code written by someone with 15 years of "C++
experience". In my experience, there just aren't that many "professional"
programmers -- and that's why we have dumbed-down versions of C++ called
Java and C# (neither of which, BTW, are immune to memory corruption
problems).

--
Scott Robert Ladd
http://www.coyotegulch.com
No ads -- just info, algorithms, and very free code.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

    There are tools to catch this kind of error (such as Purify available
both on UNIX and WinNT), and in my experience they pay for themselves in
less than a week on any project needing more than a single programmer.

    Unless you are working on cross platforms or tight real time, you should
try to convince your management to buy one of those (I only have experience
with Purify, but there are other solutions on the market, and the best of
those tools also track file handle leakage, and other hard to find errors
like this - memory is only the most commonly misused ressource used in a
program).

"Scott Robert Ladd" <scott@coyotegulch.com> a    crit dans le message de news:
BZoo8.4> many
> Very true; an excellent programmer with professional skills will not make
> memory management errors. However, I've just spent two days digging out
> memory allocation errors in code written by someone with 15 years of "C++
> experience". In my experience, there just aren't that many "professional"
> programmers -- and that's why we have dumbed-down versions of C++ called
> Java and C# (neither of which, BTW, are immune to memory corruption
> problems).



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CA0FD94.A13F8343@acm.org...
> > >
> > > I thought the analogy was pretty clear.  The stack checking compiler
> doesn't
> > > catch all stack errors, but it does catch a certain class of stack
> errors
> > > (those that overwrite the return address area, generally).  The pointer
> > > nulling compiler doesn't catch all stale pointer errors, but it does
> catch a
> > > certain class of stale pointer errors (those that use the same instance
> of
> > > the pointer that was deleted).
> > >
> >
> > Having delete set pointers to null doesn't check anything.
>
> No, but most common platforms will flag a null dereference.  Putting a
> canary in the stack doesn't check anything either, but coupled with a
> validity check it can catch errors.  Setting the pointer to null doesn't
> check anything, but coupled with hardware that traps access violations it
> can catch errors.
>
> If you're trying to argue that it isn't reasonable on all platforms because
> we can't assume protected memory and therefore it shouldn't be mandated,
> that's fine.  If you're trying to argue the effect is negative rather than
> positive, I disagree.
>

I'm just pointing out the flaw in your purported analogy.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi all,

I'm curious about the delete operator and NULL pointers.  Why doesn't
the standard require that the delete operator to set the pointer's value
to NULL?

If the pointer is NULL, then if someone comes along and try to access
that pointer, it would crash with a segfault, instead of reading garbage
( or even worse, write over some memory ).

Crash early is a Good Thing(TM) right?

I would appreciate any comments.

p2sam


--
Life is like an analogy

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a7j7vg$78s$1@watserv3.uwaterloo.ca>, Pedro Sam
<p2sam@uwaterloo.ca> writes
>I'm curious about the delete operator and NULL pointers.  Why doesn't
>the standard require that the delete operator to set the pointer's value
>to NULL?

We could do with an FAQ round here. delete gets a pointer value, (and
essentially that is what it must get) aka an address of the object to be
destroyed and have its memory released. It knows nothing of the
location, if any, where that address is stored.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pedro Sam wrote:
>
> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?
>
> If the pointer is NULL, then if someone comes along and try to access
> that pointer, it would crash with a segfault, instead of reading garbage
> ( or even worse, write over some memory ).
>

void f()
{
int *ip = new int;
delete ip; // no point in setting to null:
  // goes out of scope immediately
}

void f(int *ip)
{
delete ip; // setting to null would be misleading:
  // caller still holds pointer
}

Knowing whether a pointer is valid is a matter of design. If your design
calls for a flag in some cases, then you can use null as that flag. Most
of the time assigning null is not needed, or downright dangerous.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

p2sam@uwaterloo.ca (Pedro Sam) wrote:

> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?

You weren't able to do this anymore:

struct A {};
struct X
{
 A * const a;
 X() : a(new A) { }
 ~X() { delete a; }
};

>
> If the pointer is NULL, then if someone comes along and try to access
> that pointer, it would crash with a segfault, instead of reading garbage
> ( or even worse, write over some memory ).
>
> Crash early is a Good Thing(TM) right?

Accessing a pointer after it has been deleted is a lesser source of errors
and it's almost always easy to find. The 'real' kind of error occurs when
you access deleted memory through an aliased pointer: The is much harder to
track, happens more frequently (at least to the unstructured programmer) and
can't be covered by a modifing delete.

If you want this kind of delete, define one:

template<class T>
void destroy(T * &t)
{
 delete t;
 t=NULL;
}

Marco

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
....
> We could do with an FAQ round here. delete gets a pointer value, (and
> essentially that is what it must get) aka an address of the object to be
> destroyed and have its memory released. It knows nothing of the
> location, if any, where that address is stored.

The point is, that delete could have been given a different interface
that took a pointer to a pointer, or a reference to a pointer, which
would have allowed such semantics. So the question of why that wasn't
done is legitimate.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> We could do with an FAQ round here.

<snip>

> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

It seems there used to be a FAQ (link above) but the link is dead now.
The page is still in Google's cache though:

http://www.google.com/search?q=cache:oVE9HO3dg9QC:www.research.att.com/~aust
ern/csc/faq.html+comp.std.c%2B%2B+faq&hl=en

Regards,

Dirk Gerrits



======================================= MODERATOR'S COMMENT:
 The comp.std.c++ will available again shortly,
probably with a new URL which will be advertised as normal
in each message posted to this group.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C9DD892.94860335@acm.org...
> Pedro Sam wrote:
> >
> > I'm curious about the delete operator and NULL pointers.  Why doesn't
> > the standard require that the delete operator to set the pointer's value
> > to NULL?
> >
> > If the pointer is NULL, then if someone comes along and try to access
> > that pointer, it would crash with a segfault, instead of reading garbage
> > ( or even worse, write over some memory ).
> >
>
> void f()
> {
> int *ip = new int;
> delete ip; // no point in setting to null:
> // goes out of scope immediately
> }

Red herring...sure there's no point in that case, but that's easily taken
care of by the optimizer...

> void f(int *ip)
> {
> delete ip; // setting to null would be misleading:
> // caller still holds pointer
> }

This is better, but you could argue that you shouldn't be able to modify the
pointer (and deleting the pointer is arguably modifying it) without a
reference, in which case things would still be consistant.

The damning issue then would be all the programs that would break due to the
change.

> Knowing whether a pointer is valid is a matter of design. If your design
> calls for a flag in some cases, then you can use null as that flag. Most
> of the time assigning null is not needed, or downright dangerous.

I can't see how it would be *more* dangerous than not setting it to NULL,
but I agree that *relying* on it being NULL would be a bad idea.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> > void f(int *ip)
> > {
> > delete ip; // setting to null would be misleading:
> > // caller still holds pointer
> > }
>
> This is better, but you could argue that you shouldn't be able to modify the
> pointer (and deleting the pointer is arguably modifying it) without a
> reference, in which case things would still be consistant.

Huh? ip is modifiable. I don't see how references come into this.

>
> The damning issue then would be all the programs that would break due to the
> change.
>
> > Knowing whether a pointer is valid is a matter of design. If your design
> > calls for a flag in some cases, then you can use null as that flag. Most
> > of the time assigning null is not needed, or downright dangerous.
>
> I can't see how it would be *more* dangerous than not setting it to NULL,
> but I agree that *relying* on it being NULL would be a bad idea.
>

Then you do understand how it's *more* dangerous than not setting it to
null.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3C9DD892.94860335@acm.org...
> > Pedro Sam wrote:
> > >
> > > I'm curious about the delete operator and NULL pointers.  Why doesn't
> > > the standard require that the delete operator to set the pointer's value
> > > to NULL?
> > >
> > > If the pointer is NULL, then if someone comes along and try to access
> > > that pointer, it would crash with a segfault, instead of reading garbage
> > > ( or even worse, write over some memory ).
> > >
> >
> > void f()
> > {
> > int *ip = new int;
> > delete ip; // no point in setting to null:
> > // goes out of scope immediately
> > }
>
> Red herring...sure there's no point in that case, but that's easily taken
> care of by the optimizer...

Red herring. You don't write useless code just because you think the
compiler will get rid of it. The point was that setting the pointer to
null often doesn't accomplish anything, which may not have occurred to
the original poster.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pedro Sam wrote:
>
> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?
>
> If the pointer is NULL, then if someone comes along and try to access
> that pointer, it would crash with a segfault, instead of reading garbage
> ( or even worse, write over some memory ).
>
> Crash early is a Good Thing(TM) right?
>
> I would appreciate any comments.
>
> p2sam

There's an old principle that goes back to the design of C, and
continues into C++: you don't pay for what you don't use. Most of the
time, well-designed code doesn't need to null the pointer, not even as a
safety precaution. I usually try to arrange it that a pointer goes out
of scope immediately after freeing the memory it points at; it's not
very difficult. Therefore, the (admittedly small) amount of time needed
to null the pointer would be wasted. Code that needs the pointer to be
nulled can do so explicitly. If you need that feature a lot, it's
trivial to write a template wrapper for delete that will do it
automatically.

Now, this is a very minor matter, and it might have been changed when
C++ supplemented free() with the 'delete' operator. However, C++ code
generally makes far less explicit use of dynamic memory allocation than
C. You should be using containers, and certain kinds of smart pointers,
which handle the allocation in an exception-safe manner, rather that
doing it yourself, and having to worry about making sure that exceptions
don't prevent the 'delete' from occurring.

<pedantic>
The word NULL, when written entirely in capital letters, should be
treated as a noun, not a verb or an adjective. It's the name of a
particular stardard library macro. The word 'null', in lower case, it
the appropriate one to use in all other cases. In particular, it's not
possible for a pointer value to be NULL; NULL is required to be a null
pointer constant (NPC), and NPCs are required to have an integer type,
not a pointer type. A pointer value can be null, and such a pointer will
always compare equal to NULL, but that's because of the special rules
for equality comparisons involving NPCs, not because the pointer value
is NULL.
</pedantic>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C9DF1AC.D46ECA4B@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> writes
>Francis Glassborow wrote:
>....
>> We could do with an FAQ round here. delete gets a pointer value, (and
>> essentially that is what it must get) aka an address of the object to be
>> destroyed and have its memory released. It knows nothing of the
>> location, if any, where that address is stored.
>
>The point is, that delete could have been given a different interface
>that took a pointer to a pointer, or a reference to a pointer, which
>would have allowed such semantics. So the question of why that wasn't
>done is legitimate.

But to justify that it would be necessary to demonstrate that the result
was more useful. Everything I have ever seen shows that the contrary
would be the case. In fact since people have come to recognise the
desirability of using smart pointers, handles etc. the case is almost
entirely moot.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Sun, 24 Mar 2002 00:39:58 CST, p2sam@uwaterloo.ca (Pedro Sam)
wrote:

>Hi all,
>
>I'm curious about the delete operator and NULL pointers.  Why doesn't
>the standard require that the delete operator to set the pointer's value
>to NULL?
>
As F. Glassborow has pointed out, delete doesn't require an l-value.
In cases where you actually have a pointer you can implement something
along these lines:

---- untested code ---

#include <cstddef>

template <typename T>
void delete_and_null(T*& p) {
 delete p;
 p = NULL;
}

template <typename T, std::size_t N>
void delete_and_null(T (*&p)[N] ) {
  delete [] p;
  p = NULL;
}

----------------------------

Anyhow you have to be very careful when attempting to delete arrays
through a pointer to the first element:

char * p = new char [10];  // array to pointer conversion
.....
delete_and_null(p);          // wrong version called!


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <a7lhfq$co1$1@eeyore.INS.cwru.edu>, Ken Alverson
<Ken@Alverson.com> writes
>I can't see how it would be *more* dangerous than not setting it to NULL,
>but I agree that *relying* on it being NULL would be a bad idea.

It is easier to teach people a simple rule (and a simple solution) such
as:

It is your responsibility to null a pointer when the object it points to
has been deleted. Rather than say, sometimes the compiler will do it but
now you must learn when it won't.

And the solution? Well learn to use handles and smart pointers.


--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C9E5921.735FEB25@acm.org...
> Ken Alverson wrote:
> >
> > > void f(int *ip)
> > > {
> > > delete ip; // setting to null would be misleading:
> > > // caller still holds pointer
> > > }
> >
> > This is better, but you could argue that you shouldn't be able to modify
the
> > pointer (and deleting the pointer is arguably modifying it) without a
> > reference, in which case things would still be consistant.
>
> Huh? ip is modifiable. I don't see how references come into this.

Sorry...I didn't quite say what I was thinking, nor was what I was thinking
totally thought through.

I was trying to say that rules could be made that would outlaw such behavior
(example - a pointer parameter must be a const pointer/delete doesn't work
on const pointer).  I wasn't trying to say that that would be a desirable
goal, or even a possible one, without breaking existing code.  I was merely
attempting to play devil's advocate.

> > > Knowing whether a pointer is valid is a matter of design. If your
design
> > > calls for a flag in some cases, then you can use null as that flag.
Most
> > > of the time assigning null is not needed, or downright dangerous.
> >
> > I can't see how it would be *more* dangerous than not setting it to
NULL,
> > but I agree that *relying* on it being NULL would be a bad idea.
> >
>
> Then you do understand how it's *more* dangerous than not setting it to
> null.

That's like saying (for example) a compiler that supports checking the stack
for corruption is more dangerous than one that does not, because people will
stop worrying about buffer overflows, instead relying on the compiler to
catch them.

While that could possibly be true for some, I have a hard time believing the
average error rate would go up due to it.  A few spikes versus a lot of
small dips...

Personally, I recommend smart pointers anyway...most people can't be trusted
with a pointer in the first place.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C9E5A54.12B15FB3@acm.org...
> Ken Alverson wrote:
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3C9DD892.94860335@acm.org...
> > >
> > > void f()
> > > {
> > > int *ip = new int;
> > > delete ip; // no point in setting to null:
> > > // goes out of scope immediately
> > > }
> >
> > Red herring...sure there's no point in that case, but that's easily
taken
> > care of by the optimizer...
>
> Red herring. You don't write useless code just because you think the
> compiler will get rid of it. The point was that setting the pointer to
> null often doesn't accomplish anything, which may not have occurred to
> the original poster.

I do so on a regular basis.  I return classes, relying that the return value
will be optimized, avoiding a copy construction.  I use smart pointers,
relying that the function call to operator-> or operator* will be
eliminated.  I use vectors, relying that iterator access will be inlined to
the point where it will be as fast as array access.

The point that the result doesn't survive the function is good.  It has
failed to be useful.  But it hasn't actively done harm either.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Gennaro Prota <gennaro_prota@yahoo.com> wrote in message news:<f94s9usiqvi9s4hfspdhkni29d3dr20fdq@4ax.com>...
[..]

>
> template <typename T, std::size_t N>
> void delete_and_null(T (*&p)[N] ) {
>   delete [] p;
>   p = NULL;
> }
>

Hmmm... congratulations, Genny! :) Now, how do you get your hands on a
"pointer to array" via a new expression?

Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pedro Sam" <p2sam@uwaterloo.ca> wrote in message
news:a7j7vg$78s$1@watserv3.uwaterloo.ca...
> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?
>
> If the pointer is NULL, then if someone comes along and try to access
> that pointer, it would crash with a segfault, instead of reading garbage
> ( or even worse, write over some memory ).

Consider the following example:

    class bar { /* ... */ };

    class foo
    {
    public:
     ~foo()
      {
        for( set::set< bar * >::iterator i( s.begin() );
             i != s.end(); ++i )
          delete *i;
      }
    private:
      std::set< bar * > s;
    };


i) std::set's iterators are all const_iterators -- even the one named
'iterator' so you cannot modifiy the value.

ii) if you did nullify the iterators value (using, say, a const_cast) bad
things would happen because the set would have been tricked into containing
multiple equal values.

--
Richard Smith


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Stroustrup has a whole discussion about exactly this subject at
"http://www.research.att.com/~bs/bs_faq2.html#delete-zero".

Fairly exhaustive,

Joe.

p2sam@uwaterloo.ca (Pedro Sam) wrote in message news:<a7j7vg$78s$1@watserv3.uwaterloo.ca>...
> Hi all,
>
> I'm curious about the delete operator and NULL pointers.  Why doesn't
> the standard require that the delete operator to set the pointer's value
> to NULL?
>
> If the pointer is NULL, then if someone comes along and try to access
> that pointer, it would crash with a segfault, instead of reading garbage
> ( or even worse, write over some memory ).
>
> Crash early is a Good Thing(TM) right?
>
> I would appreciate any comments.
>
> p2sam

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote:
> Ken Alverson wrote:
>>
>> "Pete Becker" <petebecker@acm.org> wrote in message
>> news:3C9DD892.94860335@acm.org...
>> > Pedro Sam wrote:
>> > >
>> > > I'm curious about the delete operator and NULL pointers.  Why doesn't
>> > > the standard require that the delete operator to set the pointer's value
>> > > to NULL?
>> > >
>> > > If the pointer is NULL, then if someone comes along and try to access
>> > > that pointer, it would crash with a segfault, instead of reading garbage
>> > > ( or even worse, write over some memory ).
>> > >
>> >
>> > void f()
>> > {
>> > int *ip = new int;
>> > delete ip; // no point in setting to null:
>> > // goes out of scope immediately
>> > }
>>
>> Red herring...sure there's no point in that case, but that's easily taken
>> care of by the optimizer...
>
> Red herring. You don't write useless code just because you think the
> compiler will get rid of it. The point was that setting the pointer to
> null often doesn't accomplish anything, which may not have occurred to
> the original poster.
>

I believe that by setting the pointer to NULL, further unintended access
to that pointer will crash the program immediately (which is good).  And
I do agree that this feature is totally useless for a correctly working
program that does not reference a stale pointer.  (but one can argue the
same thing about assertions)

--
It's easier to get forgiveness for being wrong than forgiveness for
being right.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:

> In article <a7lhfq$co1$1@eeyore.INS.cwru.edu>, Ken Alverson
> <Ken@Alverson.com> writes
>
>> I can't see how it would be *more* dangerous than not setting it to NULL,
>> but I agree that *relying* on it being NULL would be a bad idea.
>
>
> It is easier to teach people a simple rule (and a simple solution) such as:
>
> It is your responsibility to null a pointer when the object it points to
> has been deleted. Rather than say, sometimes the compiler will do it but
> now you must learn when it won't.
>
> And the solution? Well learn to use handles and smart pointers.


     Handles and smart pointers don't work very well in C++.
The language doesn't support them adequately.  Even
the simplest case, auto_ptr, can't be made safe.
People have tried hard on that one, and the
semantics of auto_ptr we have now are, at best,
mediocre.

     We went through this back when I was proposing
"strict C++".  It can be done, but not with total
backwards compatibility.

     The C/C++ attitude that the language and compiler
have no responsibility for memory integrity is the
single largest cause of production defects in programs
today.  Look at Bugtraq.   It's also one of the main
motivators for transitioning to Java and various
scripting languages.

    John Nagle
    Animats


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3C9E5A54.12B15FB3@acm.org...
> > Ken Alverson wrote:
> > > "Pete Becker" <petebecker@acm.org> wrote in message
> > > news:3C9DD892.94860335@acm.org...
> > > >
> > > > void f()
> > > > {
> > > > int *ip = new int;
> > > > delete ip; // no point in setting to null:
> > > > // goes out of scope immediately
> > > > }
> > >
> > > Red herring...sure there's no point in that case, but that's easily
> taken
> > > care of by the optimizer...
> >
> > Red herring. You don't write useless code just because you think the
> > compiler will get rid of it. The point was that setting the pointer to
> > null often doesn't accomplish anything, which may not have occurred to
> > the original poster.
>
> I do so on a regular basis.  I return classes, relying that the return value
> will be optimized, avoiding a copy construction.

Returning classes is not useless code.

> I use smart pointers,
> relying that the function call to operator-> or operator* will be
> eliminated.  I use vectors, relying that iterator access will be inlined to
> the point where it will be as fast as array access.

Inline functions are not useless code.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pedro Sam wrote:
>
> I believe that by setting the pointer to NULL, further unintended access
> to that pointer will crash the program immediately (which is good).

Believing it doesn't make it so. <g> Dereferencing a null pointer
produces undefined behavior. Nothing more.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C9FD370.908FB6F8@acm.org...
> Ken Alverson wrote:
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3C9E5A54.12B15FB3@acm.org...
> > >
> > > Red herring. You don't write useless code just because you think the
> > > compiler will get rid of it. The point was that setting the pointer to
> > > null often doesn't accomplish anything, which may not have occurred to
> > > the original poster.
> >
> > I do so on a regular basis.  I return classes, relying that the return
value
> > will be optimized, avoiding a copy construction.
>
> Returning classes is not useless code.

No, but the resulting copy construction that would happen without return
value optimization is.

> > I use smart pointers,
> > relying that the function call to operator-> or operator* will be
> > eliminated.  I use vectors, relying that iterator access will be inlined
to
> > the point where it will be as fast as array access.
>
> Inline functions are not useless code.

The function call itself is useless.  The effects of the function call are
not.  If the compiler wasn't able to optimize simple cases like that, people
would use macros instead.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> That's like saying (for example) a compiler that supports checking the stack
> for corruption is more dangerous than one that does not, because people will
> stop worrying about buffer overflows, instead relying on the compiler to
> catch them.
>

I don't see how. But since you haven't mentioned how you reached this
conclusion it's not possible to see where your reasoning went astray.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CA063FF.3C2EE83A@acm.org...
> Ken Alverson wrote:
> >
> > That's like saying (for example) a compiler that supports checking the
stack
> > for corruption is more dangerous than one that does not, because people
will
> > stop worrying about buffer overflows, instead relying on the compiler to
> > catch them.
> >
>
> I don't see how. But since you haven't mentioned how you reached this
> conclusion it's not possible to see where your reasoning went astray.

I thought the analogy was pretty clear.  The stack checking compiler doesn't
catch all stack errors, but it does catch a certain class of stack errors
(those that overwrite the return address area, generally).  The pointer
nulling compiler doesn't catch all stale pointer errors, but it does catch a
certain class of stale pointer errors (those that use the same instance of
the pointer that was deleted).

Either case may cause a certain portion of the programmer population to rely
on the feature and thereby introduce more errors, but the vast majority will
continue in the manner they previously were and have less errors because the
compiler is catching mistakes.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ken Alverson wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3CA063FF.3C2EE83A@acm.org...
> > Ken Alverson wrote:
> > >
> > > That's like saying (for example) a compiler that supports checking the
> stack
> > > for corruption is more dangerous than one that does not, because people
> will
> > > stop worrying about buffer overflows, instead relying on the compiler to
> > > catch them.
> > >
> >
> > I don't see how. But since you haven't mentioned how you reached this
> > conclusion it's not possible to see where your reasoning went astray.
>
> I thought the analogy was pretty clear.  The stack checking compiler doesn't
> catch all stack errors, but it does catch a certain class of stack errors
> (those that overwrite the return address area, generally).  The pointer
> nulling compiler doesn't catch all stale pointer errors, but it does catch a
> certain class of stale pointer errors (those that use the same instance of
> the pointer that was deleted).
>

Having delete set pointers to null doesn't check anything.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3CA0FD94.A13F8343@acm.org...
> >
> > I thought the analogy was pretty clear.  The stack checking compiler
doesn't
> > catch all stack errors, but it does catch a certain class of stack
errors
> > (those that overwrite the return address area, generally).  The pointer
> > nulling compiler doesn't catch all stale pointer errors, but it does
catch a
> > certain class of stale pointer errors (those that use the same instance
of
> > the pointer that was deleted).
> >
>
> Having delete set pointers to null doesn't check anything.

No, but most common platforms will flag a null dereference.  Putting a
canary in the stack doesn't check anything either, but coupled with a
validity check it can catch errors.  Setting the pointer to null doesn't
check anything, but coupled with hardware that traps access violations it
can catch errors.

If you're trying to argue that it isn't reasonable on all platforms because
we can't assume protected memory and therefore it shouldn't be mandated,
that's fine.  If you're trying to argue the effect is negative rather than
positive, I disagree.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]