How far should I go in protecting the user from his stupidity?

[Roman Werpachowski]

In a recent thread http://tinyurl.com/8n7fe I asked about preventing
the user from deleting the object pointed to by a pointer/reference.
Now I would like to ask about a different aspect of this thing: it this
protection worth it? It is fairly obvious that deleting an object you
will need in the future is wrong. So is it worth to bother with
protecting it against deletion?

 

[=?ISO-8859-2?Q?Ali_=C7ehreli?=]

In a recent thread http://tinyurl.com/8n7fe I asked about preventing
the user from deleting the object pointed to by a pointer/reference.
Now I would like to ask about a different aspect of this thing: it this
protection worth it?

No it is not worth that level of protection. Who are these users deleting
stuff! They can always do this too:

int i = 0;
delete &i;

It is fairly obvious that deleting an object you
will need in the future is wrong. So is it worth to bother with
protecting it against deletion?

Don't delete anything explicitly anyway... Always use an apropriate smart
pointer to define the lifetime of dynamic objects.

For example, when it comes to communicating the transfer of ownership, pass
or return std::auto_ptr objects by value. That way, there is no question of
whether the user should delete or not.

Ali

 

[roberts.noah]

In a recent thread http://tinyurl.com/8n7fe I asked about preventing
the user from deleting the object pointed to by a pointer/reference.
Now I would like to ask about a different aspect of this thing: it this
protection worth it? It is fairly obvious that deleting an object you
will need in the future is wrong. So is it worth to bother with
protecting it against deletion?

As has already been stated the return of a pointer has many problems.
The fact that they can do bad things with your internal pointer is just
one. The problem of object ownership becomes a real issue when
returning pointers - just who is going to delete the thing? What is
its lifetime? Can I depend on it to be a certain value consistently or
is it going to change the next time that function is called (for
instance C functions that returned char* often were implemented with a
static array that would get altered any time that function was
called)...

So really your issue goes beyond "just" protection from callers. I do
disagree with the other answer in that I think that alone is reason
enough to look for an alternative, but there are certainly several
other problems with returning a pointer. Obviously nothing that cannot
be worked with for programmers have been returning pointers for years,
but it just adds to the burden of coding in an unnecissary way....best
to avoid any possible problems if possible.

Had a little "argument" with a coworker about something similar today.
I prefer to keep things as safe as possible without going overboard.
Having exposed pointers is one of those things I really like to avoid
and will spend a little bit of time looking for an alternative if I
find I think I need to do that...most often I find a better way. If a
user can cause you to crash I think that is bad.

Today's argument was about a vector inside of a struct. The struct is
public and so its internal vector is as well. Things were getting
weird and an idea given to me was to make that vector a pointer. I
explained that I didn't like this idea because someone can delete it or
point it to someplace bad. Of course he "would never do that" but I
still don't like leaving that posibility open - I would then feel the
need to check that pointer any time it is accessed, at least with a
debug wrapped assert(). Now, an empty vector is no issue - I just end
up not doing anything - so the exposed vector is "ok"...but I didn't
want to do the same with a pointer....and I ended up solving the
problem in a more robust and elegant manner.

IMHO it is not silly to protect your class from users doing stupid
things - quite often that user will end up being you and the time spent
debugging may far outweigh the time looking for a method of
encapsulation.

 

[Guest]

IMHO it is not silly to protect your class from users doing stupid
things - quite often that user will end up being you and the time spent
debugging may far outweigh the time looking for a method of
encapsulation.

Definitely, I agree with you.
Recently, I encountered interesting "idea of arena".
As I understand from following article "arena" seems to solve
some of problems related to ownership and lifetime of objects:

http://www.cuj.com/documents/s=7990/cujcexp1910austern/

Here also Bjarne considers this idea:
http://public.research.att.com/~bs/bs_faq2.html#placement-delete


Cheers

 

[roberts.noah]

Definitely, I agree with you.
Recently, I encountered interesting "idea of arena".

Looks like the NSAutoreleasePool from objective-c. In objective-c all
objects are created on the heap. Returning an object is necessary but
is equivelant to returning TYPE* all the time. So one creates the
object and calls autorelease just before returning it, which places the
object on the release pool's stack for deletion. When the pool gets
deleted it destroys everything in it. To keep an object you call
retain, which increments a counter inside the object that tells it not
to go away when release is called. New release pools get placed in the
current pool's stack so deleting one previous destroyes those created
after...

There are some simple rules to follow when using a system like
this...namely that the object is your responsibility when you call an
alloc or retain. You relinquish your part by calling autorelease and
placing the object in the current pool. It works pretty well when the
rules of object ownership are followed.

 

[Jim Langston]

In a recent thread http://tinyurl.com/8n7fe I asked about preventing
the user from deleting the object pointed to by a pointer/reference.
Now I would like to ask about a different aspect of this thing: it this
protection worth it? It is fairly obvious that deleting an object you
will need in the future is wrong. So is it worth to bother with
protecting it against deletion?

As soon as you come up with idiot proof code, they'll come up with a better
idiot.

 

[Markus Becker]

As soon as you come up with idiot proof code, they'll come up with a better
idiot.

Or only idiots will want to use it.

Markus