This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dynamic library cost (was RE: libtool, java woes)
- To: Cedric Berger <cedric at wireless-networks dot com>
- Subject: Re: dynamic library cost (was RE: libtool, java woes)
- From: Jonathan P. Olson <olson at mmsi dot com>
- Date: Fri, 13 Apr 2001 08:51:30 -0700
- Cc: dewar at gnat dot com,gcc at gcc dot gnu dot org,hans_boehm at hp dot com,java at gcc dot gnu dot org,jsturm at one-point dot com,tromey at redhat dot com
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
>