Vicente Botet Escriba wrote:
Achilleas Margaritis-4 wrote:
Sid Sacek wrote:
It's the lack of a programming model that integrates destructors and peoples' legitimate expectations that they will be called to release non-memory resxources. What can you say about the non-memory resources owned by a GC'd object that contains, say, a mutex?
Personally, I don't see why resources like mutexes or files should be managed like memory. Resources like that are "binary" resources: they have two states (locked/unlocked, opened/closed), which is perfectly suited for RAII.
I think the question David was asking is; if a GC object is holding a mutex that is currently holding a lock, then when does that lock release, or how does that lock release? The GC may run in the future, and in the meanwhile, that lock is frozen.
Aren't scoped locks a better way to handle such issues? The big advantage of C++ is scoped construction/destruction.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,
The user can use already RAII on its application. Suppose that you have a RAII class X that is garbage collected (inherits from gc_object<X>) that holds a mutex (or a file handle) and lock (open) it on construction and unlock (close) on destruction.
How the following behaves?
scoped_ptr<X> p(nex X());
When the unlock (close) function will be called?
Does it means that classes like X should not inherit from gc_object<X> and the user of X must decide whether the new X() must be garbage collected or not?
What are the criteria X must satisfy to inherit from gc_object<X> without any trouble?
The GC RAII combination rises clearly some issues, and the user must be aware of them. The question is, what the GC library can provide to the user to make user life easier and safer.
HTH, Vicente
The gc'd objects can be deleted any time, and therefore RAII works on gc'd objects as well.