Patrick Down wrote:

> Yes, this is a problem.  Right now I don't think D needs very complicated code for stack unwinding on an exception.  But the auto stuff would require a visit to every frame's cleanup section.

Force-delete doesn't impact the complexity of cleanup code.  In any block, you can manually add a finally {} block, which must run when the block exits or an exception is thrown.  That's a "hand-made" force-delete.

This whole thing is really an issue of whether or not the compiler should include syntax sugar to automatically add one of these cleanup blocks.

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

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a732ft$gum$1@digitaldaemon.com...
> Does that not sound like a gigantic kludge to you?  I don't want to be polluting my main() function with stuff that conceptually should be done
in
> a finalize method of an object.

It doesn't have to be main(), just places in your program that suggest themselves as a convenient place to put them.

> Sure we can use delete obj; and manually call the GC when we need to... I would just like some guarantees from the language that the destructor will get called for every object that is collected, and that every object will
be
> collected as the program shuts down.

main() does automatically run a collection cycle upon completion. However, it is still possible that there's a dangling reference in the stack and static data. It's possible the gc could be changed to ignore them for the final collection.

>  If the compiler could automatically
> "collect" objects that simply go out of scope when it knows that no
pointers
> to the object have been stored anywhere (the code never takes the address
of
> the object for instance, or never stores it or sends it anywhere), that would be real nice too.

The problem is it isn't simple. There's a lot of implementation required to get it right.

Russ Lewis wrote in message <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: [snip]
>

I think it's time to unravel the need for a feature and way it was
implemented
in C++.  I think what you want is an encapsulated mechanism that a) has
an implicit or explicit context, b) has a entrypoint called on entry to a
block,
and c) an entreepoint guaranteed to be called on block exit.

Note that the semantics of "synchronized" in D and Java have exactly those characteristics, but are builtin rather than programmable.  Perhaps the answer is replacement of "synchronized" with an extensible mechanism to allow other and/or additional resource managers to share the semantics. Among other things, this would allow the odd crank to synchronize with two state locks rather than mutexes.  Sure would be a nice feature...

Among the problems to be solved is argument passing.   Although the
two forms of "synchronized" take an implicit or explicit argument, the
actually monitor is invisible, buried in the implementation.  It's fairly
clear that any generalization would require a little more infrastructure
to be useful.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C963321.EFBC360F@deming-os.org...
> Walter wrote:
> > I think it is analogous to the way C++ calls destructors on stack
objects
> > when they go out of scope. The problem isn't that they are on the stack,
but
> > the complicated rules for doing the destructors.
> Can't we just say that for these types of objects the compiler implicitly generates a finally {} block which deletes them?  It does add some
complexity,
> but not much.  Compilers that don't support that feature (yet) just throw
> compile-time errors on the type modifier :)

That's just what C++ does.

Things get complicated, though, for destruction of temporaries that may or may not have been created, for ?: expressions that might have been short circuited, construction objects as function parameters, and then an exception happens before the function gets called, etc.

"Walter" <walter@digitalmars.com> wrote in message news:a7k4io$mbt$1@digitaldaemon.com...

> Things get complicated, though, for destruction of temporaries that may or may not have been created, for ?: expressions that might have been short circuited, construction objects as function parameters, and then an exception happens before the function gets called, etc.

There won't be any temproraries there, since we work with references
rather than objects. This is an important difference from C++ -
here, the only thing the compiler should do is to guarantee that
any auto reference gets deleted at the end of the scope. In fact,
it just means implicitly inserting delete statements at the end
of the block, after every break, and in final section of each try block.
Another tricky thing is that the block must be wrapped an invisible
try..finally block:

    void foo()
    {
        while (true)
        {
            /* try { */
            auto File file = new File;
            ...
            if (file.eof())
            {
                /* delete file; */
                break;
            }
            ...
            file.read(n);     // could raise an exception
            ...
            try
                file.write(n);
            finally
            {
                n = 0;
                /* delete file; */
            }
            ...
            /* } finally { delete file; } */
        }
    }

Of course, there's also goto, but in this case you could just state that "goto doesn't delete auto references" - so if somebody is smart enough to goto out of block (instead of, say, break'ing), he should take care of deleting all autos himself.

Are these rules complex? I wouldn't say so...

"Pavel Minayev" <evilone@omen.ru> wrote in news:a7keme$1aig$1@digitaldaemon.com:

> "Walter" <walter@digitalmars.com> wrote in message news:a7k4io$mbt$1@digitaldaemon.com...
> 
>> Things get complicated, though, for destruction of temporaries that may or may not have been created, for ?: expressions that might have been short circuited, construction objects as function parameters, and then an exception happens before the function gets called, etc.
> 
> There won't be any temproraries there, since we work with references
> rather than objects. This is an important difference from C++ -
> here, the only thing the compiler should do is to guarantee that
> any auto reference gets deleted at the end of the scope. In fact,
> it just means implicitly inserting delete statements at the end
> of the block, after every break, and in final section of each try
> block. Another tricky thing is that the block must be wrapped an
> invisible try..finally block:
> 

What about this...

void bar(out Obj a)
{
  a = new Obj;
}

void foo()
{
  auto Obj b = new Obj;

  bar(b);
}

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91DB6CC9E77BApatcodemooncom@63.105.9.61...

> What about this...
>
> void bar(out Obj a)
> {
>   a = new Obj;
> }
>
> void foo()
> {
>   auto Obj b = new Obj;
>
>   bar(b);
> }

The object created first is collected by the GC, since there are no
references left to it. The second one (constructed in bar()) gets
deleted at the end of function.

This leads to a decision that all auto objects shouldn't be changed once assigned, as if it was declared const in C++.

I suppose the question is "when should an object be deleted?"
this could be ...
(1) when the procedure / method exits (object goes out of scope) := in
which case the compiler could simply add an invisable finally block
(2) when a throw occurs := in which case the compiler schedules a garbage
collection on all objects in the stack (after all throws are exceptions and
need not be fast).
(3) when the task / job exits := another garbage collection cycle (think
this is already specified in D standard)
(4) when an object is overwritten := in the same cases this is trivial -
just add "delete <obj>;" before reassignment. - however in a called class
this is difficult [void foo( inout a ) { a = new Obj; }] either we check a
flag in the object to see if it should be deleted (yuck - slow (has to be
done on every new)) or wait until the procedure returns,  check if old
object == returned object and if not delete old object.

Finally we have a problem if the object is referenced outside the procedure,  ie. delete must occur on the object even after the force delete command in the procedure has been forgotten.

I suggest that if forced deletion is to be included that it works as
follows.
(1) the object is created specifying forced deletion required
(2) the object continues to exist until the procedure it was defined in
exits,  then the object is deleted - reguardless of any external references
- creating such references could be considered an error,  though catching
this at compile time could be tricky.
(3) the object is deleted if a throw is thrown past the procedure - this
could be in a finally block or by running a GC cycle (latter option assumes
no external references).
(4) the object is deleted if it is reassigned within the procedure
(5) the object is deleted if it is reassigned within a called procedure -
but only after that procedure returns

The only other way I can see to achieve this is to use reference counting - though I believe this has been (and should be) ruled out.

C 2002/3/25