On Fri, Aug 22, 2025 at 10:25 PM organicoman <organicoman_at_[hidden]> wrote:
> > The current guideline is to use std::unique_ptr or other smart
> > pointer, and not raw pointers. So by that argument we have already
> > achieved what you appear to be trying to do by having a guideline.
>
> Smart pointers don't suffer, use after free or double free problems, so obviously I'm talking about low level code dealing with raw pointers.

Really?

void somefn() {
    auto ptr = std::make_unique(5);
    auto ptr2 = std::unique_ptr<int>(ptr.get()); // Maybe this should
have been .release() ?
}

Double-free using smart pointers. Sure, I had to work at it (or used
the wrong member function), but it's possible.

> > I didn't say that the originating pointer is deleted/freed, I said its
> > lifetime ends. The pointer, not what it's pointing at.
> >

> > ... example with arbitrary class receiving a pointer to a dynamically allocated object ...

> >

> > ... example how this breaks even std::unique_ptr ...

> You are mixing between raw pointers usage and smart pointers usage.

No, I'm implementing a smart pointer which breaks almost immediately
upon construction, and breaks further if one attempts to move it, or
even dereference it. Assuming the guideline is being used.

> Passing by copy, creates resources ownership confusion.
> Passing the pointer variable by reference imposes on it to outlive all the references, but at the same time, if any of these variables is a parameter to the delete operator, then it's guaranteed to become nullptr as per the proposal, so no false ownership.
> that's the guideline purpose.

Which breaks things. You don't get to hand-wave away the carnage
that the guideline imposes. ("Why can't I drive through red lights?"
"Because there exists cross-traffic". "Yeah, ignore that.")

> Let's forget the passing by reference thing....just focus on the delete operator which nullify it's pointer parameter. I don't see why it is not the standard..

So throw away the part of the proposal that (if it didn't break things
along the way) was supposed to address the truly useful part (also
assuming that dereferencing nullptr were defined behaviour)? OK:

If we're focusing on just having the delete operator able to set its
argument to nullptr: it doesn't address the plethora of other copies
of the pointer still pointing at now released memory, and those are
the cases that are harder for the compiler and other static analyzers
to detect. I'm not seeing the value in imposing a dead write (in
well-defined C++ programs) on every delete call. The folk who are
doing the "low level code" (and who can tolerate the use of dynamic
memory in some form) are also the folk who are quite sensitive to
extra operations.