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

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
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
>
>

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

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

"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;
    }

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

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.

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.
> 

"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

"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.