dynamic library cost (was RE: libtool, java woes)

[Jonathan P. Olson]

In my case, I let the conservative GC collect C++ objects just like it 
does
Java objects.  Instead of storing a native peer in a `long', objects 
which
require a native peer store an int which indexes into a C++ Map vector 
of native
peers.

A little less evil than storing the native peer in a `long' variable.  
Yeah,
the finalizer is still necessary to deallocate the peer int from the Map
vector but this allows the C++ object to be shared by multiple references
and collected by GC without an explicit free().

On Friday, April 13, 2001, at 08:44  AM, Cedric Berger wrote:

> "Jonathan P. Olson" wrote:
>
>> Even in Java, it's often not possible.  Consider how Java AWT
>> implementations
>> typically store native peer objects in `long' variables.  Yeah, this is
>> totally evil but unfortunately Java doesn't provide any way to declare
>> `native' object references.
>
> Ok, I've done that a lot (storing native peer objects in `long' 
> variables)
> but then I write a finalizer to free() the memory explicitely.
> (this is one of the very common use of finalizers)
> Cedric
>