On Sun, Aug 24, 2025 at 12:21 PM organicoman via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
>
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: David Brown <david.brown_at_[hidden]>
> Date: 8/24/25 4:41 PM (GMT+01:00)
> To: organicoman <organicoman_at_[hidden]>, std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Delete...why not a parameter by reference?!
>
>
>
> On 24/08/2025 16:41, organicoman wrote:
> >
> >
> >> 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.
> >
> > Yes true, but atleast you can check if a delete was called on your
> > pointer, then you can do this:
> >
> > if (m_ptr) // if false then definitely deleted.
> >
>
> Anyone who is able to check their pointers before use, is equally able
> to assign 0 to deleted pointers.
>
> {
> T* p = new T;
> Dll_fn_takes_by_Copy (p);
> delete p;
> }
>
> Show me how.

If `Dll_fn_takes_by_Copy` maintains a copy of that pointer, then
there's an ownership problem. Either the caller is not correctly
managing the lifetime of `p`, or `Dll_fn_takes_by_Copy` is improperly
storing a pointer that it shouldn't.

Also, if `Dll_fn_takes_by_Copy` is actually storing the pointer, they
will not store a *refernce* to a pointer, even if that function takes
the pointer by reference.

> A language change only helps people avoid mistakes if it does so
> automatically or with significantly greater convenience than they
> already have. Your suggestion only helps people who are careful in
> their coding, and those people are already careful and don't make the
> mistakes that your change could prevent.
>
> If you want to help less careful programmers avoid mistakes, campaign
> for std::unique_ptr and friends to have validity checking on
> dereference, throwing exceptions on null pointers. (The campaign
> wouldn't work because people don't want that extra overhead.)
>
> I understand why everyone is on the defensive, and I agree totally that we should not obstruct the smart pointer campaign.
>
> But library implemented and low level will definitely use raw pointers....just show me how many std::vector implementation uses smart pointers for its internal data pointer.

Well, they're certainly not going to start taking *references* to raw
pointers. And your proposal doesn't actually work unless everyone
spontaneously does that. If you're going to make everyone update their
code, maybe make them do it to a good answer.