Preventing delete

[Xavier Décoret]

Hi,

I long thought one could not delete a const pointer but the following
code compiles under g++ and visual net:

class Dummy
{
public:
Dummy() {}
~Dummy() {}
};

int main(int,char** )
{
const Dummy* const p = new Dummy();
delete p;

return 0;
}
The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

#include <iostream>
#include <string.h>

using namespace std;

class Invoice
{
public:
Invoice(char* label)
{
_label = strdup(label);
}
~Invoice()
{
delete [] _label;
}
const char* const label() const
{
return _label;
}
private:
char* _label;
};

int main(int,char** )
{
Invoice d("train");
delete [] d.label();

cout<<d.label() <<endl;

return 0;
}

[Pete C]

Xavier Décoret wrote:

The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

Make the destructor private or protected, and make the user call a
custom function that you supply to do the deleting.

[Gavin Deane]

Xavier Décoret wrote:

Hi,

I long thought one could not delete a const pointer but the following
code compiles under g++ and visual net:

class Dummy
{
public:
Dummy() {}
~Dummy() {}
};

int main(int,char** )
{
const Dummy* const p = new Dummy();
delete p;

return 0;
}
The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

#include <iostream>
#include <string.h>

using namespace std;

class Invoice
{
public:
Invoice(char* label)
{
_label = strdup(label);
}
~Invoice()
{
delete [] _label;
}
const char* const label() const
{
return _label;
}
private:
char* _label;
};

int main(int,char** )
{
Invoice d("train");
delete [] d.label();

cout<<d.label() <<endl;

return 0;
}

Are you asking purely out of academic interest? Because the real world
answer to that particular code is, for the class designer: "don't
expose the internals of your class like that" and for the client code:
"don't delete memory you don't own".

In other words, can you provide a more realistic example of the problem
you are trying to solve.

Gavin Deane

[Ben Pope]

Xavier Décoret wrote:

Hi,

I long thought one could not delete a const pointer but the following
code compiles under g++ and visual net:

class Dummy
{
public:
Dummy() {}
~Dummy() {}
};

int main(int,char** )
{
const Dummy* const p = new Dummy();
delete p;

return 0;
}
The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

Create your own type and override operator delete?

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

Pete C wrote:

Xavier Décoret wrote:

The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

Make the destructor private or protected, and make the user call a
custom function that you supply to do the deleting.

That works for your own types. The OP's code was deleting a pointer to
char. I don't know of anything you can do to a pointer to a built in
type that prevents it being deleted (apart from wrapping it in a
class).

Gavin Deane

[Xavier Décoret]

>

Are you asking purely out of academic interest? Because the real world
answer to that particular code is, for the class designer: "don't
expose the internals of your class like that" and for the client code:
"don't delete memory you don't own".

I don't buy this argument: encapsulation is meant to prevent tthe API
user to shoot himself in the foot. If you expect the programmer to be
intelligent, you do not need the const qualifier. Just trust the
programmer not to modify an object he is not allowed to ;-). And you do
not need smart pointers. Just trust the programmer to delete cleanly
every chunk of memory. And so on...

Regarding exposure of internal data, this happens all the time! Or your
class is generally useless. If you want a less academic example, just try:

#include <string>
#include <iostream>

using namespace std;

int main()
{
string s("foobar");

cout<<s<<endl;

delete [] s.c_str();

cout<<s<<endl;

return 0;
}

You cannot not do simpler. It is using a standard class (which is
developped by valuable people according to Scott Meyers ;-)). The class
must return pointer to raw data. Yet I can delete it and the above
program dumps in an unpleasant manner.

foobar
*** glibc detected *** ./a.out: free(): invalid pointer: 0x087041e4 ***
======= Backtrace: =========
/lib/libc.so.6[0x3fe124]
/lib/libc.so.6(__lib c_free+0x77)[0x3fe65f]
/usr/lib/libstdc++.so.6( _ZdlPv+0x21)[0x66b0a9]
/usr/lib/libstdc++.so.6( _ZdaPv+0x1d)[0x66b0f5]
../a.out(__gxx_per sonality_v0+0x1 a9)[0x8048909]
/lib/libc.so.6(__lib c_start_main+0x df)[0x3afd5f]
../a.out(__gxx_per sonality_v0+0x6 1)[0x80487c1]
======= Memory map: ========
0022d000-00247000 r-xp 00000000 08:01 655395 /lib/ld-2.3.5.so
00247000-00248000 r--p 00019000 08:01 655395 /lib/ld-2.3.5.so
00248000-00249000 rw-p 0001a000 08:01 655395 /lib/ld-2.3.5.so
0024d000-0024e000 r-xp 0024d000 00:00 0 [vdso]
00376000-00399000 r-xp 00000000 08:01 659189 /lib/libm-2.3.5.so
00399000-0039a000 r--p 00022000 08:01 659189 /lib/libm-2.3.5.so
0039a000-0039b000 rw-p 00023000 08:01 659189 /lib/libm-2.3.5.so
0039b000-004be000 r-xp 00000000 08:01 655494 /lib/libc-2.3.5.so
004be000-004c0000 r--p 00123000 08:01 655494 /lib/libc-2.3.5.so
004c0000-004c2000 rw-p 00125000 08:01 655494 /lib/libc-2.3.5.so
004c2000-004c4000 rw-p 004c2000 00:00 0
005a0000-005a9000 r-xp 00000000 08:01 659349
/lib/libgcc_s-4.0.2-20051126.so.1
005a9000-005aa000 rw-p 00009000 08:01 659349
/lib/libgcc_s-4.0.2-20051126.so.1
005c1000-00696000 r-xp 00000000 08:01 1717334 /usr/lib/libstdc++.so.6. 0.7
00696000-0069b000 rw-p 000d5000 08:01 1717334 /usr/lib/libstdc++.so.6. 0.7
0069b000-006a0000 rw-p 0069b000 00:00 0
08048000-08049000 r-xp 00000000 00:12 1945771
/home/artis/decoret/tmp/a.out
08049000-0804a000 rw-p 00000000 00:12 1945771
/home/artis/decoret/tmp/a.out
08704000-08725000 rw-p 08704000 00:00 0 [heap]
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f2a000-b7f2c000 rw-p b7f2a000 00:00 0
b7f45000-b7f47000 rw-p b7f45000 00:00 0
bf931000-bf947000 rw-p bf931000 00:00 0 [stack]
Abort

In other words, can you provide a more realistic example of the problem
you are trying to solve.

Gavin Deane

[Xavier Décoret]

Gavin Deane wrote:

Pete C wrote:

Xavier Décoret wrote:

The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

Make the destructor private or protected, and make the user call a
custom function that you supply to do the deleting.

That works for your own types. The OP's code was deleting a pointer to
char. I don't know of anything you can do to a pointer to a built in
type that prevents it being deleted (apart from wrapping it in a
class).

Gavin Deane

Yep. The Invoice dummy example is also deleting a const pointer on a
custom type, so it is not a problem of builtin types.

[Xavier Décoret]

Xavier Décoret wrote:

Hi,

I long thought one could not delete a const pointer but the following
code compiles under g++ and visual net:

class Dummy
{
public:
Dummy() {}
~Dummy() {}
};

int main(int,char** )
{
const Dummy* const p = new Dummy();
delete p;

return 0;
}
The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?

BTW, this seems a recurring question:

http://www.codecomments.com/C_Modura...e719344-1.html

The important point is "how to control what the users do with pointer".
The const qualifier prevents him to modify it but not to delete it.

[Michiel.Salters]

Xavier Décoret wrote:

Hi,

I long thought one could not delete a const pointer but the following
code compiles under g++ and visual net:
Sure you can. You can't assign a new value, or null, but delete doesn't
actually change the pointer value. (Or do you mean a pointer-to-const,
which is another beast?)
class Dummy
{
public:
Dummy() {}
~Dummy() {}
};

int main(int,char** )
{
const Dummy* const p = new Dummy();
delete p;
}
Const pointer to const Dummy, but obviously you can delete it.
p doesn't change, nor does *p. The end of a lifetime doesn't count
as a change, just like the beginning doesn't. There are no const
ctors or dtors, either.

The question is: how can I forbid the user to delete some data I an
handling a pointer to? Here is an example of code that does compile but
will lead to segfault. How can I prevent it?
You can't. The user can always do stupid things like 'delete new
Dummy[2];'
Point is, the users we're talking about are programmers. They're smart
enough to read the manual, at least in theory.
#include <iostream>
#include <string.h>

using namespace std;

class Invoice
{
public:
Invoice(char* label)
{
_label = strdup(label);
}
~Invoice()
{
delete [] _label;
}
const char* const label() const
{
return _label;
}
private:
char* _label;
};
Whoa. Programmers are supposed to read the manual, remember?
That includes you. strdup isn't standard C++. All implementations
I know require you to use free(). I bet yours does as well. However,
I don't suggest you change that. Read on instead.
int main(int,char** )
{
Invoice d("train");
delete [] d.label();

cout<<d.label() <<endl;

return 0;
}

That should trigger a warning or two. Invoice::Invoic e takes a
non-const char*
but "train" is definitely a const literal.

The solution is of course very simple: don't mix C and C++ like you do.
Drop
<string.h> and use <string>. Invoice::Invoic e should take a std::string
const&.
label() should return a string const&. The data member should be a
std::string.
Drop all strdup()s, free()s, delete[]s and just assign strings like
they're ints.

As a bonus, performance may even increase.

HTH,
Michiel Salters

[Gavin Deane]

Xavier Décoret wrote:

Are you asking purely out of academic interest? Because the real world
answer to that particular code is, for the class designer: "don't
expose the internals of your class like that" and for the client code:
"don't delete memory you don't own".

I don't buy this argument: encapsulation is meant to prevent tthe API
user to shoot himself in the foot. If you expect the programmer to be
intelligent, you do not need the const qualifier. Just trust the
programmer not to modify an object he is not allowed to ;-).

There's a difference between shooting yourself in the foot by accident
because your gun (API) doesn't have a safety catch (const) and shooting
yourself in the face because you have no idea how a gun works or what
you can do with it (are prone to passing things to delete just because
they are pointers to dynamically allocated memory).
And you do
not need smart pointers. Just trust the programmer to delete cleanly
every chunk of memory. And so on...
But the code to manage that memory in an exception safe manner is more
complicated without smart pointers. A competent C++ programmer could
still write it but it would take longer, be harder to read and be
harder to modify correctly. That's what smart pointers are for.
Regarding exposure of internal data, this happens all the time! Or your
class is generally useless. If you want a less academic example, just try:
OK, fair enough.
#include <string>
#include <iostream>

using namespace std;

int main()
{
string s("foobar");

cout<<s<<endl;

delete [] s.c_str();
That's still an academic example because no C++ programmer who knows
anything about C++ programming would ever do that. If you've got
developers around who do that sort of thing, no amount tightening the
restrictions imposed by your API is going to turn them into competent
programmers. They'll still produce garbage.
cout<<s<<endl;

return 0;
}

You cannot not do simpler. It is using a standard class (which is
developped by valuable people according to Scott Meyers ;-)). The class
must return pointer to raw data. Yet I can delete it and the above
program dumps in an unpleasant manner.

std::string doesn't prevent you from writing code like this. So who is
at fault? Scott Meyers's valuable people for writing a fragile API, or
you for doing something stupid?

Gavin Deane