Prevent delete on pointer in C++

Question

Is there any way to prevent deleting a pointer in C++ by its declaration?

I've tried following code without luck.

const int* const foo()
{
    static int a;
    return &a;
}

int main()
{
    const int* const a = foo();

    *a = 1;   //compiler error, const int*
    a++;      //compiler error, int* const
    delete a; //no compiler error, I want to have compiler error here

    return 0;
}

Good question, +1, but I'm pretty sure, this is not possible (unless you use some wrapper/smart pointer) — Kiril Kirov, Aug 08 '12 at 14:03
`delete` doesn't modify the value of the pointer, so using `const` will not help. — obataku, Aug 08 '12 at 14:03
but i thought that it was the memory area/array deleted. not the pointer. dont you need to equate your pointer to NULL after deleting? — huseyin tugrul buyukisik, Aug 08 '12 at 14:03
You don't *have* to, no -- but setting it to `NULL` will help prevent prevent you from keeping and attempting to use [dangling pointers](http://en.wikipedia.org/wiki/Dangling_pointer). — obataku, Aug 08 '12 at 14:05
@tuğrulbüyükışık this is the usual way, but is not a "must" — Mircea Ispas, Aug 08 '12 at 14:05
@PaulManta I don't want to free the memory, this is the point. The pointer is pointing to a static variable. — Mircea Ispas, Aug 08 '12 at 14:09
@Felics I see, but then why not expose it through a reference or an `std::reference_wrapper`? — Paul Manta, Aug 08 '12 at 14:15
@PaulManta I don't want to "solve the problem", I just want to know if this is possible. — Mircea Ispas, Aug 08 '12 at 14:17
No. Returning a reference would be a good signal that you don't want the object deleted. — Bo Persson, Aug 08 '12 at 14:25

score 39 · Accepted Answer · edited May 23 '17 at 11:54

39

You cannot declare a pointer to an arbitrary type in a way which prevents calling delete on the pointer. Deleting a pointer to const (T const*) explains why that is.

If it was a pointer to a custom class you could make the delete operator private:

class C {
    void operator delete( void * ) {}
};

int main() {
    C *c;
    delete c; // Compile error here - C::operator delete is private!
}

You certainly shouldn't make the destructor private (as suggested by others) since it would avoid creating objects on the stack, too:

class C {
    ~C() {}
};

int main() {
    C c; // Compile error here - C::~C is private!
}

edited May 23 '17 at 11:54

Community

1
1

answered Aug 08 '12 at 14:11

Frerich Raabe

90,689
19
115
207

Protected delete makes more sense in some situations too. – Michael Anderson Aug 08 '12 at 14:13
my thought as well: we use classes to encapsulate data (and define valid operations). – default Aug 08 '12 at 14:13
What about overriding delete global and perform some checks before actually freeing the memory? – Heisenbug Aug 08 '12 at 14:15
2

Should you also make operator new private/protected too - so you can't leak values on the heap? – Michael Anderson Aug 08 '12 at 14:21
@Heisenbug - That wont give you a compile time error, and so is not as useful. – Michael Anderson Aug 08 '12 at 14:21
3

@MichaelAnderson: The objects wouldn't necessarily leak: the object could `delete this`, or expose the `delete` functionality via some other method (say, a public `release` method or so). – Frerich Raabe Aug 08 '12 at 14:23
@FrerichRaabe You're correct, however I'd find it odd to allocate with new, but destroy via some other method. I'd probably create a static `create()` function instead. – Michael Anderson Aug 08 '12 at 14:25

Michael Anderson · Answer 2 · 2012-08-08T14:28:06.390

Simple answer is no. There is no way to prevent delete from being called on a pointer to built-in type.

ADDENDUM:

However I've run into similar situations to this .. my soltion was to stop using a normal pointer, and thus not need to worry about deletion. In my case a shared pointer made sense, but it yours a unique pointer or similar may suffice.

//Custom do nothing deleter.
template<typename T> dont_delete( T* ) { /* Do Nothing */ }

shared_ptr<const int> const foo()
{
  static int a;
  return shared_ptr<const int>(&a, &dont_delete<const int> );
}

shared_ptr<const int> const bar()
{
  return shared_ptr<const int>(new int(7) );
}

main()
{
   shared_ptr<const int> p1 = foo();
   shared_ptr<const int> p2 = bar();

   //p1s data _not_ deleted here, 
   //p2s data is deleted here
}

score 1 · Answer 3 · answered Aug 08 '12 at 14:18

I don't fully understand what you are asking. If you want an object that can't be deleted you can try making foo a class and make the destructor private.

class Foo {
public:
   int a;

   Foo(int v) {
       a = b;
   }

private:
   ~Foo() { }
};

int main() {

    Foo *c = new Foo(1);

    delete c; // compiler error, ~Foo() is private

    return 0;
}

I made variable "a" public since it was originally defined as a struct, but you can (and should) make it private and make accessors that enforce the access rules you wanted in your original code example.

This isn't foolproof and the compiler will only catch direct references to that class.

That way you can't even create Foos on the stack. – mfontanini Aug 08 '12 at 14:39 — mfontanini, Aug 08 '12 at 14:39

score 0 · Answer 4 · answered Oct 23 '14 at 10:35

I think what he means is accidental object deletion (whether delete o or free(o)) from happening which can result in a program crash. There really is no way around this with object allocated on the heap; as far as on the stack pointers we all know that it can't happen. Use protected dtor in top level classes is an option but then you are having to call on it in the child class dtor.

One solution (even though override the delete operator is on the table) is to use a table mapping system which returns an id/token/what-have-you but this really only works in your are writing in CSTYLE code and compiling in C conventions. The pro of doing this is hidden the object pointers from the user allow the user to pass in the token which in mapped to the object. This takes work and experience to do.

I wouldn't even worried about it because most experience and wise programmers read up on the API's documentation to avoid this mishaps. If nether wise or experience, well, I don't what to say then.

score 0 · Answer 5 · answered May 27 '16 at 15:18

You can prevent the usage of delete operator on pointer of certain classes. For example:

class Object {
public: void operator delete(void* p) = delete;
};

class Entity : public Object {    };

int main(int argc, char const *argv[])
{
    Object* o = new Object;
    Entity* e = new Entity;

    delete o; // compiler error
    delete e; // compiler error

    return 0;
}

For all classes that inherit from Object can not be deleted because the Object::operator delete was deleted. Don't mark this operator as private because it will give a compiler error when deriving or instantiating the Object class. Be aware that we can still do so:

::operator delete(o);

Which will free the o pointer but won't call the destructor. Use a class to manager the life time of the Object class. A simple implementation would be:

class Object {
    template<typename type> friend class ptr;
    public: void operator delete(void* p) = delete;
};

class Entity : public Object { };

template<typename type>
class Ptr {
public:
    Ptr(type* obj) : o(obj){}
    ~Ptr() { o->~type(); ::operator delete(o); }
private: type* o;
};

int main(int argc, char const *argv[])
{
    Object* o = new Object;
    Entity* e = new Entity;

    // delete o;  // error
    // delete e;  // error

    Ptr<Entity> ent = new Entity; // Ptr will delete ent for you.

    return 0;
}

Prevent delete on pointer in C++

5 Answers5