I for one don't care about varargs, and could completely do without printf if need be.  All I need is a ToString() method that works on every type and string concatenation.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374919407791782@news.digitalmars.com...
> On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter@digitalmars.com>
wrote:
>
> > The only significant language thing now is the deterministic object destruction.
>
> Also, templates now have to be actually _implemented_. =)
> I would also mention safe varargs as one quite important feature. Propety
> gettors &
> settors - but these are mostly decorative.

Yes but the refcounting overhead can many times be optimized away.

In any case I have never ever seen refcounting overhead show up in a performance profiler.  It could cost you some valuable memory though, but in most cases I think it's worth it.  You wouldn't want to refcount, say, a point or rectangle.  But anything bigger than a matrix would be a good candidate.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ak6f6p$2oan$1@digitaldaemon.com...
>
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9273A36B24E83patcodemooncom@63.105.9.61...
> > Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.
>
> I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

So just put the finalization code into the destructor.  I wouldn't want these things to be forced to come from the heap.  And why have two subtly different finalization methods?

Instead of "delete this" they can call "gc.dealloc(this)" or some such, in
your scenario.

Sean

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9274526F5BFB6patcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ak6f6p$2oan$1@digitaldaemon.com:
>
> >
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9273A36B24E83patcodemooncom@63.105.9.61...
> >> Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.
> >
> > I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.
>
> Yes but I think you should call it d.o.f. Deterministic Object Finalization.  Here's why.
>
> What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref().  If a user want's the full memory cleanup they can call "delete this".
>
> The reason is you can use it to implement other memory management schmes on top of the mark and sweep.  If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling.
>
> class Foo : Counted
> {
>   static Foo head;
>   static Foo alloc()
>   {
>     Foo temp;
>     if(head)
>     {
>       temp = head;
>       head = temp.next;
>     }
>     else
>       temp = new Foo();
>   }
>   void unref()
>   {
>     this.next = head;
>     head = this;
>   }
>   private next;
> }
>
>
>
> {
>   Foo a = Foo.alloc()
>
> } // a's unref returns it to the free pool
>

On Sat, 24 Aug 2002 11:44:01 -0700 "Sean L. Palmer" <seanpalmer@earthlink.net> wrote:

> I for one don't care about varargs, and could completely do without printf if need be.  All I need is a ToString() method that works on every type and string concatenation.

Heh, feels almost like "back to Algol-60 days". =)

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:ak8k3k$2d8g$1@digitaldaemon.com:

> So just put the finalization code into the destructor.  I wouldn't want these things to be forced to come from the heap.  And why have two subtly different finalization methods?
> 
> Instead of "delete this" they can call "gc.dealloc(this)" or some
> such, in your scenario.
> 
> Sean
> 

That's fine too.  I just don't want the memory explicitly collected after ~A is called.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ak8jib$2ci8$1@digitaldaemon.com...
> I would very much like that but it's not something that would prevent me from using D.  I can always manually delete things.  But performance wise it's much better if the compiler knows when things are going out of scope and just deletes them immediately, or even better knows this and allocates them on the stack instead.

I've been thinking about a root "ref counting class" hanging off of Object. This will work in most cases, but it fails if an instance is implicitly cast to an Object reference, and then that reference isn't counted.

On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter@digitalmars.com> wrote:

> I've been thinking about a root "ref counting class" hanging off of Object. This will work in most cases, but it fails if an instance is implicitly cast to an Object reference, and then that reference isn't counted.

Then maybe create a separate hierarchy tree? So that Object would be root for
all GC-collected
classes, and that other class - not derived from Object - root to all
refcounted classes.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374931061655671@news.digitalmars.com...
> On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter@digitalmars.com>
wrote:
> > I've been thinking about a root "ref counting class" hanging off of
Object.
> > This will work in most cases, but it fails if an instance is implicitly
cast
> > to an Object reference, and then that reference isn't counted.
> Then maybe create a separate hierarchy tree? So that Object would be root
for
> all GC-collected
> classes, and that other class - not derived from Object - root to all
> refcounted classes.

I did think of that, but I think it adds too much end-user complexity. There's got to be a better way...

Pavel Minayev wrote:

> On Sat, 24 Aug 2002 13:34:35 -0700 "Walter" <walter@digitalmars.com>
>  wrote:
>
>
>> I've been thinking about a root "ref counting class" hanging off
>> of Object. This will work in most cases, but it fails if an
>> instance is implicitly cast to an Object reference, and then that
>>  reference isn't counted.
>
> Then maybe create a separate hierarchy tree? So that Object would be
>  root for  all GC-collected classes, and that other class - not
> derived from Object - root to all  refcounted classes.

Refcounting is viral, so the hierarchy would have confusing intermingling, and migrate to everyone being refcounted.

I don't want to get into this debate, as the only result will be that
refcounting's a bloody huge problem that needs more investigation.  It's straightforward for interpreted languages and not so for native code. Unprecedented to my knowledge, which is far from broad, due to things like:

   counted class foo { int y; }

   foo h = new foo;
   int *z = &h.y;
   h = null;

I'm not pointing this out as an impossible problem; I'm pointing it out as an unobvious one with big consequences, and there are many others, certainly ones I have no knowledge of.  Refcounting requires an in-depth review of its effects to find out what the damage really will be, what language changes will be needed, or if it's simply not possible to have both it and what's recognisably D.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D6822B5.6020409@users.sourceforge.net...
> I'm not pointing this out as an impossible problem; I'm pointing it out as an unobvious one with big consequences, and there are many others, certainly ones I have no knowledge of.  Refcounting requires an in-depth review of its effects to find out what the damage really will be, what language changes will be needed, or if it's simply not possible to have both it and what's recognisably D.

You're quite possibly right.