Stephen and Jim,

Just one thing to note in Stephen's note.  In the GX API, object handles are
not memory pointers as Stephen implies, so don't try to dereference them if
you are programming in C or C++.  What you actually get is a long integer
that we use to look-up the actual pointer in the GX wrapper layer.  This
allows your GX's to migrate to 64-bit systems of the future without
recompilation.

Another little aside to this is that any handle can be destroyed by calling
Destroy_SYS(handle).  The garbage collection code needs to know the
destructor for every handle anyway, so this function is at times more
convenient to use than the actual handle destructor.  You will that some of
our GX code uses this function instead of the class destructor, although the
effect is identical.

Ian
_______________
Geosoft Inc.
Ian MacLeod
[EMAIL PROTECTED]
(416) 369 0111 x323


> -----Original Message-----
> From: Stephen Cheesman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 21, 2001 1:17 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [gxnet]: Trend2_VVU - autodestroy question
> 
> 
> Jim:
> 
> The objects are effectively "lost", because only the latest remains
> available. For instance, consider the following example:
> 
> hVV = Create_VV( REAL ,  0);          // hVV = 0x009fb17c  (a pointer 
>                                               // to an object 
> in memory)
> hVV = Create_VV( REAL ,  0);          // hVV = 0x009fb20e  (another
> pointer 
>                                               // to another object in
> memory)
> hVV = Create_VV( REAL ,  0);          // hVV = 0x009fb241  
> (yet another 
>                                               // pointer to 
> another object
> in memory)
> 
> Here, the first two objects still exist and are still being 
> "maintained"
> inside Oasis montaj, but they are lost to the user, because 
> the hVV pointer
> refers just to the third one.
> 
> Now the GX compiler works by creating a list of all the 
> objects, and when a
> GX exits it goes through to see which objects are still 
> around, and calls
> the Destroy functions automatically, but programmers should 
> not rely on this
> capability (although Microsoft, in its ".NET" is actually 
> promoting this
> under the term "garbage collecting").
> 
> Stephen
> 
> _______________
> Geosoft Inc.
> Stephen Cheesman
> [EMAIL PROTECTED]
> (905) 315-8207
> 
> Software and services for effective earth science decision-making.
> Free Oasis montaj interface now available at http://www.geosoft.com
>  
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: December 21, 2001 12:49 PM
> To: [EMAIL PROTECTED]
> Subject: [gxnet]: Trend2_VVU - autodestroy question
> 
> 
> 
> Hi Stephen,
> 
>  
>  
> hLine = FirstSelLine_DB(hDB);
> while (iIsLineValid_DB(hDB,hLine))
> {
> 
>     .....  (other code).
>  
>       hVV = Create_VV( REAL ,  0);    // create object inside the loop
>    ...... (other code)
>  
>   // --- Advance to Next hLine ---        
> 
>   hLine = NextSelLine_DB( hDB , hLine );
> }
> 
> > The problem is that the object is re-created over and over 
> again for each
> > new line. While the GX compiler is set up to keep track of 
> each object as
> it
> > is made, and automatically destroys them afterward, 
> hopefully preventing
> > what is known as a "memory leak", this certainly stresses 
> the system,
> > especially if there are a lot of objects and a lot of lines.
> 
> 
> Could you elaborate on this a little?
> 
> What actually happens in this case?  Do all the hVV's point 
> to the same
> memory?
> Seems to me I remember that it doesn't.  Does the system keep track of
> objects
> in some way that is independent of the symbols that are 
> attached to them?
> 
> Does automatic destruction of objects occure at any time other than GX
> termination?
> 
> Thanks,
> 
> ---
> Jim Roy                      voice  541 757 7231
> Sys. Admin.                  fax    541 757 7331
> NW Geophysical Assoc.        http://www.nga.com
> Corvallis Or. US
> ---
> _______________________________________________________
> More mailing list info 
> http://www.geosoft.com/support/listserv/index.html
> List Archive http://www.mail-archive.com/gxnet@lists.geosoft.com
> _______________________________________________________
> More mailing list info 
> http://www.geosoft.com/support/listserv/index.html
> List Archive http://www.mail-archive.com/gxnet@lists.geosoft.com
> 
_______________________________________________________
More mailing list info http://www.geosoft.com/support/listserv/index.html
List Archive http://www.mail-archive.com/gxnet@lists.geosoft.com

Reply via email to