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


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 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 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
next sibling 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 "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
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