I think that it would be useful to be able to have a "force-delete" storage class (or some such) for CLASS REFERENCES that would automatically delete the class object when the reference went out of scope.  That is, basically, it would be a class object that was NOT garbage collected.

This would be useful for things that need to be cleaned up quickly. People have suggested that open files should be cleaned up (to close the file); I run across things in multithreaded programming that are similar.  In C++, I do things like this:


class Lock;
class Locker
{
private:
    Lock *lockThis;

public:
    Locker(Lock *lockThis) { this->lockThis = lockThis;
lockThis->Lock(); };
    ~Locker() { lockThis->Unlock(); };
};



which allows me to write code like this:



{
    Locker lock(collectionObject->lock)
        ... // do stuff with collection Object
} // collectionObject is automatically unlocked when we go out of scope,

  // either by returning, continuing out of the block, or throwing an
exception



Obviously, in my style of code, delayed GC is NOT acceptable.  You could force the programmer to call delete; as he leaves the block...but the whole point of this object was to make it so the programmer DIDN'T have to remember to unlock everything - it's a failsafe.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:

> I think that it would be useful to be able to have a "force-delete" storage class (or some such) for CLASS REFERENCES that would automatically delete the class object when the reference went out of scope.  That is, basically, it would be a class object that was NOT garbage collected.

A note:

This is where I (again) am really in favor of a reference counting GC.  If you had reference counting, then you could make a syntax rule that you could not mix "force-delete" and normal references in assignments.  Then, you could still have the object persist beyond the scope of the block, but it would IMMEDIATELY be deleted when the last reference went away.

Yes, yes, I know loops are a problem.  But David Bacon (of IBM Research) has a system that can auto-detect loops in a reference-counting system.  If you use a non-concurrent collector (i.e. you stop all threads in the program while the collector runs), then the algorithm to detect loops is actually remarkably trivial.  He has also posted another, more complex, test that will work with concurrent collectors.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> schrieb im Newsbeitrag news:3C8F869F.F8A5B82A@deming-os.org...
> I think that it would be useful to be able to have a "force-delete" storage class (or some such) for CLASS REFERENCES that would automatically delete the class object when the reference went out of scope.  That is, basically, it would be a class object that was NOT garbage collected.

I thought calling delete on an object immediatly destroy it and does not wait until gc catch up?

If this is not so, I think it should be made like this, or are there reasons to not make delete act like this?


> This would be useful for things that need to be cleaned up quickly. People have suggested that open files should be cleaned up (to close the file); I run across things in multithreaded programming that are similar.  In C++, I do things like this:

as you mention the word "multithreaded", I remember a issue, where reference counting can heavily impact the performance on multithreaded enviroment.

Are there the possibility to forbid reference counting on objectst? Maybe with a keyword?



> class Lock;
> class Locker
> {
> private:
>     Lock *lockThis;
>
> public:
>     Locker(Lock *lockThis) { this->lockThis = lockThis;
> lockThis->Lock(); };
>     ~Locker() { lockThis->Unlock(); };
> };
>
>
>
> which allows me to write code like this:
>
>
>
> {
>     Locker lock(collectionObject->lock)
>         ... // do stuff with collection Object
> } // collectionObject is automatically unlocked when we go out of scope,
>
>   // either by returning, continuing out of the block, or throwing an
> exception

I think "RAII" (resource allocation is initialisation) in D is written like
this:

{
   lock_something();    // allocation

  ...
}
finally {
  unlock();        // deallocation
}

I dislike this in some kind too, because it lacks some of the coolines of the c++ - way (as example, the destructor is never called, when an exception within the constructor is thrown), but I think I may get used to it...


> Obviously, in my style of code, delayed GC is NOT acceptable.  You could force the programmer to call delete; as he leaves the block...but the whole point of this object was to make it so the programmer DIDN'T have to remember to unlock everything - it's a failsafe.

You may directly call to the destructor in finally {}... But since you may
call
to unlock as well, there is no more use for a sentry-class like Locker


Imi

I like this idea, but don't think you'd have to specify the storage class explicitly for it to work.  I bet the compiler could figure out whether any references to an object created in a given scope could possibly survive past the end of the block.  If it did, it'd allocate the object from the heap and later GC it.  If no references could possibly survive, it could create the object on the stack and automatically clean it as it goes out of scope.  A reference to an object can "survive" a block by having a pointer to it or one of its members passed as a parameter to a function call or directly stored into a nonlocal variable.

Yes.  I definitely want this.

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8F869F.F8A5B82A@deming-os.org...
> I think that it would be useful to be able to have a "force-delete" storage class (or some such) for CLASS REFERENCES that would automatically delete the class object when the reference went out of scope.  That is, basically, it would be a class object that was NOT garbage collected.
>
> This would be useful for things that need to be cleaned up quickly. People have suggested that open files should be cleaned up (to close the file); I run across things in multithreaded programming that are similar.  In C++, I do things like this:
>
>
> class Lock;
> class Locker
> {
> private:
>     Lock *lockThis;
>
> public:
>     Locker(Lock *lockThis) { this->lockThis = lockThis;
> lockThis->Lock(); };
>     ~Locker() { lockThis->Unlock(); };
> };
>
>
>
> which allows me to write code like this:
>
>
>
> {
>     Locker lock(collectionObject->lock)
>         ... // do stuff with collection Object
> } // collectionObject is automatically unlocked when we go out of scope,
>
>   // either by returning, continuing out of the block, or throwing an
> exception
>
>
>
> Obviously, in my style of code, delayed GC is NOT acceptable.  You could force the programmer to call delete; as he leaves the block...but the whole point of this object was to make it so the programmer DIDN'T have to remember to unlock everything - it's a failsafe.

"Sean L. Palmer" wrote:

> I like this idea, but don't think you'd have to specify the storage class explicitly for it to work.  I bet the compiler could figure out whether any references to an object created in a given scope could possibly survive past the end of the block.  If it did, it'd allocate the object from the heap and later GC it.  If no references could possibly survive, it could create the object on the stack and automatically clean it as it goes out of scope.  A reference to an object can "survive" a block by having a pointer to it or one of its members passed as a parameter to a function call or directly stored into a nonlocal variable.
>
> Yes.  I definitely want this.

In general, this would work for most applications, but I also have code that passes pointers to Lockers (references in the D mindset) to other functions. Those functions guarantee not to change the lock in the long term, but they do muck with it during their course.  So compiler auto-detection is unlikely to work, unless the compiler has VERY aggressive optimization :/

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Immanuel Scholz wrote:

> I thought calling delete on an object immediatly destroy it and does not wait until gc catch up?
>
> If this is not so, I think it should be made like this, or are there reasons to not make delete act like this?

No, your understanding is correct.  (Or, at least, it matches my understanding.)  But if I force programmers to code a delete, then there's no need for my Locker class.

> as you mention the word "multithreaded", I remember a issue, where reference counting can heavily impact the performance on multithreaded enviroment.
>
> Are there the possibility to forbid reference counting on objectst? Maybe with a keyword?

Currently, D's GC is NOT a reference counter (see my other post on the subject).

> I think "RAII" (resource allocation is initialisation) in D is written like
> this:
>
> {
>    lock_something();    // allocation
>
>   ...
> }
> finally {
>   unlock();        // deallocation
> }

Right.  D can do this far more cleanly than C++ (we can consolidate all of the cleanup into the finally block), but it still forces programmers to remember it.  I have had way too many forgotten locks in my own code to trust my own memory :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a6o69m$1vif$1@digitaldaemon.com...

> I thought calling delete on an object immediatly destroy it and does not wait until gc catch up?

It does. What Russ wants is an object that's deleted _automatically_ when its scope ends.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8F883A.3C5903F0@deming-os.org...
> A note:
>
> This is where I (again) am really in favor of a reference counting GC.  If you had reference counting, then you could make a syntax rule that you
could
> not mix "force-delete" and normal references in assignments.  Then, you could still have the object persist beyond the scope of the block, but it would IMMEDIATELY be deleted when the last reference went away.
>
> Yes, yes, I know loops are a problem.  But David Bacon (of IBM Research)
has
> a system that can auto-detect loops in a reference-counting system.  If
you
> use a non-concurrent collector (i.e. you stop all threads in the program while the collector runs), then the algorithm to detect loops is actually remarkably trivial.  He has also posted another, more complex, test that will work with concurrent collectors.

Reference counting would be a big problem to implement in D due to D's support of interior pointers possibly being the only references to an object. Interior pointers are necessary to support array slicing and interfacing easilly to C.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6o7s4$206h$1@digitaldaemon.com...
> "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a6o69m$1vif$1@digitaldaemon.com...
> > I thought calling delete on an object immediatly destroy it and does not wait until gc catch up?
> It does. What Russ wants is an object that's deleted _automatically_ when its scope ends.

What this does is add back in C++ semantics for auto-destruction of objects. Unfortunately, that drags along a great deal of complexity internal to the compiler, coupled with all kinds of obscure rules about when temporaries are destructed, interactions with various features like ?:, and lots of inevitable obscure implementation bugs.

Adding this in will mean that D will no longer be a small, easy to understand and implement language.

Far and away most uses of resource deallocation are memory releases, which is not necessary with garbage collection. The next most common use is releasing mutex locks, which is handled by the "synchronize" features of D. What's left should not be too onerous to use with explicit finally blocks.

Destructor semantics are very handy.  Let's say I have a 3D Model object

class Model3D
{
private:
  IDirect3DVertexBuffer8* vb;
  IDirect3DTexture8* tex;
public:
  this() { /+ load model here +/ }
  ~this() { vb->Release(); tex->Release(); }
};

If your language gives you no guarantees that the destructor will ever get called, you cannot make sure that your program leaves something in a consistent state.  You can't use try...finally in the above situation.

This kind of thing is more common than you think.  It's not just mutex's and memory we have to manage.

Sean


"Walter" <walter@digitalmars.com> wrote in message news:a707f0$1qif$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a6o7s4$206h$1@digitaldaemon.com...
> > "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a6o69m$1vif$1@digitaldaemon.com...
> > > I thought calling delete on an object immediatly destroy it and does
not
> > > wait until gc catch up?
> > It does. What Russ wants is an object that's deleted _automatically_ when its scope ends.
>
> What this does is add back in C++ semantics for auto-destruction of
objects.
> Unfortunately, that drags along a great deal of complexity internal to the compiler, coupled with all kinds of obscure rules about when temporaries
are
> destructed, interactions with various features like ?:, and lots of inevitable obscure implementation bugs.
>
> Adding this in will mean that D will no longer be a small, easy to understand and implement language.
>
> Far and away most uses of resource deallocation are memory releases, which is not necessary with garbage collection. The next most common use is releasing mutex locks, which is handled by the "synchronize" features of
D.
> What's left should not be too onerous to use with explicit finally blocks.