Re: Factories, handles, and handle wrappers
On Dec 18, 12:01 am, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
On 17/12/09 21:42, Paavo Helde wrote:
Maxim Yegorushkin<maxim.yegorush...@gmail.com> wrote in
news:4b2a898e$0$9753$6e1ede2f@read.cnntp.org:
[...]
I remember there was a long thread about garbage collection in C++
and IIRC the outcome was that the garbage collector should release
the memory, but should not invoke any destructors, in order to avoid
non-deterministic behavior (postponing the destructor call forever
is considered deterministic).
Yes.
One could consider it a fundamental problem in C++, that memory
managment is linked to destruction. On the other hand, C++ does have
mechanisms which can be used to automatically trigger destruction in
certain cases (on stack objects, in particular), which can be
particularly useful in those cases where they're applicable.
It probably depends on one's definition of deterministic.
Deterministic means that it happens at a specific, well determined
point
in the program logic. (At meta-levels, everything is deterministic,
since the computer is nothing other than a large finite statement
machine. And at an even higher level, quantum physics mean that
nothing
is deterministics. Neither of these levels are of any practical
consideration when trying to develop working software, however.)
I think the major source of determinism in C++ is the scoped resource
management based on destructors (RAII).
The destruction of variables defined at local scope is deterministic.
And an incredibly powerful and useful idiom. std::shared_ptr does
provide deterministic destruction *IF* (and only if) there is only one
pointer to the object, and that pointer is defined at local scope.
Generally, however, such cases are better handled by not using a
pointer
at all, or by using auto_ptr.
IMO, it is more powerful and general mechanism applicable to pretty
much any type of resource (memory, mutexes, locks, connections, etc..)
More than just resources. It supports full transactional semantics.
rather than garbage collection limited to one type of resource which
is memory and a ridiculous prehistoric try/finally construct for
anything else.
The difference is simple: destructors are only automatically called on
local objects, which have a lifetime defined by the language. For
dynamically allocated objects, whose lifetime depends on external
events, they must be called explicitly. Calling a destructor ends the
object's lifetime.
Garbage collection addresses a completely different issue. It ensures
that the memory for an object will not be reused as long as there are
any pointers to that object, *even* if the object's lifetime has
ended.
It's really necessary for safety reasons: with garbage collection, you
can mark a object as dead in its destructor, and verify that it is not
dead in all member functions. When memory management is linked to the
lifetime of the object, you always run the risk of recycling the
memory
of a dead object while there are still pointers to it, with the result
that using the pointer will access a different object. (This
represents
a serious security hole on systems which are openly accessible, such
as
web servers.)
--
James Kanze