On Wed, Sep 24, 2008 at 10:50:59PM +0200, Mateusz Loskot wrote: > strk wrote:
> > The most effective way was usually kind of "pools". > > Basically, you use containers of things to delete at the > > end of the operations (every operation is a class anyway). > > It usually did fine. > > Generally, true but number of issues come to my mind: > Those pools are not documented. Right. But you'll find a few around... > There is no way to learn where are start and end points of operations and > algorithms, unless you read the code from start to the end. There kind of is, if you assume operations are driven by operation classes... > Memory and time boundaries of operations are not documented. True, you may very well end out of memory before getting a chance to dispose all. > So, tracking objects ownership and flows is very hard. > How do we know all users of given pool in given time (without reading the > whole codebase). Which is another well known problem: there are too many interfaces exposed. My solution was: warranty void if you don't use the C-API. So you'd basically follow the flow from C-API on. The wider your pools, the more issues with memory and time boundaries. The closer-to-low-level-op you pool the better. --strk; _______________________________________________ geos-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/geos-devel
