Re: Good idea or gimmick: Go-style OO-programming in C++ ?
On Feb 26, 3:58 pm, Stefan Ram wrote:
Tiib <oot...@hot.ee> writes:
I am firm follower of RAII idiom (last resource leak that I discovered
in my code was 8 years ago), so I can't help there much, I see currently
no purpose for GC whatsoever since RAII behaves more predictably
while being both as painless and as efficient as GC (but I admit that I
can be still wrong).
I'd like to read a book/chapter/article especially about
rules to follow to avoid memory errors (that is, both leaks
or invalid accesses) in C++, both for automatic and for
allocated storage. Maybe someone is aware of something like
this? (I am aware of some GotW questions about exception safety.)
I guess it can be summarized as "Appreciate RAII" where RAII refers to
the concept of delegating responsibilities (like resource management)
from yourself as a programmer to objects that either live in automatic
memory or are themselves managed by one or more other objects that
live in automatic memory or ... you get the idea. :) You can imagine a
graph which represents
these responsibility/ownership relations between objects/resources. It
should be acyclic and its roots should be objects living in automatic
memory. This means that there won't be any "owning raw pointers".
That's how you at least solve leaking issues.
Avoiding invalid accesses is about making sure that you don't use a
pointer (or reference) whose pointee ceased to exist. This is a bit
trickier I guess and I don't think that there is a general approach
that's applicable in every situation (even less so compared to RAII).
Holding on to a "non-owning" pointer might be perfectly reasonable in
some programs. Examples for "non-owning" pointers are raw pointers and
objects of type std::weak_ptr<T>. The nice thing about weak pointers
is that you can actually detect whether the pointee still exists or
not. But of course, this relies on the pointee being managed by a set
of std::shared_ptr objects which might be overkill in some cases. For
example, I would prefer std::unique_ptr over std::shared_ptr as an
"owning pointer". In probably most cases you don't really nead to
share ownership of a dynamically allocated object, so unique_ptr would
be sufficient. The downside obviously is that you don't get to check
whether this dynamically allocated object still exists if all you have
is a raw pointer.
In C, I can easily summarize. AFAIK
- Do not pass pointers to automatic storage upwards
(i.e., beyond its life time).
- Do not access pointers intended for dynamic storage
that
- do not point to memory obtained from a
successful call to malloc or equivalent
- already have been released by free or
equivalent
- For every successful malloc eventually there
should be exactly one corresponding free
(unless that is a short-lived program that will
terminate soon anyways)
But C does not have containers, exception, references,
smart pointers, ...
For C++ I would write:
- Learn about and appreciate RAII. This includes things like
- Prefer containers over hand-written "pointy" data structures.
- Don't use raw pointers and references for things you
would have to delete manually later.
- Use std::vector instead of new[]
- Whenever you feel the need to dynamically allocate something
stop for a minute and ask yourself whether there is a better
way.
- If you still feel the need to dynamically allocate stuff,
delegate the responsibility for its deletion to an object of
type unique_ptr or shared_ptr (or something like that).
- Keep in mind that if you feel the need to manually call
delete or delete[] you it's very likely that you did
something wrong.
- Don't access things that ceased to exist.
- shared_ptr/weak_ptr allows you to detect this for
dynamically allocated objects.
Perhaps it's a good idea to somehow replace unique_ptr<T> and T* with
shared_ptr<T> and weak_ptr<T> for the debug mode so that you can
terminate with an assert in case of a dangling pointer.
Cheers!
SG