www.digitalmars.com         C & C++   DMDScript  

D - "Manual" GC

reply "news.digitalmars.com" <kencr shaw.ca> writes:
Would it be possible to add the ability to specifically direct the GC to
collect a given reference?  Obviously it would not be good for the system to
simply free the specified object since there may be other references to it.
What I'm wondering is if the GC system could use the object reference as a
starting point to a (hopefully) much smaller reference set.

You could retain the well-known "delete" syntax for this operation, or
simply invoke it whenever a reference is set to null.

for (int i=0; i<100; ++i);
{
  Bar b = new Bar(i);
  b.foo();

  b = null;  // this way
  delete b;  // or this way
}

If the GC finds that the object can be freed, then it does so immediately.
It would/could recursively evaluate any references contained in the
referenced object.

If the GC finds that the object cannot be freed (due to another reference),
then the code has a bug in it .  The GC could ignore the early free attempt
and continue and/or log the error so it can be corrected.

I wonder if this kind of semi-automatic GC might better satisfy some people
with GC-phobias, and could keep a system's memory footprint lower.
Hmmm...perhaps it would just end up doing a full collect anyhow.

Comments?

Thanks,


Ken Carpenter
Jan 13 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
The delete expression already does just this!

"news.digitalmars.com" <kencr shaw.ca> wrote in message
news:avtsel$1s5s$1 digitaldaemon.com...
 Would it be possible to add the ability to specifically direct the GC to
 collect a given reference?  Obviously it would not be good for the system

 simply free the specified object since there may be other references to

 What I'm wondering is if the GC system could use the object reference as a
 starting point to a (hopefully) much smaller reference set.

 You could retain the well-known "delete" syntax for this operation, or
 simply invoke it whenever a reference is set to null.

 for (int i=0; i<100; ++i);
 {
   Bar b = new Bar(i);
   b.foo();

   b = null;  // this way
   delete b;  // or this way
 }

 If the GC finds that the object can be freed, then it does so immediately.
 It would/could recursively evaluate any references contained in the
 referenced object.

 If the GC finds that the object cannot be freed (due to another

 then the code has a bug in it .  The GC could ignore the early free

 and continue and/or log the error so it can be corrected.

 I wonder if this kind of semi-automatic GC might better satisfy some

 with GC-phobias, and could keep a system's memory footprint lower.
 Hmmm...perhaps it would just end up doing a full collect anyhow.

 Comments?

 Thanks,


 Ken Carpenter

Jan 14 2003
next sibling parent Ken Carpenter <Ken_member pathlink.com> writes:
In article <b00p4f$s90$1 digitaldaemon.com>, Walter says...
The delete expression already does just this!

Very nice! I guess I need to get some experience with D before asking for new features. Ken Carpenter
Jan 14 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
Hi.

Here's a simple language extension I've used in the past.  It actually 
gets used a lot.  Examine the following common C code:

while((c = getchar()) != EOF) {
     charArray[x++] = c;
}

Instead of puting assignments in the condition (or duplicating them 
twice in your code), you can write:

do {
     c = getchar();
} while(c != EOF) {
     charArray[x++] = c;
}

The first do-part is always executed at least once.  If the condition 
then fails, the loop is terminated.  Otherwise, the while-part is 
executed, and then we start over by executing the do-part.

One programmer I know always writes his loops with this construct, and 
then only reduces it to the simpler do-while or while loop if it turns 
out that there are no statements in the do-part or while-part.  Ever 
stare at the screen for a while trying to figure out if you need a while 
vs. a do-while loop?  This construct eliminates that.

What do you think?

Bill Cox
Jan 25 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E326753.90803 viasic.com...
 Instead of puting assignments in the condition (or duplicating them
 twice in your code), you can write:

 do {
      c = getchar();
 } while(c != EOF) {
      charArray[x++] = c;
 }

What I do for such things is: while (1) { c = getchar(); if (c == EOF) break; charArray[x++] = c; }
Jan 26 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Theodore Reed wrote:
 On Sun, 26 Jan 2003 00:04:46 -0800
 "Walter" <walter digitalmars.com> wrote
What I do for such things is:

    while (1)
    {    c = getchar();
        if (c == EOF)
            break;
        charArray[x++] = c;
    }

Why not: while ((c = getchar()) != EOF) { charArray[x++] = c; } Or does this not work in D?

Sure. Just of all three variants, the one by Bill seems to be most legible. Less ugly. Well, you can argue that all C descendants have to be ugly because their parent was. :> -i.
Jan 26 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi.

The while loop thing is pretty minor.  My need for the extension to the 
while loop is somewhat self-imposed.  At work, we have many rules for 
how to write code.  You can't use break, continue, or goto, and you 
can't put assignments in conditions.  To get around the problem, we use 
the C pre-processor:

#define utDo do {

#define utWhile(cond) if(!(cond)) break;

#define utRepeat } while(true);

Our loops often look like:

utDo {
     c = getchar();
} utWhile(c != EOF) {
     charArray[x++] = c;
} utRepeat;

Rules like this seem to help new programmers become productive without 
shooting themselves in the foot.  The audience for all our code is 
"stupid people" (not that we hire them very often).  Frankly, I've come 
to like it.  I can be pretty stupid now and then.  We're definately a 
KISS house (keep it simple-stupid).

BTW, I've finished reading the D definition in detail.  I hope not to 
post any more ill-informed messages.

Bill

Ilya Minkov wrote:
 Theodore Reed wrote:
 
 On Sun, 26 Jan 2003 00:04:46 -0800
 "Walter" <walter digitalmars.com> wrote

 What I do for such things is:

    while (1)
    {    c = getchar();
        if (c == EOF)
            break;
        charArray[x++] = c;
    }

Why not: while ((c = getchar()) != EOF) { charArray[x++] = c; } Or does this not work in D?

Sure. Just of all three variants, the one by Bill seems to be most legible. Less ugly. Well, you can argue that all C descendants have to be ugly because their parent was. :> -i.

Jan 26 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E34038A.5020901 viasic.com...
 The while loop thing is pretty minor.  My need for the extension to the
 while loop is somewhat self-imposed.  At work, we have many rules for
 how to write code.  You can't use break, continue, or goto, and you
 can't put assignments in conditions.  To get around the problem, we use
 the C pre-processor:

I can understand the ban on goto's and assignments, but not the ban on break and continue. I've seen code that didn't use break and continue, and it tended to be more complex as a result (and hence more prone to bugs). In the end, I suspect you'll find such macros that create alternate syntax are more trouble than they are worth (the code won't be readable to other programmers, nor any editors / browsers / parsers that try to extract information by reading source text). I used similar things for a while, and wound up editting them all out.
Feb 03 2003
parent Bill Cox <Bill_member pathlink.com> writes:
In article <b1n5st$it3$2 digitaldaemon.com>, Walter says...
"Bill Cox" <bill viasic.com> wrote in message
news:3E34038A.5020901 viasic.com...
 The while loop thing is pretty minor.  My need for the extension to the
 while loop is somewhat self-imposed.  At work, we have many rules for
 how to write code.  You can't use break, continue, or goto, and you
 can't put assignments in conditions.  To get around the problem, we use
 the C pre-processor:

I can understand the ban on goto's and assignments, but not the ban on break and continue. I've seen code that didn't use break and continue, and it tended to be more complex as a result (and hence more prone to bugs). In the end, I suspect you'll find such macros that create alternate syntax are more trouble than they are worth (the code won't be readable to other programmers, nor any editors / browsers / parsers that try to extract information by reading source text). I used similar things for a while, and wound up editting them all out.

Hi, Walter. The rules we're using have evolved over probably 20 years now and at multiple companies, but change when we find a need. The ban on break and continue is about 12 years old, and seems to have had broad support over this term. I agree that these can help make code clearer. The only downside is that inexperienced programmers (or those who are a bit too creative) can make a mess with them. The most uncommon aspect of our coding environment is that programmers share code daily. Everyone writes code that looks good to everyone else, and anyone can easily read anyone else's code. To get there, the coding rules are a bit on the strict side. Even without our ban on break and continue, I'd argue that the do {...} while(condition) {...} loop is nice. It seems to simplify a parser, rather than complicate it, and it's handy quite often. I bet if you tried it for a while, you'd become a fan. I apriciate your feedback, but don't work too hard. I'd feel guilty if you wasted time replying to silly feature requests like this one, rather than doing the real work of making D fly. Bill
Feb 03 2003
prev sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Bill Cox" <bill viasic.com> ha scritto nel messaggio
news:3E326753.90803 viasic.com...
[...]>
 Instead of puting assignments in the condition (or duplicating them
 twice in your code), you can write:

 do {
      c = getchar();
 } while(c != EOF) {
      charArray[x++] = c;
 }

This is good. And should be easy to achieve: do <instruction> while (<expression>) <instruction> The normal do-while can fall in this more general loop. Ciao
Jan 27 2003
prev sibling parent reply Theodore Reed <rizen surreality.us> writes:
On Sun, 26 Jan 2003 00:04:46 -0800
"Walter" <walter digitalmars.com> wrote:

 
 "Bill Cox" <bill viasic.com> wrote in message
 news:3E326753.90803 viasic.com...
 Instead of puting assignments in the condition (or duplicating them
 twice in your code), you can write:

 do {
      c = getchar();
 } while(c != EOF) {
      charArray[x++] = c;
 }

What I do for such things is: while (1) { c = getchar(); if (c == EOF) break; charArray[x++] = c; }

Why not: while ((c = getchar()) != EOF) { charArray[x++] = c; } Or does this not work in D? -- Theodore Reed (rizen/bancus) -==- http://www.surreality.us/ ~OpenPGP Signed/Encrypted Mail Preferred; Finger me for my public key!~ "The word of Sin is Restriction. O man! refuse not thy wife, if she will! O lover, if thou wilt, depart! There is no bond that can unite the divided but love: all else is a curse. Accursed! Accursed be it to the aeons! Hell." -- Liber AL vel Legis, 1:41
Jan 26 2003
parent "Walter" <walter digitalmars.com> writes:
"Theodore Reed" <rizen surreality.us> wrote in message
news:20030126011522.320fdcea.rizen surreality.us...
 Why not:

 while ((c = getchar()) != EOF) {
     charArray[x++] = c;
 }

 Or does this not work in D?

Yes, you can do that, and it works fine in D.
Feb 03 2003