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