On 24/08/2025 14:59, organicoman wrote:
>
> Fortunately for a great many of the C++ users out there, what the
> standards say is important, /not/ what particular OS's do. The majority
> of "things running software" out there do not run an OS that has a
> concept of "segfault" - the majority do not use an OS at all. C++ is
> wider than just Windows and *nix.
>
> And even on *nix or Windows, dereferencing a null pointer is in no way
> guaranteed to give a segfault. Dereferencing a null pointer is
> undefined behaviour, and can cause daemons to be launched from your
> nose. /That/ is more important.
>
> 😂 let's exorcis them with a 'delete' expression which assign nullptr
> (whatever it means 0 or anything else) to its 'reference' argument.
>

That would be nice - if it had the slightest influence on the issue,
which it does not.

If you use "delete p;", and then try to dereference p, then the
behaviour is undefined. /Anything/ can happen - including launching
nasal daemons, or crashing the program, or deleting your files, or
coincidentally doing something useful. It does not matter if "p" is
assigned to nullptr, left unchanged, or has a random value - the
behaviour is still undefined.

The only way you can free a pointer of some sort and safely catch
invalid attempts to re-use the freed pointer is by checking when the
pointer is /used/, not when it is /freed/. Thus if you have a smart
pointer type (not the standard C++ smart pointers) which checks that its
wrapped pointer is non-null before any dereference, /then/ it may be
worth making the deletion or freeing of that smart pointer set its
wrapped pointer to 0. But as long as "*p" does not throw or otherwise
identify and handle error conditions, there is no benefit in having a
deletion set the pointer to 0.