Doing one last thing to a WeakReference

[Paul J. Lucas]

Yeah, that's how it goes. Work on a temporary copy if you're concerned
about that.

Needlessly copying around very large images is a non-starter.

By the way, how come you're so much concerned about deleting
a file when your program is actually working on it?

It may be working on it at time T1. At some later time T2 > T1, the user may
decide this image is rubbish and delete it. Users are fickle.

Also, are you sure you open the file in read-only mode?

Windows doesn't care.

Not if you do it properly.

But you may also forget about the timeout, load the file/image metadata
once, and remaining data on-demand.

But I still have to keep the file open in that case.

- Paul

 

[Stefan Ram]

Unfortunately, I don't think Java will ever get
stack-allocation of objects (which would enable true
destructors and RAII) which is what's really needed to solve
the problem at hand.

ISO/IEC 14882:2003(E) does not mention that objects are
allocated from a stack. They have »automatic storage
duration«. An activation record might be implemented as a
stack frame or on the head.

In Java, it is similar: The language does not promise that any
objects are allocated from a stack, but some JVM do an escape
analysis: When the JVM can proof that an object can not
»escape« from the lifetime of a method, it will be allocated
from a stack indeed.

The difference between both languages is that Java does not
have automatic storage duration as part of the language and so
one can not rely on block exit triggering a method.

 

[John W Kennedy]

C++ has destructors.

Are there any other (object-oriented) programming
languages with destructors?

Turbo Pascal did; I suppose Delphi does. I daresay any OO language that
has either a FREE statement/operator or stack-allocated objects will,
perforce.

 

[Stefan Ram]

Supersedes: <[email protected]>

Unfortunately, I don't think Java will ever get
stack-allocation of objects (which would enable true
destructors and RAII) which is what's really needed to solve
the problem at hand.

ISO/IEC 14882:2003(E) does not mention that objects are
allocated from a stack. They have »automatic storage
duration«. An activation record might be implemented as a
stack frame or on the heap.

In Java, it is similar: The language does not promise that any
objects are allocated from a stack, but some JVM do an escape
analysis: When the JVM can prove that an object can not
»escape« from the lifetime of a method, it will be allocated
from a stack indeed.

The difference between both languages is that Java does not
have automatic storage duration as part of the language and so
one can not rely on block exit triggering a method.

 

[John B. Matthews]

Turbo Pascal did; I suppose Delphi does. I daresay any OO language that
has either a FREE statement/operator or stack-allocated objects will,
perforce.

As did Wirth's Object Pascal, but I'm not sure free qualifies as a
destructor. In contrast, what the OP wants is a user-defined method that
is called when the storage is actually reclaimed, but at a more
deterministic time than finalize().

 

[Paul J. Lucas]

Is the variable reference-counted or is the object?

The object (of course).

If the method returns the same reference twice, how is it counted?

It never returns the same *reference* twice. It can, however, return new
references to the same *object* twice.

If it returns a reference to an existing object with other references
out there, how will it be counted?

The count of the object is always incremented when creating a new counted
reference to it. All other facts are irrelevant.

- Paul

 

[Arne Vajhøj]

I think the best accomodation that could be made without a major and
potentially awkward addition to the language and runtime system would be a
C#-style 'using' construct:
using (ImageInfo info = getImageInfo(fileName)) {
int w = info.getWidth() ;
// etc
}

In [1], it is described how to write a class
»FileInputStreamOpenCloseAndNull« so that

for( final java.io.FileInputStream fileInputStream:
new FileInputStreamOpenCloseAndNull( "input.txt" ))
use( fileInputStream );

will close »fileInputStream« after the use.

The same can be achieved with a finally.

Arne

 

[Arne Vajhøj]

Turbo Pascal did; I suppose Delphi does. I daresay any OO language that
has either a FREE statement/operator or stack-allocated objects will,
perforce.

All languages with dynamic allocation and no GC, which probably
is about the same as your criteria.

Ada must fell in this category as well.

Arne

 

[Arne Vajhøj]

As did Wirth's Object Pascal, but I'm not sure free qualifies as a
destructor. In contrast, what the OP wants is a user-defined method that
is called when the storage is actually reclaimed, but at a more
deterministic time than finalize().

I don't think the argument was that free was a destructor - just that
a language that used free would need a destructor.

Arne

 

[John B. Matthews]

I don't think the argument was that free was a destructor - just that
a language that used free would need a destructor.

Yes, but the utility was apparent only in retrospect. All the languages
mentioned (Ada, C++, D, Delphi, Java, Object Pascal, Turbo Pascal) are
object-oriented and have destructors in the sense of a method that is
automatically invoked when the object's storage is reclaimed.
Conversely, not all object-oriented languages that can reclaim storage
(by freeing dynamically allocated memory or closing a stack frame) have
the method invocation characteristic of destructors. Wirth & Tessler's
original Object Pascal is a familiar counter-example. IIRC, Turbo Pascal
had just a single destructor.

 

[Paul J. Lucas]

In [1], it is described how to write a class
»FileInputStreamOpenCloseAndNull« so that

for( final java.io.FileInputStream fileInputStream:
new FileInputStreamOpenCloseAndNull( "input.txt" ))
use( fileInputStream );

will close »fileInputStream« after the use.

The same can be achieved with a finally.

Except if "after the use" is not lexically scoped.

- Paul