www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About RAII and GC...?

reply Nick Sabalausky <a a.a> writes:
Maybe I'm misunderstanding things, but if you use RAII wherever appropriate,
wouldn't that eliminate the need for garbage collection? Is there something I'm
missing here?
Jul 30 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky Wrote:


 Maybe I'm misunderstanding things, but if you use RAII wherever appropriate,
wouldn't that eliminate the need for garbage collection? Is there something I'm
missing here?


If the only resource you're acquiring at construction is memory (90% of cases),
you can just use the GC instead. Also, the GC isn't necessarily incompatible
with RAII -- if there's some resource you don't need to release as soon as
possible, the GC will run the destructor on its own.
Jul 30 2007
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:f8m283$2q9b$1 digitalmars.com...

 Nick Sabalausky Wrote:


 Maybe I'm misunderstanding things, but if you use RAII wherever 
 appropriate, wouldn't that eliminate the need for garbage collection? Is 
 there something I'm missing here?


 If the only resource you're acquiring at construction is memory (90% of 
 cases), you can just use the GC instead. Also, the GC isn't necessarily 
 incompatible with RAII -- if there's some resource you don't need to 
 release as soon as possible, the GC will run the destructor on its own.


That's not exactly what I'm asking. I'll explain:

As we know, the reason for having garbage collection is that when using 
malloc/new there's a general tendency to forget the occasional free/delete 
(or end up with an exectution path that accidentially omits it), thus 
causing memory leaks. GC, of course, fixes that by saying "Don't worry about 
freeing, I'll clean up after you".

Now, maybe I'm misunderstanding RAII, but as I understand it, RAII 
guarantees that allocated memory (or whatever resource) gets freed 
automatically whenever the owning object goes out of scope.

So that seems to indicate to me that RAII is not only more general than GC 
(ie, can work for more than just memory) but also lacks any overhead of 
having a GC (aside from the usual overhead of freeing a resource). Thus, 
RAII can effectively replace the use of a GC.

Of course, with RAII you still need to manually release resources (right?), 
but you only need to do it in the destructor (right?). And this is vastly 
easier to not screw up than having "new"s and "delete"s all over the place.

So, does my analysis of this make sense, or am I off-base?
Jul 30 2007
parent Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:
Nick Sabalausky wrote:



 Now, maybe I'm misunderstanding RAII, but as I understand it, RAII
 guarantees that allocated memory (or whatever resource) gets freed
 automatically whenever the owning object goes out of scope.
 
 So that seems to indicate to me that RAII is not only more general than GC
 (ie, can work for more than just memory) but also lacks any overhead of
 having a GC (aside from the usual overhead of freeing a resource). Thus,
 RAII can effectively replace the use of a GC.


You are probably right. If absolutely all variables (with references types)
is declared with scope, then  they will be destroyed explicitly and GC will
have  probably nothing to do. But you will need to write allocators for this
types of variables, because compiler will use GC allocator (but will free
memory explicitly like with delete) if not.
Jul 31 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:f8m0fq$2ogm$1 digitalmars.com...

 Maybe I'm misunderstanding things, but if you use RAII wherever 
 appropriate, wouldn't that eliminate the need for garbage collection? Is 
 there something I'm missing here?


Go ahead and program your entire program without persisting any state 
outside the program execution stack.  Let us know how it goes ;)

Basically RAII only works for local function variables.  If you want the 
lifetime of an object to be controlled by something other than the execution 
time of a function, that's what the GC is for.

Although I wonder how much the GC could be helped by means of a new kind of 
object lifetime control, where the lifetime of one object is controlled by 
the lifetime of another.  Collecting the "parent" object would cause the 
"child" object to be collected, and the child couldn't be collectable until 
the parent object was.
Jul 30 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Jarrett Billingsley wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:f8m0fq$2ogm$1 digitalmars.com...

 Maybe I'm misunderstanding things, but if you use RAII wherever 
 appropriate, wouldn't that eliminate the need for garbage collection? Is 
 there something I'm missing here?


 
 Go ahead and program your entire program without persisting any state 
 outside the program execution stack.  Let us know how it goes ;)
 
 Basically RAII only works for local function variables.  If you want the 
 lifetime of an object to be controlled by something other than the execution 
 time of a function, that's what the GC is for.
 
 Although I wonder how much the GC could be helped by means of a new kind of 
 object lifetime control, where the lifetime of one object is controlled by 
 the lifetime of another.  Collecting the "parent" object would cause the 
 "child" object to be collected, and the child couldn't be collectable until 
 the parent object was. 


Scoped member variables; second half of my old proposal :P
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=38329

	-- Daniel
Jul 30 2007
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:f8m50f$2soh$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:f8m0fq$2ogm$1 digitalmars.com...

 Maybe I'm misunderstanding things, but if you use RAII wherever 
 appropriate, wouldn't that eliminate the need for garbage collection? Is 
 there something I'm missing here?


 Go ahead and program your entire program without persisting any state 
 outside the program execution stack.  Let us know how it goes ;)

 Basically RAII only works for local function variables.  If you want the 
 lifetime of an object to be controlled by something other than the 
 execution time of a function, that's what the GC is for.

 Although I wonder how much the GC could be helped by means of a new kind 
 of object lifetime control, where the lifetime of one object is controlled 
 by the lifetime of another.  Collecting the "parent" object would cause 
 the "child" object to be collected, and the child couldn't be collectable 
 until the parent object was.


Ahh, I see.
Jul 30 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Jarrett Billingsley wrote:

 
 Although I wonder how much the GC could be helped by means of a new kind of 
 object lifetime control, where the lifetime of one object is controlled by 
 the lifetime of another.  Collecting the "parent" object would cause the 
 "child" object to be collected, and the child couldn't be collectable until 
 the parent object was. 


I think Walter intends to use "scope" for that.  ie.

class C {}
class D { scope C c; }


Sean
Jul 30 2007