-------- Original message --------
From: Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org>
Date: 8/24/25 7:35 PM (GMT+01:00)
To: std-proposals@lists.isocpp.org
Cc: Jason McKesson <jmckesson@gmail.com>
Subject: Re: [std-proposals] Delete...why not a parameter by reference?!
<std-proposals@lists.isocpp.org> wrote:
>
>
>
>
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: David Brown <david.brown@hesbynett.no>
> Date: 8/24/25 4:41 PM (GMT+01:00)
> To: organicoman <organicoman@yahoo.fr>, std-proposals@lists.isocpp.org
> 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.
If you start if'ing, about a function that belongs to library with a closed source, that's a big No No.
We want to be free of guess work.
We need minimal effort to stay correct.
The proposal is about protecting ourselves from unintentional mistakes.
I have a pointer and I want to pass it to a function:
There are 3 cases:
1- the function will own the lifetime
2- the function will not modify the pointee
3- the function will inspect the pointer
For the first case, pass by copy, and make your pointer variable a temporary
i.e
Dll_fn_takes_by_Copy (new T{})
Or
{
T* p = new T
Dll_fn_takes_by_Copy(p);
} // p dead here
2nd case pass by const&
Dll_fn_takes_by_const_ref(T* const&);
You will ensure that the pointer and the pointee are safe from any modifications.
3rd case, pass by reference
Dll_fn_takes_by_ref(T* &)
You will ensure that even if the pointee is modified, there is no accidental delete of the pointer. Why? Because the proposal says that delete expression takes by reference and nulls out the parameter.
So from a caller perspective, I give you a pointer and when I return from the callee I find it nullptr, that's a side-effect that your API doesn't respect its contract (either by mistake or intentionally)
It's a team work, with this proposal, we help library implementers to catch bugs.
> 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.
They won't change a blip.....observe that the call site won't change
delete(void*) => delete (void* &)
At call site
delete(p) => delete(p);
And that's the same for all other functions that take raw pointers....std::deallocate, construct....etc
ABI wise, Ahhh, yes it will hurt, unless compiler magician find a clever way.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals