Is it possible to prevent `delete` on a `const *`?

[JonB]

@SGaist said in Is it possible to prevent `delete` on a `const *`?:

declaring the delete operator of your class private or protected

Ohh, I didn't even know delete was an operator and you can override it.

@JoeCFD
Yes, you are right about * const ptr, that just affects its value. I wish delete ptr set ptr to nullptr, then I would not be allowed to delete *const ptr which would suit me :)

[JonB]

There is still one concept I don't uderstand. I got side-tracked with the second const, forget that.

const Foo *foo = somefunc();

• I can't go foo->something = somewhat because error const/read-only, perfect.

• But I can go delete foo (given a standard delete). Why? delete frees the memory used by the object. That's just as destructive as assigning into it. If I need a non-const pointer for write access why don't I need that to delete too?

[Chris Kawa]

You could look at constructors and destructors as "special" functions that follow slightly different set of rules than other member functions. For example did you know that delete operator is the only static member function in C++ that is called polymorphically?

You could have a philosophical take on it by saying that accessing a regular mutating member is different operation than deallocating an object as a whole, but then there's the issue of mutating destructors. You could give it a pragmatic explanation that disallowing destruction through pointer to const could lead to a situation where there's no way to delete an object without a const_cast if all you have are just pointers to const. That would be fugly. You could take a C style explanation that it just deals with memory and not access, but then there are destructors...

It is what it is is what I'm trying to say. One of the many quirks of a complicated language :)

[SimonSchroeder]

@JoeCFD said in Is it possible to prevent `delete` on a `const *`?:

1. can call only const funcs

delete does not only delete the contents something points to. It also calls the destructor of the underlying object. So, there is an inconsistency that I can call the destructor on a const object (which I never noticed in my long C++ career).

Best advice is to not use plain owning pointers in C++. But, that would still leave you with the convention to use raw pointers as non-owning pointers with the technical possibility that someone calls delete on them. Making the delete operator private works to suppress this, but is also really intrusive to be of general use.

[JonB]

@SimonSchroeder said in Is it possible to prevent `delete` on a `const *`?:

It also calls the destructor of the underlying object. So, there is an inconsistency that I can call the destructor on a const object (which I never noticed in my long C++ career).

Exactly! I am "surprised" that you have never "noticed" this, as I most certainly have, and is precisely why I am so shocked it is allowed! :) I am finding this whole "you cannot change the object via const * but feel free to completely clobber it by deleting" very odd!

[jsulm]

@JonB said in Is it possible to prevent `delete` on a `const *`?:

I am finding this whole "you cannot change the object via const * but feel free to completely clobber it by deleting" very odd!

Else, you would not be able to free the memory

[J.Hilk]

@JonB said in Is it possible to prevent `delete` on a `const *`?:

I am finding this whole "you cannot change the object via const * but feel free to completely clobber it by deleting" very odd!

freeing an objects memory is very much different from changing its internal state. const only prohibits the later

[JonB]

@J-Hilk said in Is it possible to prevent `delete` on a `const *`?:

freeing an objects memory is very much different from changing its internal state. const only prohibits the later

Well it may be "different" but it is equally "destructive". And ends up "changing its internal state" as a consequence. Hence the discussion. I now get that "const only prohibits the later", and that's life, but I still find it "odd".

[SimonSchroeder]

I was just thinking about this: Is it possible to overload the delete operator with a const and non-const version?

[JonB]

@SimonSchroeder
So for my case that would do what, presumably runtime error? I was looking for a compile-time error on attempting to delete a const pointer (like I would get on attempting to write to a member/call a non-const member method).

[J.Hilk]

@JonB make yourself a delete macro, that calls delete and setzt the pointer to nullptr :D

[JonB]

@J-Hilk My badly-behaved fellow programmers can/will call delete directly, and I want them to fall over at compile time as per trying to write into the const pointer!

[SimonSchroeder]

@JonB said in Is it possible to prevent `delete` on a `const *`?:

So for my case that would do what, presumably runtime error?

If you can distinguish that, you could make the const-version private and the non-const public. So, you can still normally delete objects when you are allowed to (with a pointer to non-const). But I'm not sure if this distinction is possible.

[Chris Kawa]

@SimonSchroeder said:

But I'm not sure if this distinction is possible

It's not. The delete operator can't be cv qualified.

Here's a fun quirk:

struct Foo {
    void itIsFine() const { delete this; }
    ~Foo() {  bar = 42; }
    int bar = 0;
};

const Foo* foo = new Foo();
foo->itIsFine();

so not only can you delete an object through a pointer to const, but a const function can mutate the object without mutable or const_cast by deleting the object it is being called on;)