Even Rouault wrote:
What's the "Java dirty trick" that the code talks about?
Ari,
Do you really want to hear the explanation ;-) ? OK, here it is.
This is related to subtelities of SWIG and Java garbage collection.
Imagine that DISOWN is still used for the input parameter of
ForceToMultiPolygon
Consider the following code :
geom1 = ogr.CreateGeometryFromWKT(xxxx);
geom2 = ogr.ForceToMultiPolygon(geom1);
IMHO this shouldn't be allowed in languages that use OGR through swig in
the first place since forceTo.. really works on its argument geometry
although it syntactically returns a new pointer. That's why I thought it
would have been better to be a object method, i.e.,:
geom1 = ogr.CreateGeometryFromWKT(xxxx);
geom1.ForceToMultiPolygon();
There are similar problems elsewhere in the swig bindings, which are
also fixed with similar tricks in Perl bindings (I'm not sure about the
other languages), but they are usually due to things like feature
depending on the existence of its layer.
Regards,
Ari
geom2 = null;
/* big memory allocation */
foo(geom1)
If nothing special is done, during the big memory allocation, the garbage
collector will collect the geom2 object. During its finalization, this will
call the destructor of the underlying C++ object (let's call it geom2_cpp).
But since the call of ForceToMultiPolygon(), geom1_cpp is owned by geom2_cpp,
thus deleting geom2_cpp will cause geom1_cpp to become invalid. And
foo(geom1) would operate on garbage.
This can be fixed (I have already done this for Feature.SetGeometryDirectly())
by adding special code in ogr_java.i so that geom1 (the Java object) holds a
Java reference to geom2 (the Java object). So the 2 objects are bound
together and garbage collection of one cannot occur if the other one is still
in scope...
Calling Clone() and separating the lifetime of the 2 objects avoids the above
complication.
Best regards,
Even
Ari
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
