kanze@gabi-soft.de writes:

[...]

| This is a definite weakness in the language, and one that it would be
| nice to fix.  Of course, fixing it means not just nullifying the pointer
| mentioned in the delete, but nullifying *all* pointers in the program
| which point to the object being deleted, including any internal pointers
| (pointers pointing somewhere into the middle of the object).

To make `nullifying delete' work properly and consistently, you need
to make fundamental core language changes.  All proposals I've seen so
far ignore computed pointer values.  But for that, we don't need to
change delete's semantics.  It sufficies to use the appropriate
abstraction tools.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

|>  David R Tribble wrote:

|>  > michael <serrano@ozemail.com.au> writes:
|>  > >| The proposition "std behaviour is a shame" should be backed up b=
y an
|>  > >| argument.

|>  > Gabriel Dos Reis wrote:
|>  > > Yes, I asked for such argument but didn't get any convincing one.

|>  > I gave one.

|>  > [1] Mandate that 'delete' should automatically invalidate its
|>  > pointer operand (by setting it to null).

|>  That's _not_ invalidation. A null pointer is a valid pointer.

|>  > This would plug a hole in the language, which currently allows
|>  > dangling pointers to be created without any warnings.

This is a definite weakness in the language, and one that it would be
nice to fix.  Of course, fixing it means not just nullifying the pointer
mentioned in the delete, but nullifying *all* pointers in the program
which point to the object being deleted, including any internal pointers
(pointers pointing somewhere into the middle of the object).

I think that the next step if for Mr. Tribble to post a sample
implementation of this, which doesn't require too much additional
overhead, so we can the discuss the issue further.  With a good, working
sample implementation as proof of concept, I think we could present a
proposition to the committee.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <39DBE134.7A8C@wanadoo.fr>, Valentin Bonnard
> <Bonnard.V@wanadoo.fr> writes
> >Let's say you have a program with one bug: it deletes and
> >already deleted pointer (sometimes using the same pointer
> >lvalue, sometimes not).
>
> Actually, any time a program tries to delete a pointer twice in any way
> there is a design error in your code. I would not advocate methods that
> hide design errors.

I think it all a question of policy. You have a class. It contains a
pointer to something. At some point, you will have to assign values to
that pointer, or get rid of it. So the question is: how do you specify
the policy on that pointer and more importantly, how you enforce that
policy such that all future maintainers are forced to follow it.

Smart pointers are one excellent way. But you need a good library of
various smart pointer with all the different policies. Nulling the
pointer is another a quick way to get a clear and simple policy: you can
always delete a pointer since it is either valid or null.

So it can be simply a mean to simplify policy decisions, and not
necessarily a way to hide errors.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39DBE134.7A8C@wanadoo.fr>, Valentin Bonnard
<Bonnard.V@wanadoo.fr> writes
>Let's say you have a program with one bug: it deletes and
>already deleted pointer (sometimes using the same pointer
>lvalue, sometimes not).

Actually, any time a program tries to delete a pointer twice in any way
there is a design error in your code. I would not advocate methods that
hide design errors.



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Valentin Bonnard" <Bonnard.V@wanadoo.fr> wrote in message
news:39DBE134.7A8C@wanadoo.fr...
> David R Tribble wrote:
> > Another question I asked was, why *not* let the compiler nullify the
> > pointer?
>
> For no really good reasons really. For so few good reasons that
> the compiler is _already_ allowed to do that -- no change need,
> no DR, no nothing. You can implement and release a patch to do
> that in your favorite free conforming C++ compiler, and will
> still be conforming !

A small caveat.  In most implementations you'll have to change
both the compiler and the linker.  Since the standard specifies
that the pointer is invalidated (more precisely: has indeterminate
value) only when the system deallocation function is called.
Typically the compiler doesn't have this knowledge...

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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

David R Tribble wrote:

> michael <serrano@ozemail.com.au> writes:
> >| The proposition "std behaviour is a shame" should be backed up by an
> >| argument.
>
> Gabriel Dos Reis wrote:
> > Yes, I asked for such argument but didn't get any convincing one.
>
> I gave one.
>
> [1] Mandate that 'delete' should automatically invalidate its pointer
> operand (by setting it to null).

That's _not_ invalidation. A null pointer is a valid pointer.

> This would plug a hole in the language, which currently allows
> dangling pointers to be created without any warnings.

ROTFL

(sorry, but this one is tooo funny)

> [2] A special exception would be mandated for deleting const pointers.
> A warning would be issued that a dangling pointer is being created,
> but the delete would still be allowed to occur.

Please notice that currently the standard never mandates any
warning. Adding this requirement would be a big change.

> [3] The compiler would be free to optimize away the pointer
> invalidation if it can determine that it is unnecssary (such as
> deleting a pointer that is about to go out of scope).

Obviously, you don't even need to mention it.

> Some people pointed out that deleting a null pointer was benign
> under C++ rules.  They pointed out that perfectly valid programs
> depended on this behavior.  So it made sense to them (logical
> symmetry) that 'delete' should nullify its pointer.

The first two sentences are perfectly correct. I just can't see
the link with the third one.

> One of the arguments against my proposal was that it does not provide
> any added benefit.  "If you want a deleted pointer to be null, just
> set it to null."

Indeed.

> I counter with the question, then why do dangling
> pointers occur if C++ is so safe already?

Is that an intended to be an argument, or just rhetorical sugar ?

> Another question I asked was, why *not* let the compiler nullify the
> pointer?

For no really good reasons really. For so few good reasons that
the compiler is _already_ allowed to do that -- no change need,
no DR, no nothing. You can implement and release a patch to do
that in your favorite free conforming C++ compiler, and will
still be conforming !

> Half the responses were concerned with efficiency; see [3].
> I am willing to accept what tiny overhead there may be to let the
> compiler set deleted pointers to null if it saves me from having to
> do it after every delete.

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

> The other half said it didn't go far enough because it didn't nullify
> every pointer to the object; but surely if you've got multiple
> pointers to an object, that is your problem and not the compiler's.

If I write:

   char* p = new char[10];
   delete []p;
   delete []p;

surely it's _the compiler's problem_, not mine, but when I write

   char* p = new char[10];
   char* q = p;
   delete []p;
   delete []q;

it's the _my_ problem, and mine only.  Interresting point
of view.

> Others stated that setting pointers to null created a false sense
> of security.  I'm not sure how else you can know that a pointer no
> longer points to anything other than setting it to null.

Two sentences.  Both correct.  But the reason why you put
them together in this paragraph, implying a logical relation,
isn't clear to me.

> Others suggested setting the pointer to an invalid value other than
> null, to cause program crashes later on if the pointer was
> subsequently used.  This is very little different than setting it
> to null,

Let's say you have a program with one bug: it deletes and
already deleted pointer (sometimes using the same pointer
lvalue, sometimes not).

Case 1: the program passes a test case, because the pointer
was nullified by the first delete.

It then fails during real-world use because the memory
management bug got undetected: the program tried to delete
twice the same memory block, but using different lvalues,
so the lvalue couldn't be nullified !

Case 2: the program fails ``cleanly'' at the test, with an
invalidated pointer. The bug is discovered and corrected.

Does it make a difference ?

I think so.

--

Valentin Bonnard

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]