Re: Raw pointers not evil after all?
On 5/1/2013 2:19 AM, mike3 wrote:
Hi.
I saw this:
http://stackoverflow.com/questions/4252273/should-i-use-smart-pointers-on-everything-and-forget-about-classic-normal-pointe
--
"You should use smart pointers careful. They are not the silver bullet
when considering memory management. Circular references are still an
issue.
When making the class design, always think who has the ownership of an
object (has the responsibility to destroy that object). Complement
that with smart pointers, if necessary, but don't forget about the
ownership."
--
And another thing that once seemed clear is now not so clear. What is
"careful" -- what is one to watch out for?
And does this mean that in many cases (it says "smart pointers, *if
necessary*", suggesting there's a good chance they aren't
"necessary"), the "owning object" should use a raw pointer? Yet I've
heard raw pointers are "evil".
So what is it?
And then I see this:
http://stackoverflow.com/questions/417481/pointers-smart-pointers-or-shared-pointers
--
"Although "never" isn't entirely accurate. If you're implementing a
smart pointer you need to use raw pointers. Outside of that special
case you're much better off using the smart versions." (a comment on
one of the answers)
--
"much better off using the smart versions"... whereas the "use them
carefully" to me implies "sparingly". Or am I wrong, and they should
be used frequently, but the care is in _how_ you use them, not _how
many_ or _how often_?
Consider this illustration snippet:
class Owner {
private:
std::vector<Owned *> owns;
public:
...
~Owner();
void addSomething(Owned *);
};
...
~Owner()
{
for(std::vector<Owner *>::iterator it(owns.begin()); it !=
owns.end(); ++it)
delete (*it);
}
void Owner::addSomething(Owned *smth)
{
owns.push_back(smth);
}
void f()
{
Owner oneOwner, twoOwners;
Owned *smthToOwn = new Owned;
oneOwner.addSomething(smthToOwn); // BUT WAIT! The pointer to
smthToOwn is still in f()!
twoOwners.addSomething(smthToOwn); // FATAL!
}
What I notice is this:
1. Only one Owner can own a given Owned. Yet with a raw pointer,
there's nothing to stop us from putting it into two Owners, causing a
fatal crash when both are destroyed. Now, one could say "well then
just don't do that", but shouldn't that be enforced by code and not
just the user's understanding?
2. This concern suggests to use auto_ptr or something like it. But
auto_ptr is attacked on the same website. And technically, the
auto_ptr owns the object, not the Owner. It seems the only way Owner
can directly own the object is with an _EVIL_ raw pointer.
So what to do?
Be a good programmer and use what is appropriate for the task rather
than trying to form a general rule and expect magical results. I use raw
pointers, shared_ptrs, weak_ptrs, and auto_ptrs in my code.
My experience has been that teams that use raw pointers entirely have
memory leak bugs, teams that use smart pointers entirely have memory
leaks due to cyclical references. Many software houses have adopted an
very ignorant philosophy of "If we make everything a shared pointer,
than nothing will leak!" and it is completely false.
Use RAII. Try your best to make sure anything that is allocated is
"owned". Something can indeed be owned AND shared. You should never find
yourself debugging code and left wondering "Who allocated this? Who is
releasing it?", "When is it getting release?" It should be obvious by
the design, not something you have to spend a day reverse engineering.
None of these are "evil", the programmer whom misuses them is evil.
I won't go too in depth with examples, but I will clarify auto_ptr, in
that the situation where I use auto_ptr is when I have a method that
_must_ allocate its result to be returned to the caller. Such a
situation is where I have a method
ISomeAbstractInterface DoSomething(x,y,z);
You have no choice, AFAIK, but to new MyConcreteInterface and return it.
You don't want to return a raw pointer, because no one will own it and
it isn't obvious to the caller that you allocated something that needs
to be released. Thus you return an auto_ptr, which forces the caller to
take ownership, because the returned object is going to be released when
it goes out of scope.